Halbert D.C., O'Brien P.D. "Using Types and Inheritance in Object-Oriented Programming." IEEE Software, vol. 5, no. 4, 71--79, September 1987  Home/Search   Document Not in Database   Summary   Related Articles   Check

....in the OCAD project. The types comprise ellipse arcs and specializations. Many update methods, query methods, and (graphical) attributes are left out for shortness. Ordering the types according to the requirement of structural inheritance results in a subtyping for generalization hierarchy ( HO88; Bud91] depicted in Fig. 2. As all in 290 herited methods can syntactically be applied to all instances of the subclasses, this hierarchy apparently satisfies the property of substitutability as well. EllipseArc relationship The symbol denotes the subtype SemiMajorAxis Radius ....

D. Halbert and P. O'Brien. Using types and inheritance in object-oriented programming. IEEE Software, 4(5), September 1988.

....In particular, roles add new event types and sequences to an object type, but neither add nor refine attributes and methods. Consequently, unlike object types and their specializations roles cannot have instances of their own. This however lets roles appear as partial specifications of types [32] implemented as abstract supertypes in a multiple inheritance context. We shall come back to this later. Finally, Jungclaus et al. 36,37] revert the view of roles as the dynamic variant of specialization by regarding specializations as special, namely static, kinds of roles. While this is a ....

D.C. Halbert, P.D. O'Brien, Using types and inheritance in object-oriented programming, IEEE Software 4 (5) (1987) 71 79.

....and capture the case specific behavior in the subclasses. In order to appreciate the need for this refactoring, it is important to understand the role of subtyping for specialization. A type characterizes the behavior of its instances by describing the operations that can manipulate those objects [53]. A program with a well designed type structure will minimize and localize the dependencies among types, enhancing maintainability and extensibility. A type hierarchy is composed of subtypes and supertypes. The intuitive notion of a subtype is one whose objects provide all the behavior of another ....

....whose objects provide all the behavior of another type (the supertype) plus something extra. Subtyping is most frequently used to model conceptual hierarchies. When used in this way, a subtype describes a type that is more specific than a supertype; the subtype is a specialization of the supertype [53, 74]. 5MS DOS is a trademark of Microsoft Corporation. 15 Inheritance can be used in several ways; some clarify the design of a framework while others can make a framework more difficult to understand. One use of inheritance is to model the type hierarchy that is, represent the supertype as a ....

Daniel C. Halbert and Patrick D. O'Brien. Using types and inheritance in object-oriented programs. IEEE Software, pages 71 79, September 1987.

.... 56 59 The problems of inheritance, subtyping, and recursion are exposed in [33, 14, 15, 5] The separation of subtyping and inheritance is made clear in [32] Slide 58 Emerald is described in [6, 50, 7, 87] Trellis Owl in [95] Slide 60 62 Definitions of class based inheritance are given in [57, 49, 110, 46, 63, 96, 9, 93]. Annotated Bibliography 103 Slide 63 66 The soundness of covariance in Eiffel is questioned in [34] the soundness of the pure Simula version is argued in [60] Slide 67 Typed Smalltalk is developed in [51, 45, 44] A system which preserve recursive structure is described in [78, 77, 83] ....

Daniel C. Halbert and Patrick D. O'Brian. Using types and inheritance in object-oriented programming. IEEE Software, September 1987.

....principle of genus et differentiae leading to a taxonomic hierarchy of categories or types [7] while those with implementation in mind focus on the reuse of class definitions and polymorphism as made possible by subclassing and inheritance. This has led to an extensive discussion (see [1, 4, 5, 8]) as to whether Square should be a subclass of Rectangle or vice versa, a dilemma that is, of course, precedential in character. Despite the different perspectives there appears to be a broad consensus that, in principle at least, both a conceptual type and a class (as a programming construct) ....

Halbert, DC. O'Brien, P.D. Using types and inheritance in object-oriented programming. IEEE Softw. 4, 5 (May 1987), 71--79.

....and capture the case specific behavior in the subclasses. In order to appreciate the need for this refactoring, it is important to understand the role of subtyping for specialization. A type characterizes the behavior of its instances by describing the operations that can manipulate those objects [53]. A program with a well designed type structure will minimize and localize the dependencies among types, enhancing maintainability and extensibility. A type hierarchy is composed of subtypes and supertypes. The intuitive notion of a subtype is one whose objects provide all the behavior of another ....

....whose objects provide all the behavior of another type (the supertype) plus something extra. Subtyping is most frequently used to model conceptual hierarchies. When used in this way, a subtype describes a type that is more specific than a supertype; the subtype is a specialization of the supertype [53, 74]. Inheritance can be used in several ways; some clarify the design of a framework while others can make a framework more di#cult to understand. One use of inheritance is to model the type hierarchy that is, represent the supertype as a superclass and a subtype as a subclass. However, ....

Daniel C. Halbert and Patrick D. O'Brien. Using types and inheritance in object-oriented programs. IEEE Software, pages 71--79, September 1987.

....In particular, roles add new event types and sequences to an object type, but neither add nor refine attributes and methods. Consequently, unlike object types and their specializations roles cannot have instances of their own. This however lets roles appear as partial specifications of types [32] implemented as abstract supertypes in a multiple inheritance context. We shall come back to this later. Finally, Jungclaus et al. revert the view of roles as the dynamic variant of specialization by regarding specializations as special, namely static, kinds of roles [36; 37] While this is a ....

DC Halbert, PD O'Brien "Using types and inheritance in object-oriented programming" IEEE Software 4:5 (1987) 71--79.

....and then creating the subtypes. Frequently, you create several seemingly disparate types, realize they are related, and then factor out their common characteristics into one or more supertypes. several passes up and down are usually required to produce a complete and correct program design [50]. Despite the importance of the decomposition activity in object oriented design, Meyer cautions us not to expect onesize fits all, mechanical solutions. Expecting to obtain infallible recipes for finding the classes is as unrealistic as would be, for an aspiring mathematician, expecting to ....

D. Halbert and P. O'Brien. (1988) "Using Types and Inheritance in Object-Oriented Programming," IEEE Software vol. 4(5).

....with methods to determine such things as who is the captain and where the ship is registered. Subtypes contain more specialized ships such as tankers and freighters. There can be quite an elaborate hierarchy (e.g. tankers are a special kind of freighter) Windows are another well known example [Halbert and O Brien 1987]; subtypes include bordered windows, colored windows, and scrollable windows. Common examples of subtype relationships are allowed by our definition provided the equal method (and other similar methods) are defined properly in the 22 Delta B. Liskov and J. Wing subtype. Suppose supertype ....

Halbert, D. C. and O'Brien, P. D. 1987. Using types and inheritance in object-oriented programming. IEEE Software 4, 5 (Sept.), 71--79.

....with methods to determine such things as who is the captain and where the ship is registered. Subtypes contain more specialized ships such as tankers and freighters. There can be quite an elaborate hierarchy (e.g. tankers are a special kind of freighter) Windows are another well known example [17]; subtypes include bordered windows, colored windows, and scrollable windows. Common examples of subtype relationships are allowed by our definition provided the equal method (and other similar methods) are defined properly in the subtype. Suppose supertype provides an equal method and ....

Daniel C. Halbert and Patrick D. O'Brien. Using types and inheritance in object-oriented programming. IEEE Software, pages 71--79, September 1987.

....with methods to determine such things as who is the captain and where the ship is registered. Subtypes contain more specialized ships such as tankers and freighters. There can be quite an elaborate hierarchy (e.g. tankers are a special kind of freighter) Windows are another well known example [HO87] subtypes include bordered windows, colored windows, and scrollable windows. Common examples of subtype relationships are allowed by our definition provided the equal method (and other similar methods) are defined properly in the subtype. Suppose supertype provides an equal method and consider ....

Halbert, D. C. and O'Brien, P. D. Using types and inheritance in object-oriented programming. IEEE Software, 4(5):71--79, September 1987.

....of the subtype methods is identical to that of the corresponding supertype methods and new methods (defined on the extra state) have no corresponding supertype method. For example, bordered windows, colored windows, and scrollable windows are all extended subtypes of a more generic window type [5]. In their paper, Liskov and Wing call these extension subtypes since the subtype extends the supertype by providing additional state and correspondingly additional methods. Case 2. If changes to old methods are made, then Part 2 of the subtype definition applies: the contra covariant rules, the ....

Daniel C. Halbert and Patrick D. O'Brien. Using types and inheritance in object-oriented programming. IEEE Software, 4(5):71--79, September 1987.

....be overly flexible while at others overly restrictive. For example, a common error is to use subtyping (subclassing) as a means of composition rather than to define a sum of behaviors. Design rules which guard against misapplication of object oriented principles during system design are given in [HO87] The requirement that all concepts be organized into classes can be overly restrictive. For example, Borgida has investigated how non strict taxonomies of classes can be used to accommodate exceptional entities [Bor88] i.e. those which differ only slightly from the class definition. An ....

D. Halbert and P. O'Brien. Using Types and Inheritance in ObjectOriented Programming. IEEE Software, pages 71--79, September 1987.

....often choose between keeping operating systems portable, extensible, maintainable, and efficient. Using modern programming methodologies, languages and software engineering techniques may be the best hope to overcome these problems. The object oriented paradigm[Weg87, JF88, Sny86, Mey87, Boo86, HO87, Mey86, GR83] is rapidly gaining attention as a useful tool to solve the kind of problems operating system software suffers. Object oriented programming is claimed to support the sharing of common interfaces and code, incremental extensibility, and the development of reusable and extensible ....

Daniel C. Halbert and Patrick D. O'Brien. Using Types and Inheritance in ObjectOriented Programming. IEEE Software, pages 71--79, September 1987.

....its superclass; the superclass has fewer attributes and a more general behavior. This organization is strictly enforced in specification inheritance hierarchies. Systems using implementation inheritance hierarchies are not restricted in this way, so other inheritance organizations may be explored [HO87]. There are essentially two varieties of type systems used for object oriented programming languages: class based and specification based. In a class based type system, the appearance of a class name in a type expression means that only instances of that class may appear during execution in a ....

....methods. If an inherited method is redefined by a class, they require that its return type be a subtype of the return type of the method being overridden. This is not a requirement of Smalltalk nor is it even a convention. In fact, subclassing for generality is a legitimate programming methodology [HO87]. Their nearest common supertype treatment of union types is inadequate. As discussed in Section 1.2.4, this usually destroys the specific information needed for optimization. For example, the nearest common supertype of Set and OrderedCollection is Collection. The implementations of the two ....

Daniel C. Halbert and Patrick D. O'Brien. Using types and inheritance in object-oriented programs. IEEE Software, :71--79, September 1987.

....has to be constantly integrated into existing applications, resulting in considerable program restructuring. Because of the variety of mechanisms provided by object oriented languages, the best choice for representing a real world entity in terms of classes is not always readily apparent [10]. Moreover, the object orientation relies heavily on a mechanism, inheritance, that can serve many purposes such as denoting specialization relationships, enforcing typing constraints, and sharing implementations. This variety in the permissible usages of inheritance complicates the task of ....

....be tailored to derive new classes without actually changing existing definitions. Some common tailoring mechanisms available in object oriented languages are the renaming of attributes (variables and methods) and the redefinition of properties (variable types, method bodies and class interfaces) [10][14] Tailoring is however of limited value when it comes to the redesign of a class collection, and its undisciplined use quickly leads to incomprehensible subclassing structures. The problem of modifying class definitions in a consistent way has been extensively investigated in the area of ....

[Article contains additional citation context not shown here]

Daniel C. Halbert and Patrick D. O'Brien, "Using Types and Inheritance in ObjectOriented Programming," IEEE Software, pp. 71--79, IEEE, September 1987.

....suffered from problems of scalability, maintainability and extensibility. Distributed systems exacerbate these problems since even more components must be maintained and integrated. The use of object oriented techniques is proposed as a solution to these types of software engineering problems [17, 10, 13]. Object oriented programming and design stresses modularity and data encapsulation through narrow and rigidly defined interfaces. An object oriented operating system could internally structure itself as objects and present all kernel accessible resources to client applications as a set of objects ....

....is a mechanism which allows a new class to copy of the parent s implementation, modify some of the inherited methods, and add additional methods. Inheritance is useful for code and interface sharing, for factoring code into common places, and for incremental development and documentation [10, 23, 13, 17]. When using classes for type conformance checking a client specifies its requirements (needed interface) as a class. Server objects which are instances of that class or any of its subclasses conform by definition to the required interface. i.e. class C x conforms to C y if and only if C x is a ....

Daniel C. Halbert and Patrick D. O'Brien. Using Types and Inheritance in Object-Oriented Programming. IEEE Software, pages 71--79, September 1987.

....and polymorphism, and thus supplies a solid basis for the development of large libraries of reusable components that satisfy the above requirements. However, a strong methodological framework is needed for the benefits of object orientation to materialize. As several studies (cf. 1] 3] [4], 13] 14] have shown, an undisciplined usage of object oriented programming constructs leads to complex hierarchies that are difficult to understand and to extend, and to a considerable amount of redundant code. Moreover, some approaches place more emphasis on one particular requirement rather ....

Halbert, D. C. and O'Brien, P. D. Using Types and Inheritance in Object-Oriented Programming. IEEE Software, September 1987, pp. 71-79.

No context found.

Halbert D.C., O'Brien P.D. "Using Types and Inheritance in Object-Oriented Programming." IEEE Software, vol. 5, no. 4, 71--79, September 1987

No context found.

Daniel C. Halbert and Patrick D. O'Brien. Using Types and Inheritance in Object-Oriented Programming. IEEE Software :71-79, September, 1987.

No context found.

Daniel C. Halbert and Patrick D. O'Brien. Us- ing types and inheritance in object-oriented programming. IEEE Software, pages 71-79, September 1987.

No context found.

Daniel C. Halbert and Patrick D. O'Brien. Using types and inheritance in object-oriented programming. IEEE Software, pages 71--79, September 1987.

No context found.

Halbert D C., O'Brien P D.,"Using Types and Inheritance in Object-Oriented Programming", IEEE Software, Sep 1987

Online articles have much greater impact   More about CiteSeer.IST   Add search form to your site   Submit documents   Feedback  

CiteSeer.IST - Copyright Penn State and NEC