The Nightstar Zoo

Nightstar IRC Network - irc.nightstar.net
It is currently Fri Dec 15, 2017 5:06 am

All times are UTC - 6 hours [ DST ]




Post new topic Reply to topic  [ 15 posts ] 
Author Message
 Post subject: Interesting OO comment
PostPosted: Thu Jun 17, 2004 3:07 pm 
Offline
Nightstar Graveyard Daemon
User avatar

Joined: Mon Jun 03, 2002 8:30 pm
Posts: 1071
Location: Wouldn't you rather observe my Velocity?
I'm reading Object-Oriented Programming by Peter Coad & Jill Nicola. I picked the book up because they give a short list of quotes that should alert you that you're not thinking OO. I say most of these all the time, and here I was thinking I was OO.

What do you think of these?
  1. "This coordinates/handles/controls/manages..."
  2. "Save a few lines of code by factoring out and inheriting..."
  3. "The object decides what to do based on the type of that other object..."
  4. "Just get its value and do something with it."
  5. "How can it do ______ to that other object?"
  6. "What are the functions in the system?"
  7. "Get its ______ and do ______ with it."


Last edited by Chalain on Thu Jun 17, 2004 3:22 pm, edited 1 time in total.

Top
 Profile  
 
 Post subject:
PostPosted: Thu Jun 17, 2004 3:16 pm 
Offline
Energizer Bunny
User avatar

Joined: Wed May 22, 2002 12:24 am
Posts: 1634
The only one that really pisses me off is the third one: The first should instead ask the second to do the job, and not try to do it itself - the latter makes it hard to extend functionality to larger and larger sets of object types... and when you're writing large systems with a lot of interoperation, you need extensibility and lots of it.

The second one sorta grates - inheritance isn't so much for code saving but for functionality/interface duplication: code savings comes from that in a sense, but that's an indirect effect and should not be considered as a motivation to factor/inherit.

I'm not really sure what the others mean.

Vorn


Top
 Profile  
 
 Post subject:
PostPosted: Thu Jun 17, 2004 3:27 pm 
Offline
Nightstar Graveyard Daemon
User avatar

Joined: Mon Jun 03, 2002 8:30 pm
Posts: 1071
Location: Wouldn't you rather observe my Velocity?
The one that got me was the first one. I do that all the time. In fact, I have a warm place reserved in my heart for any class that ends with "...Manager Object". Coad and Nicola strongly insist that this is not proper OO. I haven't gotten all the way through their rationale yet, but so far what I've been able to determine is that they feel you should not create a class to represent the manager of a thing, but the thing itself. They say avoid classes that end in "-er" if at all possible. They started with a "Counter" class and then went back and said "No, I don't want an object to manage the count, I want an object that IS the count." And they renamed the class Count.

I sort of begin to see the concept, though... a Counter class is a class you meant to provide a nice interface to a count value, but what you have done is written a class that gets in the way between you that count value. Better to just write a class for the object itself.


Top
 Profile  
 
 Post subject:
PostPosted: Thu Jun 17, 2004 3:29 pm 
Offline
Nightstar Graveyard Daemon
User avatar

Joined: Mon Jun 03, 2002 8:30 pm
Posts: 1071
Location: Wouldn't you rather observe my Velocity?
Vorn the Unspeakable wrote:
I'm not really sure what the others mean.


All of these are things that should send up a warning flag that you're thinking procedurally instead of OO if you hear them.


Top
 Profile  
 
 Post subject:
PostPosted: Thu Jun 17, 2004 3:33 pm 
Offline
Energizer Bunny
User avatar

Joined: Wed May 22, 2002 12:24 am
Posts: 1634
Well sure, I knew that, but... what kind of... uh... What would that kind of thing look like?

(also, if we follow the first one to its logical conclusion, a dictionary would have all its functionality in its nodes, as opposed to having an overarching object that stored them and mediates finding/indexing)

Vorn


Top
 Profile  
 
 Post subject:
PostPosted: Thu Jun 17, 2004 4:16 pm 
Hmm...

I'm certain I've been guilty of at least five or six of those so far today. No doubt all of them within the last 72 hours.

But I fail to see how this is a bad thing. I will probably never fully adhere to "pure" OO programming until somebody can explain to me why I should adhere to someone's idea of "pure" OO programming. Perhaps Coad and Nicola put in such a rationale in their book.

Objects, and OO concepts in general are a programming tool. A useful programming tool, but when all is said and done, still a tool, and no one tool can solve every problem in the best way, which is why we have more than one. Vorn has an example of a problem where "pure" OO may not be ideal.

I shun anybody that tries to turn OO into their religion. After a while, every programming task starts to look like a nail.


Top
  
 
 Post subject:
PostPosted: Thu Jun 17, 2004 4:42 pm 
Offline
Nightstar Graveyard Daemon
User avatar

Joined: Mon Jun 03, 2002 8:30 pm
Posts: 1071
Location: Wouldn't you rather observe my Velocity?
Vorn the Unspeakable wrote:
(also, if we follow the first one to its logical conclusion, a dictionary would have all its functionality in its nodes, as opposed to having an overarching object that stored them and mediates finding/indexing)


Actually, a dictionary is an excellent example of the right way to do it. You're thinking of a collection as the only only object in the system, but what you really have here is an object that is a collection of other objects. A dictionary object that acts as a collection for words rather than a manager for words (subtle difference--the menager can manipulate the internals of the words) sounds like good design to me.

Leaving the dictionary for a moment, here's some more verbiage out of Coad & Nicola. They give some "Object-think" phrases to use to replace some of those procedural phrases:
  • Bad: How can it do _____ to that object?
    Good: I am a _____. I know how to _____ myself.
  • Bad: What are the functions in the system?
    Good: What are the objects in the system?
  • Bad: It decides what to do based on the type of object.
    Good: I am a ____ object. I know about these kinds of objects. I send them the ____ message.
  • Bad: Get its ____ and do _____ with it.
    Good: I am a ____ object. I know my ____, and I use it to _____ myself.


Okay, we'll pause now for the giggling to stop. When you are done telling each other to go ____ yourselves, we'll move on... :D

Now, back to the dictionary. I submit that a dictionary has a good class design as follows:
Code:
class Dictionary has a collection of Word objects.  It can insert new words and look up words and return them.


Here's the bad/procedural version:
Code:
The dictionary module has a collection of words and definitions.  You can submit a word and its definition to the dictionary by calling insertWord(word, definition).  Function lookup(word) takes a word and returns the definition for that word.


Imagine trying to add part-of-speech functionality to that. Or pronunciations.

Now, to illustrate what a poor OO design looks like, consider this first cut at an OO system that *does* violate C&J's paradigm:
Code:
class WordManager has a collection of Words.  It knows how to add new words to the dataset and get the definition for a word by looking it up.


That seems reasonable at the outset, doesn't it? C&J's problem with this is that the verbiage describing this system is a good description of a program, not the problem domain. You can immediately see that the WordManager knows more about word objects than it should, and as a result, any changes to the word object will necessitate a change in the word manager.


Top
 Profile  
 
 Post subject:
PostPosted: Thu Jun 17, 2004 4:50 pm 
Offline
Energizer Bunny
User avatar

Joined: Wed May 22, 2002 12:24 am
Posts: 1634
So in short, the correct way to implement Python's dictionary class would be to have: A. a key-value pair class, B. a collection class to put those in, and C. a class that recieves requests for keys and pulls collection.lookup(key).getValue() ?

Vorn


Top
 Profile  
 
 Post subject:
PostPosted: Thu Jun 17, 2004 5:06 pm 
Offline
Nightstar Graveyard Daemon
User avatar

Joined: Mon Jun 03, 2002 8:30 pm
Posts: 1071
Location: Wouldn't you rather observe my Velocity?
Pi wrote:
But I fail to see how this is a bad thing.


This thread takes this as a given, or at least considers it value neutral but assumes that the goal IS to write code that is more OO, not less.

Pi wrote:
I will probably never fully adhere to "pure" OO programming until somebody can explain to me why I should adhere to someone's idea of "pure" OO programming. Perhaps Coad and Nicola put in such a rationale in their book.


They might, though I haven't reached it yet. I suspect it'll be a hundred little things rather than one overarching principle.

Personally, I don't believe in OO programming any more than I believe in procedural programming. What I believe in are individual tenets that I have tested and observed to be good ideas. Things like high cohesion and loose coupling, opaque interfaces, or self-managing code. These are all things you can do in a procedural environment if you work at it. They're also things you can avoid doing in many environments that purport to be OO. Coad & Nicola's main thrust seems to be aimed at folks who think and claim they're OO, but really aren't.

This might be a good starting topic for about three or four other threads--one on OO vs. Procedural, another on good design in procedural code, and yet another on good OO design ideas including why it's a good idea.

Pi wrote:
I shun anybody that tries to turn OO into their religion. After a while, every programming task starts to look like a nail.


True... but are you shunning OO because it sounds like a religion, or because it sounds like a different religion than your own?

What I'm finding is that I think heavily in procedural terms. I wrote those C&J quotes because, like Pi, I have thought or said each of them in the past 72 hours. What I have observed is that the best coding practices I have ever experienced (unit testing, agile development, refactoring) lend themselves verrrrrry strongly to OO design, and not just OO design, but good OO design. I have had a few experiences where I got outside my procedural experiences and wrote some code that was (luckily, and through no fault of my own) good in design, and these other practices snapped into place. The result for me was like leaving the comfort of the sea to discover hydroplaning. Much of what I already knew had to be left behind to make it work.

Now that I've gotten it to work a few times, I have begun to see that the OO paradigm isn't really anything new, it's just a different way of rearranging the knowledge I already have. I didn't really need to leave it all behind; I just needed to let the framework of my thinking go, and build a new one around the individual concepts.

Now, having waxed metaphorical, do I think OO is the end-all, be-all? Not really. But it is rapidly becoming the tool I try to grab first.


Top
 Profile  
 
 Post subject:
PostPosted: Thu Jun 17, 2004 5:13 pm 
Offline
Nightstar Graveyard Daemon
User avatar

Joined: Mon Jun 03, 2002 8:30 pm
Posts: 1071
Location: Wouldn't you rather observe my Velocity?
Vorn the Unspeakable wrote:
So in short, the correct way to implement Python's dictionary class would be to have: A. a key-value pair class, B. a collection class to put those in, and C. a class that recieves requests for keys and pulls collection.lookup(key).getValue() ?


LOL, I was thinking of dictionary in terms of a program to describe the book from Webster or Oxford.

Actually, you have very closely described how Python does indeed implement its dictionary class. All the sorting & searching goes on in the dictionary class. The keys must be immutable and hashable, for storage and sorting purposes, and the value of any key can be any valid object.

For example, dict does not know how to reverse() the contents of one of its values, where a StringManager might. All it knows how to do is return that object, and if *IT* knows how to _____ itself (reverse), then yeah, you can do it:

d = {}
d['Jennifer'] = "Jennifer Jensdotter"
d['Jennifer'].reverse()


Top
 Profile  
 
 Post subject:
PostPosted: Thu Jun 17, 2004 5:29 pm 
Offline
Energizer Bunny
User avatar

Joined: Wed May 22, 2002 12:24 am
Posts: 1634
You said StringManager. :P

Vorn


Top
 Profile  
 
 Post subject:
PostPosted: Thu Jun 17, 2004 5:43 pm 
Offline
Nightstar Graveyard Daemon
User avatar

Joined: Mon Jun 03, 2002 8:30 pm
Posts: 1071
Location: Wouldn't you rather observe my Velocity?
Vorn the Unspeakable wrote:
You said StringManager. :P


...as a bad example. Sorry I didn't make that clear. A StringManager would know how to reverse() its elements, but suppose later you wanted a collection of arrays, or that you wanted to use Unicode strings. In the case of dict(), you write the appropriate object class and reuse the collection class. StringManager, on the other hand, leaves you having to rewrite a bunch of code.


Top
 Profile  
 
PostPosted: Thu Jun 17, 2004 7:36 pm 
Chalain wrote:
What do you think of these?
    ...
  • "The object decides what to do based on the type of that other object..."


We've got a physics model right now that depends on inheritance of various primitives (all of which handle their own junk), and a virtual function that returns an object's type. I'd say that's pretty OO considering the alternatives. :) In fact, in the end it allows us to define new physics primitives without really touching the old ones. Suddenly we decided we want to add arbitrary collision triangles. No problem. If it turns out they're too slow, we can take them out again without harming existing code.

Isn't it truly OO if it's modular enough to rip out a piece and simply put another in its place? Isn't that the point?

As an aside, I do prefer to layer my object model, very much like the OSI networking standard does it... only different. :) This has saved me from fantastically hairy situations that I had no idea about until well after tha fact. As it turns out, it all tends to rest on static functions at the bottom layer. So wouldn't a true OO model break down if you just dig deep enough?


Top
  
 
PostPosted: Thu Jun 17, 2004 8:21 pm 
Offline
Nightstar Graveyard Daemon
User avatar

Joined: Mon Jun 03, 2002 8:30 pm
Posts: 1071
Location: Wouldn't you rather observe my Velocity?
Raif wrote:
Isn't it truly OO if it's modular enough to rip out a piece and simply put another in its place? Isn't that the point?


I would say that it is not. Modular code was one of the battle cries of the OO crowd, but it's hardly the unique demesne of same. It is possible to write modular code in just about any language (I've seen it done in assembly). C has many, many constructs to assist this (static functions and interface code like COM are good examples).

This is the inverse condition that Coad & Nicola are targeting. They're saying that OO does not imply Good Design. I submit that Good Design (such as modularity) does not imply OO, either.

Finally, that getType method might work great, but I suspect that C&J would splutter. If you need to know my type, then you're trying to do work that belongs to me. (And for efficiency's sake, that might be the right thing to do.)


Top
 Profile  
 
 Post subject:
PostPosted: Fri Jun 18, 2004 12:07 am 
Yeah, for all intents and purposes I am you. I'm just a slightly different style you (hence the inheritance model). They're all "PhysicsObject", just some are "PhysicsCircle" while another might be "PhysicsBox". I'm not sure how you can make drastically different shapes more OO than that (at least, not without incurring severe overhead). Perhaps I'm just not seeing it the way they are. :)


Top
  
 
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 15 posts ] 

All times are UTC - 6 hours [ DST ]


Who is online

Users browsing this forum: No registered users and 1 guest


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum

Search for:
Jump to:  
Powered by phpBB® Forum Software © phpBB Group