What does Object-Oriented Design Mean to You?
In today's world, you're just as likely to see a resume that says object-oriented design as you are to see a bachelor's degree. After more than a dozen years of sitting on a shelf, it seems like suddenly people are interested in object-oriented programming. Perhaps that's because Microsoft .NET and Java languages are all purportedly object-oriented languages. It seems like everyone believes that, if they are using an object-oriented language, they're doing object-oriented design. Nothing could be farther than the truth, and here's why.
Object Oriented Languages Do Not Make Object Oriented Developers
Object oriented languages do not automatically make programmers into object-oriented developers. Saying that I'm an object-oriented developer because I've used an object-oriented language is like saying that, because I have a bottle of wine, I'm a wine connoisseur. (For the record, my knowledge of wine is red, white, and blush.)
An object-oriented language merely makes it easier for you to implement the good programming practices that you already know. You know to minimize the impact of changes through encapsulating your data and code together. You know that you should keep the code similar and minimize the dependencies between different sets of code. An object-oriented language facilitates these and other programming goals.
Becoming an object oriented developer means studying concepts and learning to apply them rather than simply learning a new language.
Objects Don't Make an Object Oriented Design
The funniest thing I have ever heard an interviewee say was, "I've created dozens of objects-yes, and I'm an object-oriented developer." It was funny because it made object-oriented programming sound like an accident. It wasn't something he thought about, but it was something that happened to him without his knowledge. That's about as far from being an object-oriented developer/designer as you can get.
In C#, it is mandatory to create objects. However, that doesn't mean that you're doing object-oriented development or design. It just means you're working within the requirements of the tool.
Object oriented design and development is a conscious thing. It's focusing on organizing information and code into meaningful objects that perform meaningful processes on data.
An Object is
One of the fundamental tenets of object-oriented programming is that an object is modeled after a real world concept. For instance, an object representing a dog might have a tail. The dog might perform the action of walking or eating. The object is modeled after its real world counterpart.
This works well with a concrete object; however, it gets more complex when dealing with abstract objects. For instance, catalog objects have products in them, they have methods that search for products, and they may also have other properties and methods that a physical catalog might not have. When you start to layer the properties and methods, the traditional physical objects begin to lose their focus and have trouble assigning those properties and methods.
One of the keys is to think of how the physical item would behave if it wasn't limited to the physical form. Focusing on the attributes it would take on in an electronic form can help you keep focus on where you put properties and methods.
Coupling and Cohesion
Two classic programming problems are coupling and cohesion. Coupling is a factor that, in general, should be minimized. Coupling refers to the interrelated aspects of different parts of code. Whenever you make one object dependent on another for its operation - or one system dependent on another for its operation, they are coupled. One problem with coupled systems or objects is that, when one changes, it exposes the other to potential problems.
When one object looks inside of another for its operation, rather than using defined interfaces, changes in the internal operation of that object can make the other object operate incorrectly. These subtle interactions between multiple objects can be difficult or impossible to locate.
The second problem is that coupled objects need to be changed together. Even if you avoid the debugging nightmare of not knowing which objects are related to one another, they must still change their function when the coupled objects change.
One obvious exception to the coupling rule is collections. Collections are necessarily coupled with the objects that they contain so that they can return specific type information. They are coupled in other ways as well, as they may need to rapidly create large numbers of instances of the objects they contain.
Like collections, there are other special situations when, used appropriately, coupling isn't a bad thing, and in ways that are clear to even the casual observer, coupling can be a necessary part of software development.
The most closely related concept to coupling is the concept of cohesion. Cohesion answers the question, should an object be one object or more than one object? A cohesive object is one that cannot easily be broken up into multiple objects. It is an object that has one clear purpose and one clear entity that it represents.
It is also applied to those situations when an underlying object is needed. For instance, if you have a dog object and a cat object, you have two objects that have many similarities. Without an underlying object that encapsulates that similar functionality, you risk rewriting the same code. Both cats and dogs are animals and mammals. As a result, a dog object may not be a cohesive object - unless it is derived from objects such as "mammal," which in turn is derived from "animal."
Conclusion
Object oriented design is more than a language. It's not some path that you can follow blindly. It's a winding road that requires concentration. However, there are rewards. Quicker development times, fewer defects in your code, and a more maintainable masterpiece can be yours if you can keep from falling off the path.
