Bertrand Meyer. Lessons from the design of the Eiffel libraries. Communications of ACM, 33(9):68--88, September 1990.  Home/Search   Document Not in Database   Summary   ACM   TOC   Related Articles   Check

....of a component, i.e. specify how the component can be used from the outside. Bertrand Meyer s design by contract [83, 111, 112] brings the idea of contracts to the next level. Not only the interface but also pre post conditions and invariants specify the expected behavior of methods. Eiffel [110, 113] provides built in support for such contracts. The next level of evolution is reached with state machines such as AsmL (Abstract State Machine Language) 6 8] It supports the definition of contracts for Microsoft s .NET platform. Such contracts of pre and post condition and type invariants can ....

Bertrand Meyer. Lessons from the Design of the Eiffel Libraries. Communications of the ACM, 33(9):68--88, Sep 1990.

....variety of sophisticated data structures, are organized in the Smalltalk system by inheritance. The inheritance structure is used to document the classes and is presented to users as an aid to understanding the library. Yet there is growing consensus that inheritance is a producer s mechanism [Meyer91] that has little to do with client s use of classes. An alternative organization of the collection classes is developed by examining the interfaces supported by the collection objects [CCHO89, JF88] A program for extracting protocols, or sets of message names, directly from the Smalltalk system ....

....interfaces along. To address these, the behavior of methods must be analyzed . Behavioral specification tools based on pre and post conditions have also been adapted for use in object oriented programming [America91, LW90] Specifications have also been used in the design of the Eiffel libraries [Meyer91]. America s techniques are used to develop specifications for the classes in the Smalltalk library. Several interesting issues arise while discussing the specifications. In some cases, methods are being inherited that should be canceled because they violate subclass invariants. In some cases ....

[Article contains additional citation context not shown here]

B. Meyer. "Lessons from the design of the Eiffel libraries" CACM 33:9 (September 1991), pp. 68--84.

....own bulk data types (lists, trees, bags, sets, relations or multi dimensional search structures) from scratch. In fact, much work is devoted to the construction of re usable generic library code for such bulk types that can be later instantiated with specific type parameters and access mechanisms [Mey90] Despite this progress towards add on bulk types there is nevertheless much interest in type quarks [ART91] i.e. specialized built in building blocks to be used in the construction of fully fledged user defined bulk types. This interest in the DBPL research community is motivated by additional ....

B. Meyer. Lessons from the Design of the Eiffel Libraries. Communications of the ACM, 33(9):69--88, September 1990.

....complexity of software construction, maintenance, reusability and comprehension. Object orientedness provides many interesting features with respect to implementations of types. For instance, we may consider the hierarchy built in the Eiffel library to define classes for data structures [Mey90]. Classes are arranged using the inheritance mechanism following two rules: Class A inherits from class B if the data structure defined in A is a specialisation of the one defined in B. So, there exists a class container to store elements of any type, offering operations for putting elements in ....

B. Meyer. "Lessons from the design of the Eiffel libraries", Communications ACM, 33(9), Sept. 90.

....as it provides a structure for building the system, but is irrelevant to the application programmer, who only looks for the most suited paradigm to build his application. This is consistent with the recent trend in object oriented programming of regarding inheritance as a producer s mechanism [13], that has little to do with the end user s use of the classes [4] 3 An Exemplar Multiparadigm Programming Environment 3.1 Design Objectives Blueprint is an exemplar multiparadigm programming environment, built using the Conventions Paradigm 1.1 Conventions Paradigm 2 E Conventions ....

Meyer B (1990) Lessons from the design of the Eiffel libraries. Commun. ACM, 33: 68--88.

....as it provides a structure for building the system, but is irrelevant to the application programmer, who only looks for the most suited paradigm to build his application. This is consistent with the recent trend in object oriented programming of regarding inheritance as a producer s mechanism [Mey90], that has little to do with the end user s use of the classes [Coo92] Using to our approach, a multiparadigm programming environment consists of a set of classes, one for each paradigm. The classes are ordered in a hierarchy whose root is the target architecture. Every class is self contained, ....

Bertrand Meyer. Lessons from the design of the Eiffel libraries. Communications of the ACM, 33(9):68--88, September 1990.

.... Object orientation (OO) seems to provide a welcoming framework for software reuse [3] Encapsulation, genericity, abstraction and inheritance, OO features associated with classes, or the models for the real life entities programs must simulate, are mentioned as the keys to reuse in the OO world [4, 5, 6, 7]. A class is typically a well delimited syntactic structure having the following properties: it contains all attributes concerning the entities modeled, including the data structure for each entity, and the operations that can be applied to them; it may be constructed, compiled, and tested ....

B. Meyer, "Lessons from the Design of the EIFFEL Libraries", CACM 33(9):68-88, Sept 1990.

....of the effort required to use a component must include the effort required to determine what components are available, the effort required to confirm that a component is relevant to the intended use, and the effort required to use the component properly. Although the first two steps are important [10, 7], it is the last that has the biggest impact on the reusability of software a component that requires an editor to make it useful is not a very reusable one. Three important properties of code that make it more reusable [1] are generality, flexibility, and safety. Generality is about ....

Bertrand Meyer. Lessons from the design of the Eiffel libraries. Communications of the ACM, 33(9):69--88, September 1990.

....elaborator several times. A pattern is problem oriented, not solution oriented, so the developer is looking for the issues or tensions that the pattern resolves. 6 Class Libraries There have been many class libraries developed, and their design has been extensively documented in the literature [42, 46, 56, 58, 70], so this section will be brief. Object oriented class libraries embody ffl the design of interfaces, ffl the design of a class hierarchy, and ffl the design of policies or conventions, such as those on reporting errors in calls to library classes. The most effective libraries are ....

Bertrand Meyer, Lessons from the design of the Eiffel libraries, CACM 33, 3 (1991) 68--84.

....as the final code must include all libraries even the code for those never used classes. A more important task for all class library developers is to carefully design the architecture of the class library. Among the principles for good engineering class library development given by Meyer [2, 4], keep less dependence amongst the classes should be one of the primary goal. A class library can be regarded as a class hierarchy which uses as few outside libraries as possible and keep the inside classes as dependent as possible. If the class hierarchy of a class library is well formed, every ....

Meyer, B., "Lessons from the design of the Eiffel libraries", Communications of the ACM, 33:9(68-84), 1991.

....is not surprising given the small number of current libraries and their limited size. Normally libraries are constructed with the emphasis on reusability through generality [8, 10] More recently various issues have been raised by implementers based upon their experience in constructing a library [11, 14]. It is perhaps fair to say that a full picture is yet to emerge, fault tolerance considerations may just be one in a long line of unexplored concepts in large scale library construction. The interested reader is directed to [7] for a general overview of problems associated with library ....

B. Meyer. Lessons from the design of the Eiffel libraries. Communications of the ACM, 33(9):68--88, 1990.

....as it provides a structure for building the system, but is irrelevant to the application programmer, who only looks for the most suited paradigm to build his application. This is consistent with the recent trend in object oriented programming of regarding inheritance as a producer s mechanism [13], that has little to do with the end user s use of the classes [4] 3 An Exemplar Multiparadigm Programming Environment 3.1 Design Objectives Blueprint is an exemplar multiparadigm programming environment, built using the object based approach. It was implemented in order to prove the viability ....

Meyer B (1990) Lessons from the design of the Eiffel libraries. Commun. ACM, 33: 68--88.

....code sharing mechanism, inheritance is not much more powerful than import mechanisms such as C (and C ) s #include macro, or Ada s with clauses. Meyer argued that class inheritance is a developer (server) mechanism, and not a user (client) mechanism, and need not even be shown to clients 7 [22]. The C language enables developers to select the visibility of subclass relationships themselves, with the understanding that you can t use and 6. The actual (versus locally defined) pre conditions of a method consist of the logical disjunction of all the pre conditions ....

.... abstract (i.e. no implementation) classes can be quite useful: 1) they define the obligations of their subclasses (see below) 2) providing a conceptually clean organization of the class hierarchy, which can be its own reward, in addition to facilitating future evolution of the class hierarchy [22]. Abstract classes and subclassing may be used to define program families and generate family members. The abstract class itself embodies all the common aspects of the members of the family. These may consist either of Implementing Program Families Page 10 method specifications or of method ....

[Article contains additional citation context not shown here]

Bertrand Meyer, "Lessons from the Design of the Eiffel Libraries," Communications of the ACM, vol. 33, no. 9, pp. 69-88, September 1990.

No context found.

Bertrand Meyer. Lessons from the design of the Eiffel libraries. Communications of ACM, 33(9):68--88, September 1990.

No context found.

B. Meyer, `Lessons from the design of the Eiffel libraries', Commun. ACM, 33, (9), 68--88 (1990).

No context found.

B. Meyer, `Lessons from the design of the Eiffel libraries', Communications of the ACM, 33, 68--88 (1990).

No context found.

B. Meyer, 'Lessons from the Design of the EIFFEL Libraries', CACM 33(9):68-88, Sept 1990.

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