3.8 Examining the Use of Separate Entity and Controller Classes

The object-oriented community needs to examine carefully the roles of controller and agent classes in object-oriented design. While it is easier to migrate legacy systems using a technique of separating the entity classes (model) from their behavior (controller), in practice it leads to the artificial separation of data and behavior. This separation should be considered a violation of a fundamental principle of the object-oriented paradigm, namely, data and behavior are bidirectionally related as a conceptual block. The artificial separation is often encouraged by the fact that in business modeling, it often occurs that different applications will use the same data model differently. This often leads the designer to create entity classes to model the data and separate controller classes which work with the data model in different ways.

Consider the design of a media-based framework for a company with which I have recently worked. This company has many applications that work on an abstraction known in the media industry as a composition. The composition class contains a number of different items which together describe an edited work of film, or more generally , media. The data model can be easily reused in all of the applications. The problem is that it performs different functionality from one application to another. For example, when used by the editing application, it needs to support the functionality X, Y, Z; but when used by the playing application, it needs to support the functionality P, Q, R. As Figure 3.19 shows, the design of such a system via controller classes would argue for entity classes to support the composition class and its pieces and hierarchies, and two controller classes for handling the different functionality.

Figure 3.19. Reuse of entity classes via controller classes.

The problem with this design is that I can no longer examine a piece of data and ask, "Who is dependent on you?" I will now need to examine each of the controller classes to determine dependencies. How does this differ from having a behaviorless database schema and a collection of applications that possess all of the behavior? I argue that the popularity of controller classes is directly related to their semantic proximity to the action-oriented paradigm. In fact, they have some of the same problems as that paradigm, such as undefined data/behavior dependencies.

A better design is to state that the composition class has six behaviors in its public interface (i.e., P, Q, R, X, Y, and Z); see Figure 3.20. The fact that a given application uses only half the public interface is irrelevant. There is no heuristic stating that a user of class needs use its entire public interface. I have a linked list class with 30 operations. It is not an error if you only want to use insert, delete, and traverse. What is relevant is that each application does not want to pay for the object code of operations it does not use. This is not a design issue (logical design) but a source-code maintenance issue (physical design). Do not throw away a better logical design for a simple physical design issue.

Figure 3.20. A better design for the composition class.

A more subjective reason for avoiding the entity/controller form of design is that humans do not like controllers in the real world. When is the last time you misplaced the controller for your refrigerator, stove , car, or overhead projector? We cannot misplace them, because data and behavior are encapsulated into the same package. Of course, there are real-world examples that do separate the controller from the data. I argue that all of these cases are not because of human preference but because of cost. The classic example is the videocassette recorder and its prerecorded tapes. We buy a VCR player (the controller) and then purchase or rent the VCR tapes (the entities) separately. I believe that this is due to the fact that the controller is extremely expensive (a physical design issue) and not by choice. Humans would prefer that each tape come with its own player, thereby encapsulating the controller and entity information in one package. At times when traveling, I would like to rent a movie but cannot because I left my controller at home.

In a recent lecture, the VCR explanation caused one skeptic to shout that the thought of each VCR tape having its own controller was ridiculous. Another student responded that it was almost as ridiculous as the thought of people wanting a camera (a controller) and its film (the entity) in one neat little package. (Today the demand for disposable cameras is rising as the price decreases.) Several hours after the controller class discussion, the lightbulb of the overhead project burnt out and we needed to wait 15 minutes for a replacement. This led one of the students to comment that I would probably prefer that each overhead have its own behavior rather than relying on an external controller. I would have to agree!