I'll have a stab at this one.
I apologise for the length of this message, but I hope it's worth it..
One of the best ways that I have found to get a grip on OO, is through the use of CRC
cards. If you have never met this technique, it's very simple. Get a few blank index
cards (I use 5x3" cards as they are cheap and easy to carry around. They also help to limit the amount of text on each card -- a good thing). Each card will have three things written on it: 1. A Class name, 2. A list of responsibilities for that class, 3. A list of the other classes that this class collaborates with. Hence the name CRC; Class Responsibilities Collaborators.
Note that CRC is a very high-level technique. It makes no mention of stored data let alone data types or whether it might be stored in an array, a list, a binary tree ... It also makes no mention of method/function/procedure calls or constructors or any of the other details of OO implementations. Eliminating this sort of detail actually helps to generate and communicate a truly OO design without getting bogged down in trivia.
For the apocryphal 15-minute description, I'd get a few 5x3 index cards and a pencil, pick a familiar domain and work through it, annotating, correcting and even tearing up cards as we go. We are all at least mildly familiar with the operation of the Java Ranch, I'll use a dialog about the design of a Bulletin Board System as an example. In the text below,
ME is me,
15 is a virtual 15 year old.
Note that my exploration below is deliberately brief and probably both dangerously wrong and sub-optimal in places. Please feel free to experiment with this technique to come up with your own, better, designs
ME Let's look at the design of BBS then. What do you think we might need?
15 Well each message is an array of characters, so we'll need some sort of stored length ...
ME Hold it right there! We don't want to worry about data types for this. Having some sort of Message class is probably a good idea though. Let's create a card for it
<pre>
Name: Message
Responsibilities:
Collaborators:
</pre>
Do we know anything about it yet?
15 It's somewhere to keep the text of a message?
ME Sure, we'll add that responsibility
<pre>
Name: Message
Responsibilities: Keep text of a message
Collaborators:
</pre>
15 And it belongs to a Forum!
ME OK
<pre>
Name: Message
Responsibilities: Keep text of a message
Collaborators: Forum
</pre>
15 But we haven't got a Forum class. I'll make another card.
<pre>
Name: Forum
Responsibilities:
Collaborators:
</pre>
ME Good. Now what do we know about a Forum?
15 It has a list of messages
ME Remember that we're not just talking about data here. How might that be thought of as a responsibility?
15 Alright. It associates a sequence of messages
ME That's better:
<pre>
Name: Forum
Responsibilities: Associate a sequence of messages
Collaborators: Message
</pre>
15 Hey, this is really easy. Now how about a Bulletin Board which manages a collection of Forums:
<pre>
Name: Bulletin Board
Responsibilities: Manage a collection of Forums
Collaborators: Forum
</pre>
ME And now what?
15 That's all there is, isn't there?
ME Not really. You're still thinking in terms of just the data. What other
concepts might there be in this system. Think!
15 I know! A User, with his/her Preferences.
ME That's good, but what about something a little more abstract. How do all those messages get to the User's browser, and in what format?
15 In HTML from the server, of course. Do we really need to design a web server? I thought you said this was simple!
ME Sorry. I'll rephrase my question. How does that raw text from the message get into a form suitable for display on the User's browser?
15 Something has to format it. I see, let's have a Formatter class.
ME Well, that's certainly one way to do it. What could we put on a card for such a class?
15 <pre>
Name: Formatter
Responsibilities: Display a message as HTML
Collaborators: Message
</pre>
ME That's good so far, but it's only part of the way. If you look at a typical BBS web page, there's lots of other stuff there.
15 Oh yes. A whole list of messages. Maybe that card should have been:
<pre>
Name: Formatter
Responsibilities: Display a Forum as HTML
Collaborators: Forum
</pre>
ME Possibly, but I quite liked the previous version as well. How about we have two classes for this:
<pre>
Name: Message Formatter
Responsibilities: Display a Message as HTML
Collaborators: Message
</pre>
<pre>
Name: Forum Formatter
Responsibilities: Display a whole Forum as HTML
Collaborators: Forum, Message Formatter
</pre>
15 I get it. But what about those little buttons next to each message? Are they part of MessageFormatter or ForumFormatter or are they something else.
ME How about a new class Message Buttons:
<pre>
Name: Message Buttons
Responsibilities: Display buttons for editing/deleting/replying to a message
Collaborators: Message
</pre>
And the Message Formatter class will need to show these
<pre>
Name: Message Formatter
Responsibilities: Display a Message as HTML, Show message -specific buttons
Collaborators: Message, Message Buttons
</pre>
15 And I'll do the same for Forum Buttons and Forum Formatter.
ME This is going well. But now it's time to look at the cards a little differently. Can you see any similarities between any of the classes?
15 Well every time I do anything for a Message, I seem to do something very similar for a Forum.
ME So can we make use of that. Can we share anything?
15 I guess ...
ME OK. What I'm looking for is similarities which can be moved into a parent class. Some classes we've got here can inherit things from their parent. Let's have a new class Group:
<pre>
Name: Group
Responsibilities: Associate a sequence of objects
Collaborators:
</pre>
This has behaviour common to both Forum and Bulletin Board. Is it like anything else?
15 Those Buttons look like a group...
ME Good. Anything else? Be ruthless!
15 At a push, I guess a Message is a sequence of letters.
ME Aha! Now we're getting somewhere. Let's take a quick look back at those Formatter classes
15 They both format some sort of Group!
ME So let's have another parent class:
<pre>
Name: Formatter
Responsibilities: Display a Group as HTML, Show group-specific buttons
Collaborators: Group
</pre>
15 You missed the Message Buttons...
ME Not really. This is a general parent class. It can't just collaborate with Message Buttons.
15 Well add Message Buttons and Forum Buttons then.
ME Think about it. What do they have in common.
15 I See. They're both really just a Group.
ME They are, but I think they have important features in common which make them different from Messages and Forums.
15 You want a Buttons class which has the common stuff.
ME Yep. So the Formatter card now looks like:
<pre>
Name: Formatter
Responsibilities: Display a Group as HTML, Show group-specific buttons
Collaborators: Group, Buttons
</pre>
And so the discussion continues...
Key things to learn from the above are that OO concepts emerge fairly painlessly from the discussion.
Inheritance is a natural outcome of trying to find things-in-common to reduce duplication of effort.
Encapsulation really helps design because you don't need to care about detailed data representations until you actually code the solution.
Multiple Instances of Objects is so obvious that it's almost ignored, but was often a problem in procedural/structured/modular programming. Even
Polymorphism, traditionally one of the hardest parts of OO to explain flows quite easily from the interactive nature of the design process.
Try it. You might just like it.
For more details see:
http://c2.com/cgi/wiki?CrcCards http://c2.com/doc/oopsla89/paper.html The CRC Card Book by David Bellin, Susan Suchman Simone (ISBN 0201895358)
UML Distilled by Martin Fowler and Kendall Scott (ISBN 0201657838
Extreme Programming Explained - Embrace Change by kent Beck (ISBN 0201616416)
Designing Object Oriented Software by Rebecca Wirfs Brock Brian Wilkerson and Lauren Wiener (ISBN 0136298257 )
[This message has been edited by Frank Carver (edited February 02, 2000).]