Objects 101 - Data that happens to have behavior, or behavior that happens to have data?
Preface: If you are from Magenic, you probably know this already.
Here at Magenic, we have this great class called “Magenic U”. A mix of acculturation, training, and boot camp, all mixed in one, the end result is that it gives you a great sense of what sets us apart from our competition. While a “great things about Magenic” could be covered in a different, very self-serving “fan boi”-ish post - this post is really about the most important lesson I learned at Magenic U, courtesy of Rocky Lhotka.
A big reason I was an “object skeptic” for a very long time - was the fact that every OO implementation I have ever seen involved objects that merely replicated a data schema that the system ultimatley acted on. And for good reason - the data schema is, next to the UI itself, the biggest implementation detail the sponsor of a project often see. This is, of course, usually because the reporting system is the preferred method of system enhancement. That is, most organizations to add functionality and views to to the system that the original designers of the system did not originally intend - because it is typically, though not correctly, understood that reporting systems only read the system, but don't impact it. While most DBAs - and others who know about index, load, and other performance problems will argue this point vehemently (and correctly) - it is regardless, seen as less risky to add a report than to, say, add functionality to a screen and touch some of that yucky C++ code that the organization does not really understand.
Because of this, the data first view of systems will usually trickle into the object model. When a certain paradigm of system understanding is held by the sponsors (e.g. those with power) - it should not suprise anyone that the sponsor preferred mode of communication makes it into the application design. The fact that the vast, vast majority of business software developers also think this way results in the “data first” method of object design being dominant.
But that does not make it correct, or most efficient.
Almost every single data first object implementation results in “data objects” that happen to have a set of unrelated behaviors grafted onto them. This causes object bloat - which over time, creates a behavior mix of unrelated behaviors that, if you are not very careful, creates side effects. This is often called the “God Object Problem”. At it makes sense - the more something does, the harder it becomes to isolate any particular thing.
This, among other reasons, is why you build behavior based objects. As in, literally, you might have a ReadOnly version of an object for use in Combo boxes, a read/write version for use in a data entry screen, and perhaps another version for use in reports. Have business rules common to multiple versions of those objects? Use dependency injection or strategy to implement the rules. The benefit is you end up with true objects that do one thing well, giving up a little “repeat” coding you might have to do if, for example, you add a property to something that spans more than one behavior based object.
Is this compatible with NHibernate or other similar ORM approaches? Hell yes! There is no reason why you can't use those platforms for your persist mechanism. You might use them in multiple places, but you can easily use them nonetheless.
Now, at some point, the idea of mixins might be able to integrate with this concept in order to add behavior to objects. But until that becomes something you can easily do (at least on the .net platform, I can't speak for Ruby/Scheme/et al.) - this approach certainly does a great job of solving the “God Object” problem.