I was discussing object oriented (OO) programming with someone who was working on a horrible piece of software with class names like StartSession. I’ll call him “Alice”. Naturally, when wading through these classes, he finds 400 line “methods” in classes which are merely OO façades around procedural modules. This is disappointing, but it’s all too common. If you think that StartSession is a good name for a class, someone has done a poor job of teaching OO to you.
I think part of the problem is that while there are some excellent university professors who do a fantastic job of teaching OO, many professors I took classes from had little to no real experience outside of the classroom, or those with experience clearly went back to teaching due to the old adage “those who can’t, teach”. Surprisingly, two of the best instructors I had were teaching COBOL. Both of them clearly had decades of real-world experience under their belts and it showed in the classroom. They understood their material, they understood the pitfalls, and taught us how to work within the constraints of the language.
Getting back to Alice, he told me about an idea he once implemented to make it clear to other programmers that OO classes can be thought of as responsible agents. One of the first classes he wrote for his work was named the AuthenticationFairy.
When people first learn OO programming, there’s often a struggle to explain to them what it is. One instructor I had tried to get students to model a Puppy class. Not even a Dog class. A Puppy class. Clearly a puppy might be viewed as an instance of a dog, but more importantly, even modeling a dog is pretty useless for OO programming. Not many programmers need to model animals in their projects. Instead, we’re modeling business processes and the latter is an abstract concept which can make explaining OO programming even harder to students who have no idea what a “business process” is. Teaching OO by getting students to model concrete things often doesn’t map too well to the real world.
I also hear people trying to explain objects by saying “objects are data with behaviors attached.” Well, yeah, I can see that, but what the hell does that mean? A key benefit of OO programming is encapsulation, and while I value implementation encapsulation more than data encapsulation, I do prefer that data be “read only” as much as possible (letting people see all of the data any step of the way is a great debugging tool). So to suggest that objects are data with behaviors attached is hinting that being promiscuous with data might be OK.
Alice’s way was different. Describing objects as responsible agents can tremendously help clear up misconceptions about designing classes. For example, imagine that you have a knowledgeable and motivated employee whose job it is to procure stuff. You go to your employee and say “don’t spend more than £80 and get me a three drawer filing cabinet before you leave work today.” That’s it. Don’t micromanage and tell this employee how to get that filing cabinet. Trust them to do their job.
Objects are often like that. They should be viewed as trusted experts. Alice’s AuthenticationFairy was an expert in authentication. You told the fairy who was authenticating and from where, and the fairy might dutifully produce a SessionGnome or laugh in your face. The SessionGnome, of course, was very protective of its data and if you tried to touch the data directly, it would whack you with a stick. You might ask it if the session is expired but don’t you dare try to look for yourself. Of course, if this is a Web-based app, the SessionGnome might have to examine cookies, fetch the data from memcached or look it up in a database. You don’t know and, more importantly, you shouldn’t care.
This closely ties into a problem I have with Object-Relational Mappers. Too often I see them tied so tightly to the database that instead of thinking of objects, you think in terms of tables. I still remember one written in Python where the the named attributes to the constructor mapped directly to the database field names. Need to change a field name or move that field to another table? Sucks to be you.
Stop thinking of objects as procedural code or data with behaviors attached. Think of them as trusted employees who have well defined jobs. Tell ‘em what to do and let ‘em do it. Don’t muck about in their desk drawers or tell them what mop to use. Just let them do it. You’ll find your OO systems much cleaner as a result.
I agree on the object relational mappers with you 100%. That's why I chose iBatis. It works with result sets, not tables. New field name or moved field. Only change the underlying queries, code stays the same.
You mention a dog class is bad because it really isn't real world and so I did "perldoc perlboot" and what do I find:
sub Cow::speak { print "a Cow goes moooo!\n"; } sub Horse::speak { print "a Horse goes neigh!\n"; } sub Sheep::speak { print "a Sheep goes baaaah!\n" }Cow::speak;
Horse::speak;
Sheep::speak;
Now, I understand why but I thought it a little funny.
I want to follow up and say...yes I agree with you as well.
OMG!
That sounds like a C programmer who started writing in C++ without understanding objects. An all too frequent occurrence.
I completely disagree with you about ORMs, of course, I don't believe in Enterprise databases (that is to say, I think they are magical creatures, quite unlike AuthenticationFairies), so it's not a problem in my world.
Danno: for the record (no pun intended), I do like ORMs and I find them extremely beneficial. However, there are some pretty serious trade-offs with many of them and regrettably, since most developers don't understand databases, they don't understand the trade-offs. It's only in understanding the limitations of ORMs can we make reasonable decisions about their use.
Nice article but tell me that you don't take yourself seriously enough to type the cedilla in façades.
I would argue that puppy is not an instance of dog, but it is a class of its own, preferably a subclass of dog. (house_broken = false; cuteness += 10;) Fido would be an instance.
See also: The Tell, Don't Ask principle
If we couldn't map a table to an object how could we work with database and objects?