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.
No comments:
Post a Comment