Conclusion

< Day Day Up >

Conclusion

This chapter covers the design process for complete systems. It focuses on combining several classes to build a system. This system is represented by UML class diagrams. The example in this chapter shows the first pass at creating a design and is not meant to be a finished design. Many iterations may be required to get the system model to the point where you are comfortable with it.

Implementing Some Blackjack Code

I recently came across a complete implementation of a blackjack game in the book Java 1.1 Developers Guide by Jamie Jaworski. If you would like to actually get your hands dirty and write some code to implement another blackjack design, you might want to pick up this good, compressive Java book.

In the next several chapters, we will explore in more detail the relationships between classes. Chapter 7, "Mastering Inheritance and Composition," covers the concepts of inheritance and composition and how they relate to each other.

< Day Day Up >

References

Gilbert, Stephen, and Bill McCarty. Object-Oriented Design in Java . The Waite Group, 1998.

Jaworski, Jamie. Java 1.1 Developers Guide . Sams Publishing, 1997.

Wrifs-Brock, R., B. Wilkerson, and L. Weiner. Designing Object-Oriented Software . Prentice-Hall, 1990.

Ambler, Scott. The Object Primer . Cambridge University Press, 1998.

Weisfeld, Matt and John Ciccozzi. "Software by Committee," Project Management Journal , volume 5, number 1. Pages 30 “36, September, 1999.

< Day Day Up >

Chapter 7. Mastering Inheritance and Composition

Inheritance and composition play major roles in the design of object-oriented (OO) systems. In fact, many of the most difficult and interesting design decisions come down to deciding between inheritance and composition.

Both inheritance and composition are mechanisms for reuse. Inheritance , as its name implies, involves inheriting attributes and behaviors from other classes. In this case, there is a true parent/child relationship. The child (or subclass) inherits directly from the parent (or superclass). Inheritance represents the is-a relationship that was introduced in Chapter 1, "Introduction to Object-Oriented Concepts." For example, a dog is a mammal.

Composition involves using other classes to build more complex classes. There is no parent/child relationship in this case. Basically, complex objects are composed of other objects. Composition represents a has-a relationship. For example, a car has an engine. Both the engine and the car are standalone objects. However, the car is a complex object that contains (has an) engine object. In fact, a child object might itself be composed of other objects; for example, the engine might include cylinders .

A Real-World Example

It might be helpful to explain the differences between is-a and has-a relationships based on terms from the relational database world. Is-a represents a hierarchical relationship between entity types (tables), whereas has-a represents a referential relationship.

When OO technologies first entered the mainstream, inheritance was all the rage. The fact that you could design a class once and then inherit functionality from it was considered the foremost advantage to using OO technologies. Reuse was the name of the game, and inheritance was the ultimate expression of reuse.

However, over the past several years the luster of inheritance has dulled a bit. In fact, if you listen to some people, inheritance should be avoided like the plague. It is interesting that inheritance, the once-shining star of OO technologies, has now become, in some circles, a sort of pariah. In their book Java Design , Peter Coad and Mark Mayfield have a complete chapter titled "Design with Composition Rather Than Inheritance." In fact, many object-based platforms do not even support true inheritance. Platforms such as the MS COM model are based on interface inheritance. Interface inheritance is covered in great detail in Chapter 8, "Frameworks and Reuse: Designing with Interfaces and Abstract Classes."

The good news is that the discussions about whether to use inheritance or composition are a natural progression toward some seasoned middle ground. As in all philosophical debates, there are fanatical people on both sides of the argument. Fortunately, as is normally the case, these heated discussions have led to a more sensible understanding of how to utilize the technologies.

For reasons that we will discuss later in this chapter, some people believe that inheritance should be avoided and composition should be the design method of choice. The argument is fairly complex and subtle. In actuality, both inheritance and composition are valid class design techniques, and they each have their proper place in the OO developer's toolkit.

The fact that inheritance is often misused and overused is more a result of a lack of understanding of what inheritance is all about than a fundamental flaw in using inheritance as a design strategy.

The bottom line is that inheritance and composition are both important techniques in building OO systems. Designers and developers simply need to take the time to understand the strengths and weaknesses of both and to use each in the proper contexts.

< Day Day Up >