Home > Articles > Software Development & Management > Object Technology

Object Inheritance: Definition, Uses, and Motivations

  • Print
  • + Share This
Often, the best ideas are old ones. In this article, Mike Abney explores the usefulness of “object inheritance,” which is a method of defining objects that inherit much of their state from other objects. Brief examples are provided in Java.
From the author of

One of the core concepts of object-oriented programming is that of inheritance. In most languages, that means class-based inheritance: the inheritance of structure and implementation. Conceptually, however, inheritance can also be applied to objects themselves. Such an object-based inheritance would allow for the inheritance of state: A child object asked for its name provides the same answer as its parent.

As a concept, object inheritance has been around for quite some time. The Self language (see http://research.sun.com/self/ and http://www.cetus-links.org/oo_self.html) was—and is—based in part upon the concept of object inheritance. In Self, object inheritance was used to make prototype-based programming easier. New objects could be built quickly by inheriting the state and abilities of existing objects. Any object could be made the parent of another. A message sent to an object was answered by looking for a "slot" in the child that corresponded to the particular message sent. Inheritance was implemented through special "parent slots." If none of the regular slots matched the message, the message would be passed on to the parents until a match was found.

Although object inheritance as a programming language concept is interesting, the concept has also shown itself to be useful in business modeling.

Uses of Object Inheritance

Object inheritance can be applied to business problems when a single real-world person, thing, or event needs to be represented by more than one object. This occurs in three of the twelve collaboration patterns presented in Streamlined Object Modeling: Patterns, Rules, and Implementation. Jill Nicola summarizes them in the InformIT article "Enforcing Business Rules with Objects."

In the actor—role pattern, a single real-world person is represented by an actor and some number of roles that the person can play in the system. In this case, it is desirable for the roles to be able to answer certain key questions that would typically be answered by their actor. For example, employees and customers (roles) should both be able to answer the question, "What is your name?" The name they would provide is actually a property of their associated person (actor).

In the item—specific item pattern, a single real-world thing is represented by a detailed specific item and an associated item description shared with other specific items. Each specific item that is associated with a given item description should share the values of that description. For example, if a movie (item) is available in both VHS and DVD formats (specific items), the VHS version should answer the same values for the title, director, actors, etc. as the DVD, and the values they provide should come from the associated movie.

In the composite transaction—line item pattern, many entities are taking part in a single event. The composite transaction describes the properties of the overall event, whereas the line items provide detail about the connection between the event and the involved entities. In a sales transaction with more than one specific item involved, the composite transaction—line item pattern is used. The line items record any extra information, at a minimum the quantity purchased, about the association of the specific item to the transaction. If a specific item asks its line item when the event happened, the line item should answer with the date and time provided by the composite transaction.

  • + Share This
  • 🔖 Save To Your Account