OO design using protocol hiearchies

Transcription

1 OO design using protocol hiearchies Jorge Mederos Martín, Julio García Martín Universidad Politécnica de Madrid 1 Abstract This paper describes the use of protocol hierarchies as a way to sort out object oriented designs using different points of view of them. A protocol hierarchy is a somewhat hidden facility of some modern object oriented languages like Java, Objective-C or Inprise Object Pascal in Delphi. The paper explores several interesting properties of protocol hierarchies and the way they permit us to split functionality from implementation, leading to more simple object oriented designs. Introduction Traditionally, class inheritance or subclassing has been used to add flexibility to object oriented designs. A class, for example, can be a generic abstraction to represent list of things. We can define different list implementations subclassing from. Subclassing allows us to manage list implementations using generic objects, without worrying about the exact list implementation used. In other words, we can use derived classes or subclasses as if they were their parent classes or superclasses. In this way, changing from a subclass point of view a list implementation to a superclass point of view a generic list is a change between two partial representations of a list abstraction. The added flexibility comes with the fact to use objects to manage several list implementations. The ability to manage a set of abstractions subclasses using other abstraction a superclass is used to be called polymorphism. It is often interesting not to specify an abstraction implementation in a superclass. Thus, a generic list class like could not impose list implementation details so we would provide several ones. An abstract class has some of its method implementations undefined. In a same sense, a pure abstract class does not define any of its method implementations. Pure abstract classes have been proben useful in object oriented design, because they permit us to describe an abstraction functionality in a superclass without specifying its implementation details. Concrete subclasses implement the details of a superclass abstraction. A class cluster is a slight variation. It groups private, concrete subclasses under a public, pure abstract superclass. It simplifies the publicly visible architecture of an abstraction without reducing its functional richness. Protocols or interfaces Some object oriented languages like Java [Ref], Objective-C [Don95] and Delphi [Ref] include another interesting way to describe an abstraction functionality. A protocol or interface is a list of method declarations or method signatures grouped by a common identifier and unattached to any class definition. A protocol does not provide any implementation about the methods it declares. The following are protocol declarations in Objective-C and StringEncoding - (String *) encodetostring; - (void) decodefromstring: (String *) astring; 1 LSIIS Department, Facultad de informática, Campus de Montegancedo, Boadilla del Monte, Madrid, Spain. jmederos@gran-via.com, juliog@fi.upm.es

2 @end interface StringEncoding { String encodetostring(); void decodefromstring ( String astring ); Protocols or interfaces can be handled without problems using the reflection mechanics or run time type information (RTTI) of those languages. A class adopts a protocol if it agrees to implement all the methods the protocol declares. A class can not adopt a protocol part. But they can adopt more than one protocol. If a same method signature is found in some of the adopted protocols, only one method signature will remain. As example, here are two simple classes inheriting from the root class Object and adopting the StringEncoding protocol, also in both languages. The classes must define implementations for all protocol method MyClass : Object <StringEncoding> { int memberfield; - (String *) encodetostring; - (void) decodefromstring: (String *) class MyClass extends Object implements StringEncoding { int memberfield; String encodetostring(); void decodefromstring ( String astring ); A class conforms to a protocol if it adopts a protocol or inherits from a class that adopts it. There is no need to declare again the adopted protocol. In the following example, MySubClass inherits form MyClass. MySubClass does not adopts any protocol, but it conforms to the StringEncoding protocol adopted by its MySubClass : MyClass { int class MySubClass extends MyClass { int othermemberfield; A protocol can incorporate or inherit other protocols to extend them, or as a way to name a set of protocols under a single name. Duplicated method signatures are eliminated. As example, if protocol Encoding incorporates (or inherits) StringEncoding and ByteDataEncoding protocols, then it contains all method declarations of StringEncoding, ByteDataEncoding and maybe other method declarations specific to Encoding (see figure Encoding <StringEncoding, ByteDataEncoding> - ( *) interface Encoding extends StringEncoding, ByteDataEncoding { encodingstyles(); 2

3 Protocols were first introduced as an extension to Objective-C and inspired the interface declarations of Java [JavaRef] and Delphi [DelphiRef] programming languages. They are useful in at least the following situations [Don95;95]: To declare methods that others are expected to implement. They can be used as a replacement of pure abstract classes. Protocols are always abstract, because they only hold method declarations. In the previous conforming to a protocol example, the MyClass class does not need to have an abstract StringEncoding superclass, the protocol declaration is sufficient. To capture similarities among classes that are not hierarchically related. For example a encoding/decoding interface for persistent objects. We can declare other class, like MyOtherClass adopting the StringEncoding protocol in the same way as MyClass does. Both classes will have the methods declared by StringEncoding without inheritance relationships. This property is interesting. Classes that are unrelated in most respects might nevertheless need to implement some similar methods. This limited similarity may not justify a hierarchical MyOtherClass : Object <StringEncoding> - (String *) encodetostring; - (void) decodefromstring: (String *) class MyOtherClass extends Object implements StringEncoding { String encodetostring(); void decodefromstring ( String astring ); To declare the interaface to an object while concealing its class. Thus, avoiding to declare an exact class type, even a common superclass type. For example, we can create an object variable that understand the StringEncoding protocol, without declaring its exact class identifier. Objects can be type checked by a compiler against a protocol identifier, like they are checked against a class identifier. id <StringEncoding> anobject; anobject = [ MyClass new ]; //... processing with anobject, then asigned to another object of a distinct class anobject = [ MyOtherClass new ]; StringEncoding anobject; anobject = new MyClass; //... processing with anobject, then asigned to another object of a distinct class anobject = new MyOtherClass; Note that in this example we are using the same variable anobject to hold objects of classes not hierarchically related. The class hidding property The class hidding property reflects the fact that protocols or interfaces are not attached to any class type. It sumarizes the three properties alredy reviewed in the previous section: A protocol defines a set of method signatures allowing the access to any class adopting that protocol and giving a meaning name to that set. A name not related to class names. To understand why class hidding works, we need to see in more detail how protocol method signatures are translated into normal object method calls. The term dynamic binding is often used to name two distinct implementations of how to do an object method call. Classes store 3

4 methods they understand (which would be inherited) in a dispatch method table. An important implementation difference is related to the moment when the dispatch method table of each class is filled with method pointers. Why? Because to fill a dispatch method table it is necessary to review the class hierarchy looking for all inherited methods known by a given class. The search is made from subclasses to superclasses, so a method defined by a subclass is not searched again in a superclass, allowing in this way the overriding of superclass methods by subclasses. One approach to implement dynamic binding is taken by C++ or Eiffel: methods are filled during compile time. The other approach is taken by Smalltalk, Objective-C or Java: methods are filled at runtime [Revisar Java]. At compile time they do not store method pointers, but method signatures. Method signatures have an associed method pointer, but the same method signature have different method pointers in different classes. At runtime they select a correct method pointer searching up the class hierarchy using a method signature as request. A protocols is a set of method signatures. A protocol variable stores objects belonging to any class that conforms to that set of method signatures. When it is requested the execution of a method through a protocol variable, the object receives the method signature and selects the exact method pointer to execute. Method requesting and method execution are decoupled. For this reason it is possible for a protocol variable to hold an object of any class conforming to that protocol. If protocols would have used method pointers, all objects stored in protocol variables should agree in those method pointers. This is exactly the case of an object variable of a pure abstract base class. Protocols or interfaces are a very simple yet powerful abstraction, which slightly modifies the way traditional object oriented designs are carried out. As we will explore in this paper, protocol-based design encourages the separation between functionality and implementation through the use of the class hidding property in similar ways as encapsulation can do. But the implications of protocol use are a little more complex, so we will review them before. Protocol hierarchy concepts A protocol or interface that incorporates other or others protocols is a protocol hierarchy. Note that, as a special case, a protocol hierarchy can contain only one protocol if the functionality described is simple enough and it does not incorporate any other protocol. Four key aspects must be kept in mind about protocol hierarchies. The use of protocols can be viewed as another way of polymorphism. Because it lets us to reffer to an unrelated group of classes using a protocol identifier, not only a class identifier. Thus it is more generic than the use of abstract classes. In this example the encoding protocol is used to handle several unrelated classes as a common abstraction. Figure 1 shows the difference from a classical class hierarchy approach. StringEncoding MyClass StringEncoding MyOtherClass StringEncoding MyClass MyOtherClass Figure 1. Classic hierarchies need abstract classes to support common functionality. With protocols, the design is strainfoward, because classes only need to agree in protocols. The figure shows the StringEncoding abstract class in in italic inside a rectangle. It also shows a representation of protocols adopted by a class using rounded rectangles below the class name. 4

5 As we see before, a StringEncoding protocol variable can be used to hold any object belonging to any class that conforms to the StringEncoding protocol. Pure abstract superclasses are replaced by protocol adoption, simplifying the class hierarchy tree. A protocol is a partial functionality type check. It only checks a specific functionality of a given object, not the whole set of functionality provided by a given object, which maybe is distributed among several protocols. Protocols are a type checking form. It is more flexible than a whole class type check, and it can be made at compile time and at run time. A static type check is made declaring a protocol or interface variable, as we have seen before. A run time protocol type check in Objective-C and Java is the following: if ( [ anobject conformsto ) ] ) { // dynamic type check ok bool ConformsTo ( Object anobject, Object aninterface ) { //... to be filled if ( ConformsTo ( anobject, aninterface ) ) { // dynamic type check ok The Java example is somewhat more complex, because Java reflection facility continues being not as complete as desired. A protocol hierarchy defines a structured abstract interface. A tree of incorporated or inherited protocol declarations offers a more structured and often convenient organization than a simple method declaration enumeration. It is different from a hierarchy of pure abstract classes, because the protocol hierarchy is not attached to any class or set of classes. StringEncoding ByteDataEncoding Encoding Figure 2. StringEncoding and ByteDataEncoding are stand alone protocols which can be incorporated in a more generic Encoding protocol for type checking purposes. A protocol hierarchy decouples functionality from implementation through class hidding. This is an important conclusion from previous points. Complex interfaces can be declared using protocol hierarchies, and different class implementations can conform to those protocols. Using protocol-typed variables instead of class-typed variables literally detach implementation constraints from a functional point of view. 5

6 Protocol hierarchies hide class implementations. You can define multiple points of view using different protocol hierarchies. These hierarchies can be mapped to one or several class hierarchies implementations, which in turn can use again protocol hierarchies if it is needed. But, as protocols only provide a protocol name and method signatures, other implicit semantics about the use of protocol variables must be well documented. This is not new, it is equally aplied to pure abstract classes and class clusters. Functional layer (protocols) Implementation layer (classes & protocols) Figure 3. Protocols are not tied to any particular class. Among them they build a functional hierarchy not tied to a concrete implementation. This independence can serve to figure out more decoupled designs, only using protocols as an intermediate layer which hides implementation details. Several protocol hierarchies can represent different points of view of the same problem. Figure 3 shows the point. An object oriented design can be splitted in two layers: one functional with an equivalent of abstract classes using protocol hierarchies, and other with an actual implementation of the functional interface previously described. Of course, the implementation layer could be complex enough to have to be partitioned again. To ilustrate the last point better, let us assume that we are designing a list facility. We would like to declare an abstract list interface, since different implementations could be provided. There is an interesting property we would want to maintain in the list facility design. Read only lists are thread safe after construction. They are non-mutable objects. Mutable objects could have problems in a multithreading environment if they are not implemented with care, but the same problem is irrelevant for non-mutable ones. So we would like to design the list facility with mutable and non-mutable concepts in mind. A nonmutable list declares methods to read elements, and a mutable one declares methods for read an write elements. Module using protocol variables (using the functional layer) Array Linked Functional layer Modules implementing a class hierarchy conforming to protocols declared in the functional layer. MutableArray MutableLinked Implementation layer Figure 4. The and are part of a protocol hierarchy. Different implementations can be provided for distinct requirements. In this case an Array and a Linked. Note how these implementations are quite strainforward because protocols simplify the overall design and they not need to have common superclasses. Figure 4 shows the basis of functional and implementation separation. The functional layer is defined using a protocol hierarchy of two protocols: and. That is all we need 6

7 to know about the list facility interface, because we can use variables typed with those protocols. The real nature of the implementation classes for the protocol hierarchy does not need to be known. Array and Linked could belong to different class libraries. Let us see it in more detail reviewing protocol relations. is a protocol that incorporates the protocol. Array adopts the protocol. MutableArray inherits from Array and adopts the protocol. Finally, MutableArray conforms to the and protocols. Note that MutableArray conforms to the protocols in two distinct ways. It inherits from Array which adopts the protocol and it adopts the protocol because incorporates the protocol. There is no problem with that, because duplicated method signatures are not taken into account. More important, the class hidding property of protocol hierarchies allow us to concentrate in three different smaller problems instead of a single greater problem. Figure 4 shows the three modules used in this example. A module which use the list facility through protocol variables, a module implementing the array-based list facility and a module implementing the linked list-based list facility. The only needed connection are protocol declarations. In a traditional class hierarchy, as shown in figure 5, design approach we must keep in mind the complete class diagram for a very simple functionality while writing a module using the whole list facility class hierarchy. Array Linked MutableArray MutableLinked Figure 5. The and are pure abstract classes, and are shown in italic. The functional equivalent design in a traditional class hierarchy is more complex, including multiple inheritance relationships. 7

8 Protocol hierarchies do not need to conform to a one-to-one relationship with implementation hierarchies. In the above example, we would want to have two different implementations of a abstraction. One of these implementations could have the thread-safe property and would set the apropiate locks when writing data into the list. The other one could implement a mutable list without the overhead of a thread-safe code to be used in programs with only one thread. Linked Array MutableArray MutableThreadSafeArray MutableLinked MutableThreadSafeLinked Figure 6. In this case, the list facility protocol hierarchy continues having two protocols: and. We also provide two different class hierarchy trees (for illustrating purposes) representing different choices during the implementation phase. Note that these differences are not known by the module using the list facility protocol variables. The example shown in Figure 6 represents two different implementation choices for the list facility protocol hierarchy. We have continued improving the implementation details of the two implementation modules without modifying the protocol hierarchy. The module using the protocol hierarchy only need to change to reflect the exact class thread-safe or not which will be hold in a protocol variable. This issue can be properly hidden using a factory for the list facility, as we will review later. Of course, other list implementations could be added without breaking the existing ones, maybe with radically different implementation designs, like a distributed access to objects in other processes or machines. Other requirements might show us the convenience to have another way to reffer to our multiples implementations of the list facility. Those other requirements could lead us to consider the same implementations from another point of view. For example, a list can be viewed as a degenerated tree: a tree which every node has only one child. In this case, we want to see our list facility from other point of view: as a tree facility. Tree classes have few things in common with lists and they might be implemented in another class hierarchy. If we are using protocol hierarchies, we can modify our list facility to behave as a tree facility, allowing the reuse of our list facility from modules using protocol variables of a tree protocol hierarchy. We only need to implement the tree protocol hierarchy method signatures translating them to list facility calls. 8

9 Linked, Tree Tree MutableTree MutableLinked, MutableTree Functional layer MutableThreadSafeLinked, MutableTree Implementation layer Class hierarchies design simplification Protocol hierarchies allow us to describe problems from a functional point of view, rather than an implementation point of view. The inherent decoupled behavior of protocols from classes is quite convenient to describe problems without imposing implementation constraints. We will review three interesting simplifications with the use of protocol hierarchies. They simplify common object oriented designs, even the most simple ones, and alredy well documented using design patterns. As a side effect, these simplified designs are more suitable to be composed successfully. Without protocols or interfaces, some problems cannot be isolated from non-elegant implementation details, disallowing us to obtain clearer and simpler designs. They can substitute many times the use of multiple inheritance, permitting us to reuse single inheritance designs in ways that were not possible previously. Design patterns simplification There is an interesting field of research in the documentation of OO designs, with the aim to reuse good OO design ideas alredy proben to be applied in other designs.... Figure 7. The separation of protocol hierarchies and implementation hierarchies dramatically reduces the complexity of object oriented designs. The benefits grows with the addition of new points of view. Note that the inclusion of a tree point of view does not increases the complexity of the overall design, which is not true for a classical class hierarchy design. Class hierarchies limitations To ilustrate the protocol hierarchies let face to the following problem: We want to create a multiplatform graphical user interface programming framework. For example, to support some different graphical user interfaces (GUI) like Sun XView [Hel93] and OSF Motif [Hel94]. We would like to have an independient framework to describe both GUI, hidding the implementation differences between them. We could begin defining an abstract GUI object class GuiObject, which could have two (or maybe more in the future) specific subclasses: 9

10 XvGuiObject and XmGuiObject. Later, we could add more specific graphical items, like a form and a generic form item. GuiObject XmGuiObject XvGuiObject GuiForm XmGuiForm XvGuiForm GuiFormItem Figure 1a shows an initial attempt to sort this problem out. We are really describing a GUI independient interface and behavior and two GUI specific implementations of the same hierarchy. But single inheritance is not well suited for this problem. For example, we cannot reuse specific behavior from GUI specific classes, because the inheritance tree is alredy used while trying to get the independent behavior

11 11

12 Bibliography [Coa95] Peter Coad, David North, Mark Mayfield. Object models: strategies, paterns, and applications. Prentice Hall, Englewood Cliffs, NJ, [Coo95] Sean Cooter. Inside Taligent Technology. Addison-Wesley, Reading, MA, [Don95] Don Larkin, Greg Wilson. Object oriented programming and the objective- C language. NeXT Developer Library. Addison-Wesley, Reading, MA, REVISAR [Gam95] Erich Gamma, Richard Helm, Ralph Johnson, John Vlissides. Design Patterns. Elements of reusable object-oriented software. Addison-Wesley, Reading, MA, [Hel93] Dan Heller, Thomas Van Raalte. XView Programming Manual for XView Version 3.2. O Reilly & Associates, Inc [Hel94] Dan Heller, Paula M. Ferguson. Motif programming Manual for OSF/Motif Release 1.2. O Reilly & Associates, Inc [Hel96] Richard Helm, Erich Gamma. The Courier Patern. Dr. Dobb s Sourcebook. january/february [Ion95] Orbix Programmer s Guide. Release 1.3. Iona Technologies Ltd. July [Vli96] Pattern Languajes of Program Design 2. Edited by John Vlissides, James Coplien and Norman Kerth. Addison-Wesley, Reading, MA,