Summary
One of the core tenets of object-oriented programming is encapsulation. It's one of OO's most powerful ideas. More powerful than inheritance. Unfortunately it's also one of the most ignored.

---

Advertisement

Wow.. it's been a year ... yikes. That's partly due to my having set up blog.daveastels.com. But I'll try to post programming related highlights here. So to kick that off... here's a piece I wrote this weekend.

---

In "OO in One Sentence: Keep It DRY, Shy, and Tell The Other Guy" (http://www.pragmaticprogrammer.com/articles/may_04_oo1.pdf) Andy Hunt & Dave Thomas (The Pragmatic Programmers) talk about good OO code being shy:

"The best code is very shy. Like a four-year old hiding behind a mother’s skirt, code shouldn’t reveal too much of itself and shouldn’t be too nosy into others affairs. But you might find that your shy code grows up too fast, shedding its demure shyness in favor of wild promiscuity. When code isn’t shy, you’ll get unwanted coupling."

Something I see all the time, on every team I've been involved with, is code like the following (classes are generalized from examples):

myThing[] things = thingManager.getThingList();
for (int i = 0; i < things.length; i++) {
  myThing thing = things[i];
  if (thing.getName().equals(thingName)) {
    return thingManager.delete(thing);
  }
}

This code is tightly coupled to the implementation of myThing in that it gets the name property, knows that it's a string, etc. This is a classic approach from the old days or procedural programming. It is NOT OO. How about:

myThing[] things = thingManager.getThingList();
for (int i = 0; i < things.length; i++) {
  myThing thing = things[i];
  if (thing.isNamed(thingName)) {
    return thingManager.delete(thing);
  }
}

This code still knows the details of myThing. Why should it? All it should know is how to ask a thing manager to delete a thing given its name:

return thingManager.deleteThingNamed(thingName);

thingManager is closer to MyThing, in fact they're likely packaged together, so it's not as bad for it to have somewhat more intimate knowledge of MyThing. This is just one example of the approach of treating objects like new age data structures: Ask an object for information about its state, process that, make decisions based on that, then do something to/with the object. In the above example, the code

• asks the thingManager for its list of things
• iterates through those things
• asks each one for its name
• checks if the name is what it is looking for
• if so it asks the thingManager to delete that thing

The proper approach is to ask the thingManager "Delete a thing named *this* if you have one. Let me know if you were able to do that." As a side note, writing code this way makes it much more understandable. Do you write code like the first snippet? If so, you're not doing OO! Stop telling people that you are. Or better, start doing OO. Better still, get your whole team doing OO.

Talk Back!

Have an opinion? Readers have already posted 14 comments about this weblog entry. Why not add yours?

RSS Feed

If you'd like to be notified whenever Dave Astels adds a new entry to his weblog, subscribe to his RSS feed.

Digg | del.icio.us | Reddit

About the Blogger

Dave Astels has been developing hardware and software solutions for more than 20 years in domains ranging from environment control systems to electrical energy trading systems to mass market products. Since the late 1980s he has been working exclusively with object technologies: a mix of C++, Smalltalk, Java, and some more obscure OOPLs. Since the late 1990s, he has been studying, using, evangelizing, and teaching Agile Development processes and practices. He has coauthored/authored two books for Prentice Hall: "A Practical Guide to eXtreme Programming" and "Test-Driven Development: A Practical Guide". He also edits the TDD edition of The Coad Letter, which is part of the Borland Development Network. He co-founded and runs Adaption Software, Inc. (www.adaptionsoft.com).