New to OOP

[Lozbinator]

Hi All,

I'm very new to OOP, but have studied some programming way back in my first year at uni (98).

I've read a whole bunch of resources online, but I'm looking for something really clear and really simple that will help me wrap my head around OOP.

I'm also looking for information to help me understand how and why you seperate stuff into 3 tiers, and clear, simple stuff about Use Case Diagrams and Class Diagrams.

I also would love to find something that helps you to determine what information is best "put into a Class" (apologies if I am not making sense, still to green to know how to phrase this properly), particularly step-by-step with useful, real life examples.

If anybody can help me out here I would greatly appreciate it.

If it helps any, I'm supposed to be programming in Python and working this into Zope / Plone.

Thanks in Advance!
Lozbinator

 

[BobRodes]

I like to think of OOP as the software analog of the maunfacturing concept of systems of interchangeable parts. Look at how cars are built, for example. You build parts and assemble them. A class is a part, a component is a group of related parts that go into a whole.

Now, read up on concepts of cohesion and coupling to determine what functionality goes into which class. A very good book will be Tom Pender's "UML Bible" which will be published later this year. (I'm helping to edit it, but I'm not getting paid anything if you buy it, so I believe it's ok to mention it here. Sorry if I'm wrong!) Also, any other books by Tom Pender are worth reading. UML Distilled is also excellent.

Good luck!

Bob Rodes

 

[billchris]

Here are a couple of books:
[ul][li]Applying UML and Patterns - Craig Larman (Excellent introduction to OOP conectps and design.)[/li]
[li]Cloud's to Code - Jesse Liberty (A complete case study of an OOP project with sample UML and code. The code is C++ but the principles are the same regardless of language.)[/li]
[/ul]

“I have always found that plans are useless, but planning is indispensable.” --Dwight Eisenhower

 

[DonQuichote]

I've read a whole bunch of resources online, but I'm looking for something really clear and really simple that will help me wrap my head around OOP.

Maybe unexpected, but there are two things that made me grasp why object oriented programming is different from procedural programming. The first is that someone explained me the concept of "design by contract". The second was the book "Refactoring" by Martin Fowler. This book starts with a nice example of a procedural style program and gradually he morphs it into an object oriented one. The book is about the process itself, but also makes it clear why you should want to redesign your code. Most examples in the book are in (fairly simple) Java.

I'm also looking for information to help me understand how and why you seperate stuff into 3 tiers, and clear, simple stuff about Use Case Diagrams and Class Diagrams.

I learned the tiers the hard way. Separating the User Interface from the rest is very good for testability. User Interfaces themselves are often hard to test automatically, so if you can split your application into an "engine" and a "front cover", you can test the complete application automatically (see

http://c2.com/cgi/wiki?UnitTest)

without the need for a specific set of buttons.
Salesmen will also tell you that you can easily turn your application into a web application, because you only need another "front cover".

Separating the database storage from the rest is also something I recently learned to value. Storing and retreiving data is something that should work right, without objections, confirmations, etc. That is why I want a "dumb data" layer. I can test the database actions separately. This "dumb data" layer is then driven by the "business logic" layer, that can ask for confirmation, check user rights, and in other aspects "has a mind of its own".

Best regards