Anatomy of Object Oriented Design

A colleague of mine has a (good) habit of frequently questioning the way we design our applications.

We tend to write a lot of data-driven applications, and stick to a pretty consistent n-tier architecture.  As such, we also write a lot of pseudo-object-oriented code; I say pseudo-object-oriented, since we certainly don’t stick to pure object-oriented design principles.  Data and functionality has a clear divide, with a hierarchy of objects used to represent the state of the application, and another hierarchy of objects used to manipulate that state.  This is in contrast to pure object-oriented design, where domain objects should have both state and behaviour, providing proper abstractions between the domain and underlying functionality.

My colleague drew my attention to an article about classes that end with -ER.  There are also plenty more of these kinds of articles about the internet.

After reading this and a few other articles, I had a think about our use of objects ending in -ER (managers, controllers, helpers, etc.).   Most of what we implement ends up in some kind of procedural/object-oriented mashup, likely as a bi-product of using these -ER classes, but also because of our focus on separating state from behaviour.

I feel an experiment is in order to implement two identical systems using both my current data-driven, n-tier approach, and a pure object-oriented approach.  This should help me compare some different techniques in software design, and hopefully provide some insight on pros and cons of different approaches.

Over the coming weeks (and months, perhaps) I will attempt to implement a representation of the human anatomy, using both an n-tier, data/domain-driven architecture design approach and a pure object-oriented approach.  I will make the code available on Github, and provide a link here if anyone is interested in following along…