Excellent article that quickly distills key OOAD concepts. Such as:
A common practice for jump starting OO analysis is to look at the use case or stories for nouns. These nouns will be our first set of objects, often referred to as “Business Objects”, because they reflect or often trace back directly to real business entities. As the set of business objects grows, we start to try to understand their relationship with each other. While this is a good exercise in analysis to better understand the relationships of the business, too often the analysis is what is implemented. The situation is made easier and more comfortable by the fact that the same type of activity is conducted by the DBA coming up with initial crack at the schema. However, OO is about behavior not structure.
That last line is pretty important, imho, as it is one of my personal stumbling blocks – that thing I keep having to remind myself of because my background is data-model and analysis centric.
Other nice things to remember that are also quite basic (thus things that I forget about when I’ve been in a deep development cycle and am transitioning back to analysis and design) are:
Barbara Liskov in conjunction with Jeannette Wing presented in 1993 a paper entitled Family Values: A Behavioral Notion of Subtyping containing the liskov substitution principle. The principle states “If for each object o1 of type S there is an object o2 of type T such that for all programs P defined in terms of T, the behavior of P is unchanged when o1 is substituted for o2, then S is a subtype of T. [Liskov88]”. WOW! Read that a few times fast… Basically restated; an instance of an extension of a class, should be able to be passed to a method expecting the base class with no consequence or side effect. This principle is at the heart of good inheritance. By following this principle designs begin to be extensible, which brings us to the next principle.
Open / Close Principle
Coined by Bertrand Meyer, and expounded upon by Robert C. Martin, the open-close principle basically means that units of code, namely classes and methods, are open for extension and closed for modification. This principle works congruently with the substitution principle. Applying this principle, code is closed to modification… If change is required the only solution is to extend. Of course it takes a significant amount of design effort to reach this level of maturity; the benefits being a significant resilience to change.
Overall a good article for those new to OOAD and for anyone like myself that needs frequent refreshers