This question came up in our CFUG meeting last month when I gave a CFC-101 presentation, but I was reminded of it again today while reading this article about Service-Oriented Architecture. Here’s the pertinent quote that caught my attention:
“The idea of SOA departs significantly from that of object oriented programming, which strongly suggests that you should bind data and its processing together. So, in object oriented programming style, every CD would come with its own player and they are not supposed to be separated. This sounds odd, but it’s the way we have built many software systems.”
In the context of the discussions we had at our CFUG meeting, this specifically came up when I was discussing the bean objects in the sample application I built. Several people thought they seemed too simple, and that I was leaving a bunch of methods out of the beans for the purposes of illustration. The beans actually were relatively “real-world” examples albeit limited in the number of attributes they contained. Some people were wondering where the view() or display() methods were, and how the data in the beans would actually get displayed, which is a rather fundamental error in logic (IMO anyway) with respect to how much objects should really know about themselves.
This debate actually ties in directly with the quote from the SOA article. While on the surface the quote may seem correct, there is something a bit off about it to me. In OOP we of course say that an object’s methods and its data are both contained within the object; this is a hallmark of OOP and one of the features that most distinguishes OOP from procedural programming. What isn’t so cut-and-dry, however, is exactly *which* methods should be contained within the object. Where does it make sense to start taking methods out of the object and create another object to act as a service layer?
Using the example from the article, should a CD object know how to play itself? Some would say yes, citing the self-contained mantra of OOP. I, on the other hand, would likely say no, a CD shouldn’t know how to play itself, any more than I would say a Person bean should know how to display itself.
Why would I say that? Because to me if you take the notion of self-contained objects too far, you’re breaking two of the other tenets of OOP, namely tight cohesion and loose coupling. If a CD knows how to play itself, that may be taking things one step too far because while all CD objects get played the same way, what if you want to feed your CD object to a different type of player in the future? Now obviously in other cases you *do* want to have polymorphic methods to handle things like this, so in the classic Shape object example, you might have a draw() method that gets implemented differently for a circle than it does for a square.
Let’s think about the CD again for a minute. Should a CD, LP, and cassette object each inherit from a single parent and have polymorphic play() methods? Or would it be better to have the media objects be just a bit more ignorant of themselves and have a service-type object, such as a Player, handle the play() method based on the media given to it?
As with so much in OOP, the answer is “it depends.” In the case of something like a Person bean, if you have a display() method within the bean itself you’re severely limiting its usefulness and the overall flexibility of the bean. Better to have a slightly more dumbed-down bean that can be used by multiple front-ends through a service architecture of sorts.
At any rate, this thought came back to me while reading this article, and it’s something we have to be mindful of as we build object-oriented systems. There are no hard-and-fast rules but certain ways of doing things make more sense than others, and we should always be mindful of making our objects as reusable as possible. If you want to display a Person in more than one way, or you want to play a CD on more than one type of player (e.g. standard player vs. computer drive), then consider dumbing down your objects a bit and creating a service object to handle things. This can make for a far more flexible system than can more easily be expanded in the future.