Explain OO -vs- Proceedural

[Ray Marsh]

Tim Uckun said, in the RMI / Corba forum, that if you can't explain something to a 15 year old in 15 seconds, you don't know it.
Well, I have heard and read about OO concepts, many times, and I could not give a concise explanation of them. I have an excessively thick skull and come from a traditional procedural environment.
So, if someone can give a simple concise definition of OO I would greatly appreciate it. Extra credit if you can contrast it to procedural processing so even I can understand it.
Thanks, Ray

[Tony Alicea]

"OOP allows you to describe the problem in terms of the problem, rather than in terms of the computer where the solution will run."
--Bruce Eckel

[paul wheaton]

OO is thinking about things instead of thinking about processes.

[Ray Marsh]

Thanks Tony, and I've read some of Bruce's book. But, what does that mean from a programming perspective? How is a procedural approach different from a OO approach to the same issue? I can write modular code that's easily maintainable. I can write generic programs to perform common tasks instead of replicating the code over and over in many larger programs. This can all be done in a 100% procedural language. Somehow I believe there is more to OO than small programs doing the work of one large program. I know about concepts like encapsulation ( I even understand that one a little ) and others, but I'm still unclear on the significant differences between the two methods.

[Tony Alicea]

"But, what does that mean from a programming perspective?"
That it's easier to use OOP than structured. It's more human-like.
"I can write modular code that's easily maintainable."
But it can be done easier and for more complex systems using OOP. Nobody (I think) says it's impossible to do it otherwise, just better.
"I can write generic programs to perform common tasks instead of replicating the code over and over in many larger programs"
Can I reuse that code by just typing "extends Abc" and adding a function or two with completely predictable results and WITHOUT having to even see the detailed code?
"Somehow I believe there is more to OO than small programs doing the work of one large program."
Sure, but you wanted a 15 second explanation
"I know about concepts like encapsulation..."
My favorite example (as a C programmer) for showing the benefits of OOP encapsulation is from Peter van der Linden's Just Java 2 (pages 30-34). That's one of the first books that I read on OOP and Java.
Finally, I "converted" to OOP last June after having gone through another conversion in 1977 (the "Structured Programming conversion" . I too thought (in 1989 and 1990 when everyone around me was talking about a "new" language called C++ which was, well, C plus other stuff called "OOP" that it must be one new CIS "fad" that the professors at the Universities had to invent to stay in business and publish etc.
I was wrong. "Better Late Than Never", I say.
Finally, "Thank God" for Java: I DIDN'T HAVE TO LEARN C++ TO DO REAL OBJECT ORIENTED PROGRAMMING!!
I cheated "fate"!

[Frank Carver]

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).]

[Ray Marsh]

Thanks fellas. If you can get a "RPG meatballer" to understand OO you both get the teacher of the year award. And one for Paul too, for all the grief I give him. I will read both of your responses more carefully when I get home.