September 9th, 2007
A common question encountered in VB related forums, where some members are new to OOP, concerns what criteria one should use to discover the objects that fit into your solution’s design. In this article, we will look at several methods you can use to identify objects from your requirements. I’m going to take an Eastern approach so brew yourself a cup of green tea first and then start reading.
It is like a finger pointing away to the moon. Do not concentrate on the finger or you will miss all that heavenly glory. - Bruce Lee
To often programmers become fixated on the particulars of the code. For example, how they should write a Create, Update, Read, and Delete (CRUD) sequence or if they should use an integer or a long for a particular property. This is ‘concentrating on the finger’ when it comes to discovering objects. At this point in the design, don’t focus on how you will implement the particulars. Instead, look at the whole of the object and how it interacts with other objects in the system and the world at large.
The pine’s shadow is dark
Exactly as the moonlight is bright. - Kodo Sawaki
One objective in object discovery is to discover commonality between your objects. Sometimes this may not be entirely obvious so it requires one to let go of the obvious at look at things a different way. The goal is to find these points of intersection and, where applicable, use an abstract base class or interface to express this relationship.
One moon shows in every pool, in every pool the one moon. - Zen saying
Another idea along the same lines as the last is to look for things that are duplicated in the design and how they’re duplicated. This will often suggest objects and relationships between objects that you can use in various ways.
In thinking, keep to the simple. - Lao-tzu
Look for the least common denominator, the smallest unit, in your system. A common problem is defining an object too large and then having to break it down into smaller parts. This can result in bad code. Try to do this analysis early on in your design to prevent such problems.
When you have names and forms, know that they are provisional. - Lao-tzu
Separate methods and properties that will change from those that won’t change. Of course, change is almost inevitable but you can make educated judgments as to which things are the most likely to change. Try to keep the elements that will change out of your base classes and interfaces as much as possible. This process can help you further define and separate them.
We shape clay into a pot,
but it is the emptiness inside
that holds whatever we want. - Lao-tzu
Examine the data your system will need to access, particularly if you’re working with legacy data or a pre-existing database design. This will often suggest objects or additions to your existing objects.
When people see some things as beautiful, other things become ugly.
When people see some things as good, other things become bad.
Being and non-being create each other. - Lao-tzu
Imagine your classes as though they already existed and consider situations where you might use an instance of them. How would you write your code to work with them? What would their constructor and destructor routines (New and Finalize in VB.NET) need? What methods and properties would you need? Do you think the object could be extended easily? How tightly is it tied to your other objects? If you needed to write a subclass could this class act as a base class without a lot of trouble? This kind of exercise can help you find flaws in your design early on as well as suggesting relationships and needs that you might otherwise miss.
I hope that you found this article useful in getting you started on discovering objects within your design. Let me know what you think or if you have any questions by leaving me a comment.
Entry Filed under: Tip Sheets
Rate This Article: