H.S. Lahman on OO and MDA

1.0 Association Basics

Blog root page
next post in category

Relationships are very important to OO development. They provide a basic structure for collaboration. Perhaps more important, they allow business rules and policies to be enforced through static structure in the application rather than explicitly in executable program statements. This can result in a significant reduction in the amount of code. That, in turn, can improve reliability be reducing the number of opportunities to insert defects. Finally, separating relationship instantiation from relationship navigation (addressing messages) can lead to a more robust and maintainable application. Therefore it is important to get relationships right in the OOA/D.

There are two broad categories of relationships in OO development: associations and subclassing. The remainder of this post is concerned with associations. Another set of posts will deal with subclassing relationships.

An OO association defines rules for participation in collaborations. That is, a relationship in a Class Model defines constraints on which members of two classes are allowed to collaborate. Those constraints are basic static structural features of the application. Relationships are described by four characteristics.

Identity. Each relationship has a unique identity. In UML this is a name, known as a discriminator, attached to the relationship. This identity is typically only necesasary in translation systems that do full automatic code generation from PIM models. Otherwise, its main use lies in communicating among team members.

Multiplicity. Each relationship end indicates how many participants of that class are allowed for each participant at the other end of the relationship. The crucial consideration is whether there may be only exactly one participant or whether there can be multiple participants. In PIM modeling this is all that matters, so in UML the possible "values" of multiplicity are '1' or '*' (read as: one or more). This is important because in the Relational Data Model exactly one participant is handled differently than multiple participants. As a practical matter, it means that in the implementation one must support either a single reference or a collection of references.

UML allows one to define multiple participants more explictly (e.g., '5'). However, that is only relevant to addressing nonfunctional requirements. Such information is useful for optimizing the kind of collection one uses and how one manages memory. So that sort of information is relevant to OOD models that are PSMs created from a PIM, but not to the PIM itself.

Conditionality. Each relationship end indicates whether participation by members of the class at that end is mandatory or not. The default is manditory (unconditional) participation. In UML one indicates a conditional relationship be prefixing the multiplicity with "0.." as in 0..1 or 0..* (read as: zero or more). Conditionality is important because conditional relationships require code to be supplied to test whether the relationship is active or not and that code must be supplied in every context where the relationship is navigated. Such code is ususally undesirable so I will address how to reify conditional relationships to make them unconditional in a subsequent post.

Role. In UML each relationship end has an associated text qualifier that describes the role that the participants at that end play relative to the participants at the other end. Roles have no effect on the implementation of a PIM, but they are extremely important to communicating how the PIM relates to the problem space.

While some authors suggest that a role only needs to be placed on one side of the relationship, I am a strong advocate of placing roles on both sides. To make dual roles useful they each need to capture something unique and useful relevant to the problem in hand. In particular, symmetric roles -- such as "creates", "is created by" -- should be avoided because the second role adds no new insight. Often the exercise of uncovering unique roles will improve one's understanding of the problem space and it will certainly improve the understanding of the maintainers who will follow.

The notion of roles segues into the more general topic of identifying relationships. Ultimately all relationships are abstracted from the problem domain. When one looks for relationships one seeks logical connections between classes of entities. While an OOA/D relationship is used as a vehicle for rigorous constraint specification for participation, the existence of the relationship itself is a matter of logical connection. Roles provide a bridge between that logical connection in the problem domain and the constraints on the connection in the computing space.

Though UML supports notation for three or more participating classes, only binary associations are in the PIM profiles, at least for translation. That's because the UML notation for ternary and higher associations is ambiguous in some implementation contexts and requires specific decisions to be made during the implementation. So a PIM association should be a connection between exactly two classes. However, an association can be reflexive (i.e., members of a single class are related to other members of the same class). This still qualifies as binary because the individual members are not related to themselves.

One should only identify the minimum set of relationships that one needs to solve the problem. In practice what this means is that there should be a path of binary associations between any two classes whose members need to collaborate. (This is a necessary condition, but sometimes not sufficent.) So one should proceed systemmatically from the most obvious to the least obvious. Clearly the most obvious connections are those where a physical connection exists in the problem domain (e.g., tracks between railroad stations). After that it is a matter of what connections seem more prominent in the problem space.

Blog root page
next post in category

3.0 Subclassing

Blog root page
previous post in category
next post in category

Subclassing is a very simple concept but it is one of the most poorly understood in OO development. The problem is that people tend to merge together subclassing, inheritance, and polymorphism when talking about subclassing. (It gets even worse in an OOPL context where subtyping is introduced.) The reality is that subclassing, inheritance, and polymorphism are three entirely different things. While some are enabled by others in an OO context, they should be kept straight in one's mind.

Subclassing. Subclassing is about set membership. A class defines a set of entities. The set is defined in terms of properties that every member of the set has. No member of the set may have fewer properties than the other members of the set have. However, some members of the class may have additional properties. In that case, all members who have exactly the same additional properties comprise a subset of the members of the original class. We can associate that subset of members with a new class that defines the additional properties that they uniquely share in addition to the properties already identified for the original class (called a superclass) from which the subset was derived.

That's it folks! That's all there is to subclassing. The tree diagram we see in an UML Class Diagram just keeps track of sets of members. For those of you who did not sleep through your set theory classes, an OO subclassing relationship is just a Venn Diagram in tree form that defines boundaries around entities (dots on the Venn Diagram) in terms of superclasses and subclasses. The reason we use the tree display is because it makes it easier to explicitly keep track of the properties that define the classes. (To include the specific properties in a Venn Diagram rather than entities would create a topological problem that only a mathematician could love.)

However, there is a special feature unique to OO subclassing. If you have any experience with Data Modeling, please forget it because OO subclassing represents a very major divergence from Data Modeling. That difference lies in instantiating objects. In Data Modeling, each class can be instantiated independently and the subclassing relationship represents a special sort of association between the entities instantiated in each set. That is not the case for OO subclassing. In the OO situation only one object at a time is instantiated for the entire the tree. That object is always a member of a particular leaf subclass in the tree and its properties represent the union of all properties in a direct line of ascent to the root superclass. This is why an OO subclassing relationship is commonly called an is-a relationship. Every object IS A member of every set in the line of ascent.

[Some brain-dead languages like C++ allow one to create instances of superclasses. Essentially this is an unrestricted license for foot-shooting. Don't do that!]

Inheritance. Inheritance is an equally simple concept. Because only one object at a time is instantiated for the entire tree, we need a set of rules for determining exactly what the object's properties are. Inheritance supplies those rules. They are also childishly simple: the properties are the union I mentioned above. So all one has to do is run one's finger up the line of ascent from the subclass to the root superclass and one has all the properties. That's all there is to inheritance; nothing more! It happens to be enabled by OO's unique view of instantiation and the use of the handy tree format that conveniently organizes the properties for us.

polymorphism. There are actually several different sorts of polymorphism available in OO development and the one relevant in this context is known as inclusion polymorphism. The basic idea if someone is accessing a property defined in a superclass (i.e., that all members of descending subclasses have), one can substitute the implementation of that property between subclasses. Thus a member of one subclass can have a different implementation of the property than a member of another subclass derived from the given superclass. That is transparent to the client doing the accessing because it doesn't know which subclass is in hand; the client only "sees" the superclass.

This is usually not terribly interesting for knowledge responsibilities because there are only so many ways to implement a data value. However, when dealing with behavior responsibilities this can be an enormously powerful tool because we can be quite liberal about what we mean by implementation. For example:

           1           attacks 1
[Predator] --------------------- [Prey]
                                +attacked()
                                   A
                                   |
              +--------------------+----------------+
              |                    |                |
        [Brontosaurus]         [Gazelle]        [Pheasant]
           +stomp()              +run()        +takeFlight()

Here the superclass [Prey] defines a behavior responsibility that all members of the class have. However, each subclass may implement that responsibility quite differently, as indicated. [I have taken some liberties with the UML notation here in addition to geologic time. UML allows the substitution semantics but not so vividly.] In effect the "implementation" for the attacked() behavior is very different to the point where one is really substituting behaviors rather than simple implementations (e.g., different implementations of a linear programming algorithm).

This ability to substitute behaviors transparently for the client is a very powerful technique, especially for reifying complex *:* relationships in OOD/P. [One can argue that all the patterns in the GoF book ("Design Patterns" by Gamma et al) exist to reify *:* relationships where participation in complex and dynamic.] It is also very useful for dependency management during OOP to overcome the physical coupling problems shared by most OOPLs. However, it isn't very common in OOA because the notion of behavioral substitution is pretty rare in most customer problem spaces.

The key concept behind inclusion polymorphism is also quite simple. One simply substitutes behaviors between subclasses by providing access through a common superclass interface that is accessed by clients. It is enabled by the OO view of both subclassing, where the properties are defined and organized, and inheritance, which provides the rules for determining which substitution is made.

Before leaving the general topic of subclassing, let me point out two important rules that apply rather uniquely to good OOA/D practice:

The members of a subclass must be a disjoint set relative to other subclasses of the same superclass.

The union of all subclass' members must be a complete set of the members of the superclass.

The first rule essentially means that an object cannot be a member of two different subsets in direct line of descent from one superclass. The second rule means that one cannot create a object that just has superclass properties as a superclass instance. The rationale behind both these rules is that they allow unambiguous mapping when resolving access to properties when employing polymorphic access and they limit the opportunities for inserting defects when doing maintenance. The examples where one gets into trouble tend to convoluted and involve LSP (Liskov Substitution Principle), so I won't go into them here and you will have to trust me on this.

Blog root page
previous post in category
next post in category

2.0 Removing conditional ends

Blog root page
previous post in category
next post in category

Conditional ends on associations should be avoided whenever there is a reasonable alternative. There are a couple of reasons for this. One is that when a conditional association is navigated there will have to be check in the code to test if the relationship has actually been instantiated. Because one employs peer-to-peer collaboration in OO development, the peers have to traverse relationship paths through the Class Diagram. Thus the same relationship may be in many paths between different peer objects and that testing can result in significant overhead.

More important, though, is that very often more is involved than a simple test for a NULL pointer. Quite often there has to be an "else" clause to deal properly with the situation where the relationship is not instantiated. That is essentially exception processing and generally the solution will be simpler if one can avoid dealing explicitly with exceptions. So one should seek a way to express relationships without conditional ends. If one is successful, then the application will be more robust because one is enforcing problem space business rules and policies in the static structure of the application rather than in dynamic code.

As an example, consider the common example of a hierarchical tree:

         0..1    navigates 1        0..1 child of
[Client] ------------------- [Node] ------------+
                               | 0..*           |
                               | parent of      |
                               |                |
                               +----------------+

In this case every instantiated association will have two condition ends except for one and that one will have one conditional end. The actual code to implement this will become convoluted if the leaf Nodes in the tree are somehow different than the upper Nodes -- which is quite common for things like POS web sites where the hierarchy exists to navigate to the leaf items.

One way to get around this is by distinguishing between the types of nodes in the tree:

                    * parent of
             [Node] -------------------------+
                A                            |
                |                            |
   +------------+-----------+                |
   |                        |                |
[Leaf]                   [Parent] -----------+
                            A     1 child of
                            |
                  +---------+--------+
                  |                  |
               [Root]          [Intermediate]
                1 |
navigates through |
                  |
                  |
        entry for |
                1 |
               [Client]

Now there are no conditional ends. All of the rules of a hierarchical structure have been explicitly expressed in through the subclassing and associations.

But wait! How does the Client know when it has reached a Leaf? The short answer is because the Leaf won't have any parent/child association. So the key question becomes: how is having no association different in practice from having a NULL instantiation of the association? The answer to that is complicated and it gets to the heart of the notion of enforcing business rules in static relationships.

The difference is that we have made having a parent/child relationship an intrinsic property of the entity; Leafs have no children but Parents do always. So if we have a "type" attribute for Node that indicates {LEAF, PARENT}, the client can check that during navigation. [Note that the type attribute is not semantically equivalent to the subclass type. For one thing, it does not distinguish Root vs. Intermediate. It could just as easily have been {NO_CHILDREN, CHILDREN}.]

But aren't we back to testing something to determine how to navigate? Not quite. The reason is that the semantics is not the same. We are testing an intrinsic property of the object, not the conditions under which two objects collaborate. That property is relevant to the nature of collaboration, not participation in the collaboration. While that is a subtle distinction, it has important implications in principle for the complexity and robustness of the dynamic solution.

To see this we must note how much better the second diagram describes the hierarchical tree than the first diagram. Basically we have been much more explicit about the way that hierarchical trees actually work. The Client is going to navigate the tree for some purpose. It may want to get to a particular Leaf. It may want to do a guided search where someone else selects the next node to traverse. It may want to do some complex processing at every Node, possibly even reordering the tree itself. (As an extreme example, consider the Parent Nodes are logical operators, the Leaf Nodes are logic states, the tree itself is an arbitrary RPN representation of a logical expression, and the goal is to reorganize it so that the Leafs are grouped into the minimum sum of products.)

These are quite disparate purposes and the processing will be quite different. Yet all of those algorithms can be expressed in terms of Node properties, regardless of the collaborations that "walk" the tree. More to the point, the mechanics of "walking" the tree is done the same way in all cases. What we have done is to convert the orthogonal issue of relationship navigation into a problem of manipulating intrinsic object properties.

The kernel issue here is that relationship instantiation is orthogonal to relationship navigation. We instantiate relationships to define participation (i.e., constrain the allowed participants in collaborations). We navigate relationships to execute peer-to-peer collaborations. Generally the rules and policies for participation are different than those for collaboration. Therefore, in principle, we want to separate and encapsulate those concerns because doing so will usually provide greater robustness.

Checking if an association is NULL is an instantiation issue and when objects collaborate they should only be concerned with the issues around collaboration. And collaboration is about accessing intrinsic knowledge and behavior responsibilities. Therefore, if we express any problem solution decisions in terms of intrinsic object properties, collaborating objects do not need to be concerned with instantiation issues and that is a Good Thing.

This all sounds nice, but does it have any practical significance? I assert that if you eliminate conditional association ends, your dynamic problem solution will very often be simpler. More important, when you have to change the solution it will be easier to do so. But such assertions defy proof because they are based upon practical experience. However, I can offer an example.

There is always some sort of processing associated with hierarchical trees. As I indicated above, such processing (object collaborations) may be profoundly different in different contexts. OTOH, the actual traversal mechanics is the same because it is dictated by the tree structure (relationships). An obvious way to manage complexity is to separate the traversal algorithm itself from the processing done as the Nodes are accessed. In the first diagram the only place to put that traversal algorithm is in the Client. In the second diagram a much more logical place for it is in the Root Node.

The significance of that will become even more apparent if there are multiple Clients that access the tree for different purposes. It would clearly be very fragile for each client to encode the traversal algorithm in addition to its own view of the processing; if the tree itself were modified (e.g., converted to a B-Tree), each client would have to be modified. That separation of traversal concerns only becomes obvious in the second diagram. IOW, removing the conditional ends creates a structure where the separation of disparate rules and policies becomes obvious.

A final cautionary thought. One should always evaluate ways to remove conditionality in association ends but that doesn't mean one should always do so. Sometimes the conditionality is a problem space imperative that one must level with. More to the point, though, is that there is a tradeoff. The second diagram above is more complicated in a static sense. While it may lead to a less complex or more robust dynamic solution, that benefit may not be worth the price of the additional complexity -- especially when the basic problem is very simple.

Blog root page
previous post in category
next post in category

4.0 Compound subclassing

Blog root page
Previous post in category
next post in category

Compound subclassing (aka multi-directional subclassing) occurs when the same class is the root superclass for two different subclassing relationships:

[Screw] -------+                   +----------- [StockItem]
+threadSize    |                   |            + quantity
               |                   |
            R1 +---|> [Part] <|----+ R2
               |                   |
               |                   |
[Washer] ------+                   +----------- [SpecialOrder]
+diameter                                       +leadTime

Here we can subclass [Part] in two quite different ways. The interesting issue here is: What properties does a Part object have? That depends upon whether the relationships are joint or disjoint. (Though the subsets of each individual relationship are constrained to be disjoint, the subsets across relationships are not so constrained.) In UML whether they are disjoint or not is determined from the relationship names (discriminators R1 and R2 in this case). If the names are different, that indicates the relationships are joint (i.e., the union of members of each relationship's subclasses is the same as the union of members of the other relationship's subclasses). In that case the actual object properties are determined in a combinatorial fashion. Thus every Part instance will be one of the combinations: {Screw, StockItem}, {Screw, SpecialOrder}, {Washer, StockItem}, or {Washer, SpecialOrder} and will have all of the properties of the combination.

If the names are the same (e.g., both discriminators might be "R7"), that means the relationships are disjoint (i.e., each subclass represent a unique subset of [Part] members). Thus every Part instance must be a member of exactly one subclass from one relationship. This form is rather uncommon because one could just as easily create a single disjoint subclassing relationship. It is also uncommon because it implies a Part is needed in two very different contexts (e.g., POS catalogue descriptions vs. inventory control). Given the need to properly partition the application based on cohesive subject matters (see Application partitioning category), this is rather unlikely.

[The joint case can also be reified to a single subclassing relationship where the subclasses are identified combinatorially. However, that can get out of hand quickly when there are lots of combinations. (If each relationship had four subclasses there would be sixteen combinations.) Thus the joint case tends to be more common because it compacts the model.]

Blog root page
previous post in category
next post in category

Association Classes

Blog root page
Previous post in category

In UML one can qualify a relationship with a special class, the Association Class. Association classes are required for associations with *:* multiplicity and they can be used for any association, even those that are 1:1. They are required for *:* relationships because in the relational data model there is no way to associate multiple referential keys in one association participants. For one thing, the number of participants in each instance of the relationship may vary. In the example below, each Class may have a different number of Students and each Student may register for a different number of classes. That gets messy to define statically in terms of attributes.

Thus the association class is a placeholder for a more complex entity that keeps track of the participants. In an RDB that "entity" would be implemented as one or more table indices. However, in OO development we usually implement association classes from the OOA as multiple relationships in OOD and/or OOP (a process known as reification). This has significant implications for the way one constructs software in an OO fashion compared to a procedural/relational fashion that I will get to in a moment. But first some basics.

The most common reification of a *:* relationship is from:

               [Registration]

                     |

                     |

        *            |           *

[Class] -------------------------- [Student]

to:

        *             1                1                *

[Class] --------------- [Registration] ------------------ [Student]

In this case the *:* association has been replaced with two 1:* relationships. There is an instance of [Registration] for each [Class] member and each [Student] member. Each such instance of [Registration] is essentially a collection of handles to the other participants in the association. There are other alternatives for reification, such as:

        1             *                *                1
[Class] --------------- [Registration] ------------------ [Student]

In this case there is an instance of [Registration] for each combination of Class and Student. This alternative, though, is uncommon because it is relatively expensive in terms of space and performance (heap operations). In addition, the first alternative can usually be implemented using a vanilla template library collection class for [Registration].

Note that in the example [Registration] has some problem space connotation. One should always seek that out when naming Association classes. It should be very rare that one has to resort to something artificial like ClassStudentAssociation. That's because *:* relationships are very rare in most customer problem spaces. The reason is that customers don't want to deal with that level of monolithic complexity so they will have very likely already reified the *:* relationship in some fashion to simplify it into some form that is easier to manage. So all you usually have to do is look at the problem space a bit more carefully to see how they did that. Quite often one uncovers a problem space entity that has additional semantics relevant to the problem besides simply keeping track of participants.

Association classes qualify the association itself when there are complex rules and policies that govern participation. Whenever the participation in an association is complicated, regardless of actual multiplicity, one should look for an Association class in the problem space. This is just an extension of the point above. Customers try to keep things simple, so they may well have already provided some mechanism for dealing with the complexity of the participation. Quite often that simplification can be represented in terms of an Association Class even when the association is not *:*. For example,

                                  1      done with *
                  [MRPAllocation] ------------------ [Delivery]
                    +quantity                        +quantity
                          |
                          |
            1             |        used in *
[FrameBolt] -------------------------------- [Assembly]
+quantity

In this case the *:* association captures the notion that FrameBolts are used in lots of Assemblies on an assembly line. However, things may not be quite that simple. Typically things like frame bolts are not identified individually. In addition, the frame bolts may be delivered to the assembly line several times on an as-needed basis instead of all at once (e.g., as each subassembly is incorporated). The example above neatly deals with these issues through abstracting FrameBolt as a type of inventory item and employing the concept of an MRP allocation as an association class. (Note that quantity has different semantics in each class: quantity in inventory, quantity needed in a single Assembly, and quantity in a particular delivery.)

The first difference between the OO view and the RDB view of the relational data model is that in the OO view the association class is a bona fide first class object that is a peer to other objects abstracted from the problem space. In the RDB view the associated index (or embedded join) is a quite different thing than the tables that it coordinates. That indirectly leads to far more important differences in the way relationships are implemented, instantiated, and navigated.

Note that in the OO view (using the first reification) when one navigates from a particular Class to its registered Students, there is exactly one Registration object and it collects only the Students relevant to that class. Therefore if some client of Class is interested in the Students registered to that Class, they are available in the collection without any selection. Contrast that with the RDB approach where the index is against the entire [Student] table. To get the Students for a particular Class the RDB index infrastructure has to do a search of some type to select the correct Students from the entire table. Thus the OO view is more efficient for collaboration (navigating relationships for message sending).

The price one pays for the OO efficiency is a more complex process for instantiation. When a Student registers for a class, one must update two [Registration] collection instances: the Class must be added to the Student's Registration while the Student must be added to the Class' Registration. While basically the same thing happens for the RDB index, the difference is that the synchronization is hidden by the RDB engine while the synchronization is an explicit developer concern in the OO case. That's because we made the [Registration] a first class object with two explicit 1:* relationships.

This, in turn, has more profound implications for construction that apply to all associations. (I waited until this topic to bring it up because the basis is most clear when talking about association classes.) In OOA/D development we emphasize separation of concerns and encapsulation. That has particular relevance to association classes because we tend to separate the concerns of instantiation from those of collaboration. Thus we encapsulate the rules and policies for instantiating both objects and relationships, often in the form of a dedicated "factory" class as in the GoF design patterns*. One reason is that this provides better control over referential integrity because object and relationship instantiation are often inextricably linked. Thus those concerns are separated from the dynamic solution concerns of collaboration (what messages are sent, when they are sent, who sends them, and who consumes them).

One way this is manifested lies in the role of ordered sets. Sorting is rather common in the RDB world, either directly or through adding indices to a table, but it is relatively rare in OO applications. That's because in OO applications the collections are constructed to contain only the participants we are interested in. A corollary is that very often the order in which we add participants to the collection is sufficient and that comes "for free" because the underlying data structures we implement in OOP preserve that order.

Another way that is manifested lies in the way collaborations are constructed. In the RDB world, which deals only with static data, the notion of 'join' is ubiquitous. However, the closest one comes to that idea in OOA/D lies in the set operations commonly supported by abstract action languages. However, the OO set operations are done on one set (table) at a time. One reason is the separation of concerns for instantiation from navigation above. Another is that OO applications are primarily concerned with behavioral collaborations. Dynamic collaboration is more conveniently expressed in terms of ad hoc, peer-to-peer, as-needed message passing rather than static (predetermined) data relationships.

Since the OO paradigm is primarily concerned with behavior collaboration, that mode is used for both behavior and knowledge collaboration. The justification is that employing the same peer-to-peer paradigm for collaboration for both behavior and knowledge fosters consistency and simplifies the approach. So if one needs knowledge from an object, one sends it a message, navigating relationships in exactly the same way that one would for a behavior collaboration. If one needs data from two different objects, one navigates to and sends them a message individually rather than invoking a join between them. So, for all practical purposes, the concept of RDB 'join' does not exist in OOA/D.

* GoF = Gang of Four; Gamma, Helm, Johnson, and Vlissides who wrote the book "Design Patterns".

Blog root page
Previous post in category

5.0 Multiple inheritance, composition

Blog root page
previous post in category
next post in category

Multiple inheritance occurs when a class has two or more subclassing relationships with different superclasses. In this case the "subclass" draws properties from two different superclasses:

              [Amphibian]
                   |
                   |
    +--------------+----------------+
    |                               |
    _                               _
    V                               V
[Reptile]                        [Fish]
+crawl()                         +swim()

Here an Amphibian has properties that are appropriate for both living in water, inherited from [Fish], and living on land, inherited from [Reptile].

The use of multiple inheritance is a source of considerable controversy in the OO community. While I am not dogmatic about it I tend to lean towards the camp that doesn't use it for several reasons. One reason is that it very rarely reflects the way customer problem spaces actually work. Note, for example, that in the real world of Darwinian evolution the zoological tree has Amphibians evolving from Fish and Reptiles evolving from Amphibians. Thus the notion of [Amphibian] "inheriting" properties from [Reptile] is a bit of a stretch when mapping to the problem space.

A technical problem is that multiple inheritance often violates the rule that the union of subset members of the superclass must be a complete set of the superclass' members. That's because the superclasses often don't have other subclasses that are logically siblings. In this case it is hard to imagine another subclass of, say, [Fish] that is a sibling of [Amphibian]. That should be no surprise because an Amphibian isn't a Fish in the real world. Thus the notion of "is-a" goes out the window. There is a similar technical problem in that the superclasses are necessarily joint sets because members of the subclass are also members of each superset. These technical problems open the door for a lot of foot-shooting, particularly during maintenance.

A more aesthetic reason lies in the OO emphasis on cohesion. If the superclasses are completely distinct classes, they abstract quite different entities. Those entity abstractions are presumably already cohesive in their own right. To identify a subset of those entities that has both sets of properties necessarily implies a bleeding of cohesion between the supersets as represented by the subset of entities that have both sets of properties. In other words, the subclass inheriting properties from two distinct, individually cohesive superclasses cannot be as cohesive as either superclass and that bleeds cohesion for both superclasses. This notion of cohesion drives the rule that I use to qualify when I can use multiple inheritance:

Employ multiple inheritance only when both superclasses are semantically related.

This is more easily seen by example (from "Executable UML" by Mellor and Balcer):

                  [Account]
                      A
                      |
          +-----------+-------------------+
          |                               |
   [CheckingAccount]                [SavingsAccount]
          A                               |
          |                               |
   +------+--------------+                |
   |                     |                |
[Regular]           [Interest]            |
                         |                |
                         +-------+--------+
                                 |
                                 _
                                 V
                     [InterestBearingAccount]

In this case [Account] and [InterestBearingAccount] are semantically related in the problem space. One can imagine a slightly different situation where [InterestBearingAccount] might even be a subclass of [Account]:

                  [Account]
                      A
                      | R1
          +-----------+-------------------+
          |                               |
   [CheckingAccount]             [InterestBearingAccount]
           A                              A
           | R2                           | R3
    +------+-------------+  +-------------+------------+
    |                    |  |                          |
[RegularChecking]   [InterestChecking]              [Savings]

Alas, though superficially quite plausible, it is illegal because of the rule that the R1 relationship's subsets must be disjoint. A member of [InterestChecking] would necessarily be a member of both [CheckingAccount] and [InterestBearingAccount], making them joint subsets. So my bottom line point here is that one employs multiple inheritance to avoid violating the two rules about disjoint, complete sets that I cited in a previous post. In that case the superclasses are semantically related and cohesion is not a problem.

I can't talk about multiple inheritance without talking about composition. Composition is a technique borrowed from functional programming via component engineering. In its original form it is used to seamlessly glue together independent functions to achieve a more complex behavior. When applied in an OO context it essentially allows one to cobble together abstractions by merging properties that already exist in other abstractions. This is a useful tool for providing very generic services so one sees it in implementations for things like layered model infrastructures that must be independent of particular problem semantics. As it happens, multiple inheritance is an ideal vehicle for providing the "glue" that cobbles disparate properties.

Unfortunately this is not a very OO approach; in fact it is rather antithetical to OO because of the emphasis on merging properties (functions) rather than abstracting problem space entities based upon their intrinsic properties. This becomes most apparent when one considers the "-able" superclasses that are all too prevalent today. These allow one to "glue" hidden infrastructure into the class to support things like streaming or display. To do so one inherits from a Streamable or Displayable class. Such classes are thinly guised function libraries and that is definitely not the OO Way. Try going into you local Honda dealer and asking to test drive a Displayable Accord.

Blog root page
previous post in category
next post in category