The Design of Software (CLOSED)

A public forum for discussing the design of software, from the user interface to the code architecture. Now closed.

The "Design of Software" discussion group has been merged with the main Joel on Software discussion group.

The archives will remain online indefinitely.

Trying to grok OO programming. How's this approach?

I'm still slowly making the transition to OO (from VB3 and 6).

One approach that seems to work is to imagine that I've got some Magic Class and just start imagining how I'd like to use it.

Then, later, I go back and flesh out the class.

This is something I saw another programmer do I thought it was quite good.

Sort of like OO psuedocode.

Anyone here do that?
Is there a name for that?
Any pointers to resources on that?
Mr. Analogy {Shrinkwrap µISV} Send private email
Wednesday, September 27, 2006
I consider all classes to be jam filled donuts. To get access to the sugary sweet jam (attributes) you need to poke a straw through the donut and suck (method [getter]) or you could blow (method [setter]). it's really the only way to get jam into and out of the docunt.

Donuts interact too. If you press two warm sugar coated jam filled donuts together on your mouse mat you end up with a greasy sticky splodge (leaky abstraction poorly defined interface), but if you place two donuts in napkins (clean interface) it's easy to stick a straw between the two.

I think I've stretched that analogy far enough :-)
Alex Le Dain Send private email
Wednesday, September 27, 2006
> just start imagining how I'd like to use it

Yes, I think that's called "designing an API".


When I was learning OOD I thought that it was about encapsulating data, and defining methods (or as some epople call it, 'behaviour') whose implementation is closely related to or depends on the data that has been encapsulated, for example:

* The Win32 API has a lot of functions to work with file handles (CreateFile, ReadFile, CloseHandle, etc.).

* The 'data' here is the file handle

* 'Encapsulating' that data might mean defining it as a private data member of a new 'File' class.

* Now that you have the data encapsulated (private and therefore inaccessible from outside the class), you use Alex Le Dain's jam donut technique to to decide what methods to give your class: you can't call the Windows CreateFile API directly anymore (because that requires a file handle, which you know longer have, because the file handle is hidden away as private data inside your new File class), so you poke a straw through the donut by defining a createFile method of the class, or perhaps a constructor.

So: encapsulation; and behaviour (public methods) associated with state (private data).

Another important thing about OO is inheritance: implementing abstract interfaces (to decouple interface users from interface implementors), and subclassing not-so-abstract superclasses (to inherit default behaviour from the superclass, which is a kind of code re-use).

To be honest, I read some C++ books to learn *how* to do OOP ... it was when I then read the _Design Patterns_ book that I got some ideas of *why* I might want to do OOD (i.e. to enable techniques like those).
Christopher Wells Send private email
Wednesday, September 27, 2006
"imagine that I've got some Magic Class and just start imagining how I'd like to use it."

I often do that. I create the API that I want to use, and then I implement it, if possible. A lot of times makincg a really simple API means you have to do redundant calculations and caching and stuff you don't want to, which is why deciding to do it in advance is good since when you run into 'inefficiencies', the API is already set and so you don't just decide to go and change the signatures to pass a little something extra along, no matter how tempting that is.
Meghraj Reddy
Thursday, September 28, 2006
What you want to do looks like CRC Cards (Google for "crc cards oo" for more details), i.e. a concise, high level sketch of how the main "blocks" will collaborate in your OO design.

See also:
paolo marino Send private email
Thursday, September 28, 2006
If you write a little bit of code that uses your Magic Class, and then implement enough of your Magic class to get that code to work you'll be doing TDD.
Honu Send private email
Thursday, September 28, 2006
Microsoft is offering a free eLearning course on upgrading from Visual Basic 6.0

You can check it out here:
Andrey Butov Send private email
Thursday, September 28, 2006
If you make extensive use of setters and getters, then you'll have things that you imagine are "classes" but they're really just blobs of data that get operated on by good old fashioned procedural code.

If getters and setters give you orgasms, then you should try "C" which has structures and procedural code, without all that timewasting stuff with typing extra code for getters and setters.

Just ignore anyone who tells you that "getters and setters" are something to do with OO programming and you'll be miles ahead of most people who never got past procedural code.

Thursday, September 28, 2006
Bertrand Meyer calls the approach you describe "Outside In Design." You imagine yourself as a client of the object (called the "supplier"), and think about how you'd like the conversation to go.  Meyer uses this technique as the basis for his method of instruction ("The Outside In Method").

It's definitely a technique I make heavy use of in my day to day work.

I agree with the earlier poster who cautioned against heavy use of getters and setters.  The current crop of popular languages makes it harder to avoid their use, but you will definitely thank yourself for making the effort when it comes time to make changes. 

Allen Hollub produced an article several years ago on this topic that created quite a stir.  Although I don't agree with him on every point, I think he does present a good argument:

There have also been several discussions of this topic on this forum over the years, too.
Josh Send private email
Thursday, September 28, 2006
I think your basic idea is a good one. When you design a class you always want to be thinking about its public interface: what methods and properties does it expose to the world?

Then there are a whole lot of design heuristics like the Single Responsibility Principle (each class should handle one 'thing' and should only need to be modified if that thing changes), high cohesion (kind of the same thing), low coupling, etc.

There is a lot of good discussion about class (and larger scale) design principles in "Code Complete 2" by Steve McConnell.  I also got a lot out of "Applying UML and Patterns" by Craig Larman.
Jesse Send private email
Thursday, September 28, 2006

This topic is archived. No further replies will be accepted.

Other recent topics Other recent topics
Powered by FogBugz