The Nightstar Zoo

Nightstar IRC Network - irc.nightstar.net
It is currently Thu Dec 14, 2017 2:06 pm

All times are UTC - 6 hours [ DST ]




Post new topic Reply to topic  [ 4 posts ] 
Author Message
 Post subject: Why OO? Or Why Not?
PostPosted: Wed Jun 30, 2004 11:20 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?
Have it out, boys. This is the place to bash on about OO vs. PC.

In general, is one better than the other? Which? Why?

I think we've already established that nobody here is interested in a religious war. Few of us would say OO or PC is the best in every situation, that it's the only tool you'll ever need. Some of us would argue that one or the other is the only tool they've ever needed, but that's neither here nor there. We wouldn't be in this forum if we were above learning something now and then.

I'll start. I bought another book by Peter Coad, this one co-authored by Edward Yourdon. It's obviously in the same series as Object Oriented Programming; it's called Object Oriented Analysis. C&Y make a point early on that, when I read it, made me think of Pi's question, "why bother, what's so great about it?" In the case of OOA, C&Y make the typical set of claims, like it allows you to tackle more complex problems, increasing the internal consistency of analysis, explicitly represent commonality, etc. It also gets your whites whiter yet is safe enough for colors. Let me wade through all of that and present about four points they make in the first chapter that rang true for me.

But first, a disclaimer. I've seen some good procedural coders do each of these things. Every good procedural coder I've met has, at the very least, been comfortable dealing with the implied downside. I'm not saying you can't do these things in PC code, but I am saying that it's harder. I'm including these things because I have practiced OO in the past, and these things got dramatically better or easier for me than they were in PC. We're not talking religious black and white, but we are talking noticeably different shades of gray.

  1. The specifications are resilient to change. You've already heard me whining about the database project I wrote in PC code. You can write good, modular PC code, it is true. But if I sit down at an editor and start writing, chances are good I'm going to write a bigass monolithic program and then go back later and modularize it. Chances are also good that once it's working, I'm not going to bother going back to modularize it. The modularization in PC code represents extra effort put into code that has already paid off; the extra effort nets you no tangible benefit.

    OO code seems to intrinsically include modular boundaries. It's like drawing on graph paper: sure, you can scribble around freehand, but if you want to use the lines, they're there. Since you're making modular boundaries anyway, it draws your mind to it and a little extra thought gets you writing good modular boundaries. As a result, a good portion of the specification change requests that come in are already supported by the interfaces, and off you go. (I will concede that I have also seen specification changes that crosscut class boundaries, and they're as much if not more of a pain to rework than the same amount of PC code would be.)
  2. Some bits of knowledge that are implicit in PC code become explicit in OO. Encapsulation is easy to denote in both languages, but abstraction and inheritance are key OO concepts that explicitly denote differentiation in your design. I have seen these done in PC code, but it is buried at best and implicit or hidden at worst. This association between layers of abstraction is clearly and easily denoted in OO code.
  3. OOA includes all three of the PC analysis methodologies. This may be a fuzzy line where Coad steps away from typical OO and says "y'all aren't OO enough," and thus this may not be an argument for OO so much as for OO done Coad's way. In the past 40 years, project analysis has been done primarily using one of three methods, and each method has its gurus who champion it above all else (including OOA). These methods are: Functional Decomposition (breaking the functionality of a system into successively smaller subfunctions until the subfunctions are small enough to write), Data Flow Analysis (Structured analysis. Instead of watching the verbs, you watch the nouns), and Information Modeling (mapping out objects, attributes and relationships--what you're doing when you go to the whiteboard and start drawing boxes & connecting them).

    Coad's take on all three is that they are all three good, not just in different situations but for different aspects of the same project. His OOA approach is to model the system using OO techniques and all three of the previous techniques.
  4. The code tends to mimic the problem domain closely. When you do (for example) functional decomposition, it requires a human to map the issues of the problem domain onto the collection of discovered functions to see if all of them are covered. Historically, this human is frequently wrong and the project is set back by the occasional "Oh yeah" from the designers. OOA code explicitly maps out much of the problem domain, making it very clear when a subtle issue is not addressed. I don't really know how to describe what good problem-domain mimicking code looks like, except to say this: The best OO code I ever wrote, Liren was able to read, understand, and for the most part, debug. And she doesn't know how to program. THAT is the hallmark of a well-designed bit of code.


Well, that's my piece. Comments? Thoughts? Your own bits to add, pro or con?

I would not be above seeing a synthesis of good design (common to OO & PC) emerge here, but what the hell, I'll probably play devil's advocate & goad you guys for the heck of it, just because contrast is more interesting sometimes. :twisted:


Top
 Profile  
 
 Post subject:
PostPosted: Thu Jul 01, 2004 1:57 pm 
I like OO, although I generally don't write "pure" OO. Some things just seem more natural to implement in an OO way (not all, though—Java's "math" class gives me hives).

I remember doing the "find a path through a maze" project in college in C++ without any visible integers in the code (well, I used enums at one point, which are technically integers, but...). The other CS students in my hall were offended. I also threw an exception for a success (It made sense! Really!)


Top
  
 
 Post subject:
PostPosted: Thu Jul 01, 2004 9:37 pm 
You, sir, are satan. :)


Top
  
 
 Post subject:
PostPosted: Fri Jul 02, 2004 1:15 am 
Raif wrote:
You, sir, are satan. :)


Which particular part prompted that reaction? ;)

Actually, it made perfect sense to throw an exception on reaching the goal. Success was an exceptional condition: it could only happen once, max, while hitting a dead end could happen any number of times. Also, it was convenient in that I could just implement my success exception object as a stack, and have the catch block push the location data from the current frame onto it and pass it on, so when it reached main() it contained the solution to the maze.


Top
  
 
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 4 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