Is Object-Oriented Analysis & Design appropriate for the common business application?

Why Object-Oriented Design

The number one reason to employ an OO design when building software is to reduce complexity. The point is that often OO is not used because people think it adds too much complexity. I like the plain English translation from business knowledge to a business object design. When my business expert and I are trying to figure out why interest payments paid on a structured note is sometimes off, and that she noticed it on the reports and on the website, I can translate what we are talking about straight to business objects. If the expert says a structured note pays interest then I can go to the Structured Note business object and find the logic that deals with figuring out the interest payment. As the two of us talk about the business, the language we use reflects real life and the software with minimal translation. The book Domain-Driven Design by Eric Evans is all about this advantage of OO design and he heavily stresses the need for a ubiquitous language used whenever talking or writing about the business.

Furthermore, this type of design organizes things well and lends itself to simple diagramming and other modeling techniques to make it easier to “white board” things with other engineers and business experts. This is simply because the system is broken down in to smaller, self-contained parts. Parts that can be analyzed, tested and understood independent of the other parts. This makes the parts like smooth painted wooden blocks that are a joy to build with compared to wooden chunks cut from a tree. When maintaining or extending an OO application we can often find our way through the code thanks to logical relationships between things (like a User Account and Password) because the real-life relationships are also modeled. Anti-OO procedural-coding advocates often argue that everything achieved in OO can be achieved in procedure code. However, in this case they tend to just focus on cohesion, coupling, and data hiding. These are great benefits of a good design, but OO languages have many built-in constructs that facilitate these benefits as opposed to relying on coders to do them correctly. A separation of concerns is our greatest ally in dealing with complex code, why not use a language and design method geared toward this exact thing!

Creating abstractions of concepts using classes allows us a clean way to hide implementation and divide and conquer complex things while maintaining a simpler programming interface as all the nuances don't need to be thought about at once.

Dividing our information into objects that match the real world forms an organizational framework that at its higher levels is more stable when compared to software organized around data or functions. Granted OO is about putting functions with the data, but an object model, a business object model is first and foremost all about those objects. The data and functions are less stable than the objects.

Tesler's Law of Conservation of Complexity: You cannot reduce the complexity of a given task beyond a certain point. Once you've reached that point, you can only shift the burden around. (Larry Tesler) It is this shifting around coupled with dividing system intelligence that OO developers use to produce simpler programs dealing with complex relationships and logic.

When we adhere to OO design heuristics, or as many as we can, we gain confidence that our system is not fragile and destined to break as we change code. Following rules of encapsulation we are confident that changes affect only small portions of our code. Writing cohesive objects makes the division of complex elements easy to manage as we divide and conquer systems into smaller and more understandable parts

It is true that OO design is not a cure-all for our programming woes. As it is often said, a bad programmer using OO methods can create software that is just as bad as a bad programmer using procedural coding methods. Common pitfalls to the OO developer include inheritance frenzy, ravioli, and Micro-OO.

Inheritance Frenzy

Inheritance Frenzy occurs often when a novice OO developer is fascinated by the powerful inheritance relationship. Before you know it everything IS something else and when I load a Person Object from the database it also loads up all the Human Object data which also loads up all the Mammal Object data, etc, etc. Classes start inheriting functions and properties that don’t quite match the abstraction they represent and methods are overridden left and right. This is not a fault of OO design but a common mistake when modeling a business.

Micro-OO

Micro-OO is a term refers to the introduction of complex patterns to solve “problems.” This is not meant to be a dig at the use of design patterns, but the overuse of “elegant” solutions that encapsulate OO techniques but only add to the complexity of things.  This is a type of over-engineering where creative minds in search of a neat solution get carried away. 

Summary

The short answer to the question, “Why Object Oriented Design?” is simply to reduce complexity. When a business is already complex by nature, it is only beneficial to make the software representing that business use an OO design to help manage that complexity. Testing, debugging and extending applications can be complex, an OO design helps reduce this kind of complexity as well.