What do you think?
Rate this book
Principles of Object-Oriented Software Development
(Pearson Education) Presents both the benefits and the pitfalls of object-oriented technology across every stage of the software development cycle, from analysis to programming. Previous c1994. Softcover.
502 pages, CD-ROM
First published January 1, 1995
Ratings & Reviews
Friends & Following
Create a free account to discover what your friends think of this book!
Community Reviews
Displaying 1 of 1 review
July 15, 2017
Is it worth reading the 1995 edition of this book in 2015? Take into account that this book was written before Java (1995), makes no mention of the fledgeling UML (1994), before the classic book on design patterns(Design Patterns: Elements of Reusable Object-Oriented Software by Eich Gamma, Richard Helm, Ralph Johnson and John Vlissides, 1995) hit the street, before Barbara Liskov and John Guttag’s 2001 explanations about reasoning about the substitution principle by applying the signature rule, the methods rule and the properties rule (Program Development on Java) and before the Manifesto for Agile Software Development (2001).
It does provide a good, if uneven, overview of the state of object-oriented software development research at that time. While the author claims indicates that
The main, still familiar object-oriented languages mentioned in the text are SmallTalk, Eiffel and language used for most of the (small) programming examples, C++.
Nowadays the text comes across as repetitive, especially on the chapters dealing with formal specifications, type theories, classes and object-oriented constructs, which shoot past Z, CSP, initial algebras, generic abstract data types and type calculus, and Hoare logics amongst others. That is, a lot of material for any undergraduate, or even graduate course. Since I spent over a decade working on formal specifications (1978-1988), this was a pleasant trip down memory lane. However in the end only Eiffel’s elegant use of preconditions, postconditions and class invariants comes across as truly relevant material bridging specification theory with actual object-oriented programming practice, unless you are particularly interested in type theory.
I was intrigued by a brief section outlining dynamic typing,which allows an object to change or even switch between roles -unfortunately the section does not reference any literature on this idea. Dynamic typing would allow a Person object sometimes to behave as a Student and sometimes as a Professor, according to his current role when sent sent a message. This idea seems to an an extension of variant records to the object-oriented world as well as generalize the idea of an object’s state, since an object in a certain role may respond to different messages than when it is in another role -for example a person in a Professor role may correct an exam but not take it, while the same person in a Student role may take an exam but not correct it.
The chapter on concurrency and distribution was the one I enjoyed most, in spite of its lack of real depth. I am not entirely sure why I enjoyed it so much; I think it was because it is an elegant overview of attempts to match mechanisms of concurrency into objects. Occasionally it merely references an idea in passing:
Eliëns also provides a very half-hearted attempt at providing an overview of the problem of persistent objects -or maybe the brunt of the research into this area was carried out after 1995 -after all, for example, Michael Blaha and William Premerlani’s Object-Oriented Modeling and Design for Database Applications was published in 1998.
From the title of the book, one would expect more than the three chapters devoted to the subject (3. Object-oriented design, 4. Software engineering perspectives, 11. Libraries and environments) but they are rather disappointing. This is not the author’s fault, the book simply reflects that at the time there was more work being carried out on the semantics of classes, inheritance, polymorphism, delegation and objects, the design of object-oriented programming classes and the exploration of the programming paradigm.
To Eliën’s credit he manages to underline the growing importance of callbacks and the MVC pattern -which he overviews in a section titled The MV(C) paradigm. He also points out the growing number of analysis and design diagrams (use cases, domain object models, subsystems, block model, interaction, dynamic model, functional model, timing state, process model, CRC) being proposed at the time in methods such as Objectory, OMT, Fusion and Booch’s work -which were on the brink of leading to UML-, but also warns about the lack of precise semantics for many of those diagrams and the difficulties in enforcing or checking consistency between different kinds of diagrams.
There is a fascinating section on Guidelines for design on topics which turned out to be rather of a dead end in research, at least in the simplistic way they are covered in the book: metric suites based on a weighted sum of methods per class, the depth of inheritance, the number of subclasses, coupling between objects (or classes) measured just by the number of invoking and invoked methods between the objects (or classes) and a rather airy-fairy definition of cohesion. The author picks up Chidamber and Kemerer’s 1991 evaluation criteria for metrics (non-coarseness, non-uniqueness, permutation, implementation, monotonicity, interaction and combination) and exhaustively shows which evaluation criteria are satisfied by which metrics and which are not. However, this all remains disconnected from reality. For example it is one thing to state which evaluation criteria the weighted sum of methods satisfies, and another to state what sort of a number constitutes a good design or forces the designer to reconsider his classes. A stack class is defined by six methods (one to construct a new, empty stack, push, pop, top and a method that returns whether or not a stack is empty, a deque requires nine methods, but how many methods are required in a nice, useful design of a string class? Is it better to have more or rather less methods? For example if I change the stack class so that pop and top are combined into just one method, is my class design better or worse? The underlying mistake is to reduce the notion of coupling to a number of methods, without taking into account the amount and kind of information carried by the method’s invocation. By reductio ad absurdum, one can arbitrary reduce the amount of coupling between objects by defining one gigantic object with no methods, but then the object has no coherence. And, as Eliën wittily observes, designing a system as a host of tiny objects wildly communicating between them leads to hard to understand and reuse ravioli code, the object-oriented equivalent to spaguetti code in procedural programming.
Eliën’s book was also published too early to cover testing object-oriented software, a topic which I feel only began to take off after Kent Beck and Erich Gamma developed JUnit and the use of mock objects in testing began to be thoroughly explored and developed.
Eliën occasionally suggests confusing object-oriented designs. For example, in the context of modeling a Library he proposes a class called Book and another class called Person. Lending a book links a Person object to a Book object and viceversa, however Eliën confuses the design by defining borrow and return methods, as well as a query method inLibrary to the Book class and allocate and deallocate methods to the Person class. Thus, in Eilen’s design, in order to lend a book b to a person p, some unknown object needs to send a message to the book b passing p as a parameter -that is b.borrow(p)- and also needs to send a message to the p person to allocate him or her the book b -that s p.allocate(b). This is needlessly complicated and pretty unsafe -Eliën’s example does not enforce that the person returning a book has to be the same person who borrowed it, or that the book being deallocated is a book previously allocated him, or even that in order to lend a book it must be available, or that to lend a book it must both be borrowed and allocated consistently. If we see this example from an Entity-Relation data model viewpoint, we can see that a more natural model entails defining two entities, Book and Person and a relation, say Lent between them. In Eliën’s model, the Relation is not a class and thus needs to be split up and forced into the classes modeling the entities. Eliën’s design is interesting, but books have become strangely aware of who they are lent to and whether they are in the Library or not…
Chapter 11, Libraries and environments is quite peculiar and throws together quite a mixed bag of topics. By looking at Eiffel libraries, he covers such topics as naming conventions for methods in library classes, the use of an obsolete clause and appropriate taxonomies of classes. In particular, he highlights Eiffel’s access taxonomy of container classes:
While I found it fun to take time out to read this book, I would not recommend it to readers who have been introduced to object-oriented programming and are looking to broaden or deepen their knowledge. I would recommend this book to readers with a good working knowledge of an object-oriented programming language and a historical interest in formal specifications, type theory or concurrency.
It does provide a good, if uneven, overview of the state of object-oriented software development research at that time. While the author claims indicates that
It reflects the contents of an upper-level undergraduate course on Object-Oriented Programming, given at the Vrije Universiteit Amsterdamin my opinion, it would have probably worked better as an M.Sc. Level course if supplemented with some of the research papers cited in the book.
The main, still familiar object-oriented languages mentioned in the text are SmallTalk, Eiffel and language used for most of the (small) programming examples, C++.
Nowadays the text comes across as repetitive, especially on the chapters dealing with formal specifications, type theories, classes and object-oriented constructs, which shoot past Z, CSP, initial algebras, generic abstract data types and type calculus, and Hoare logics amongst others. That is, a lot of material for any undergraduate, or even graduate course. Since I spent over a decade working on formal specifications (1978-1988), this was a pleasant trip down memory lane. However in the end only Eiffel’s elegant use of preconditions, postconditions and class invariants comes across as truly relevant material bridging specification theory with actual object-oriented programming practice, unless you are particularly interested in type theory.
I was intrigued by a brief section outlining dynamic typing,which allows an object to change or even switch between roles -unfortunately the section does not reference any literature on this idea. Dynamic typing would allow a Person object sometimes to behave as a Student and sometimes as a Professor, according to his current role when sent sent a message. This idea seems to an an extension of variant records to the object-oriented world as well as generalize the idea of an object’s state, since an object in a certain role may respond to different messages than when it is in another role -for example a person in a Professor role may correct an exam but not take it, while the same person in a Student role may take an exam but not correct it.
The chapter on concurrency and distribution was the one I enjoyed most, in spite of its lack of real depth. I am not entirely sure why I enjoyed it so much; I think it was because it is an elegant overview of attempts to match mechanisms of concurrency into objects. Occasionally it merely references an idea in passing:
...a number of alternative parameter passing mechanisms may be thought of, mechanisms that provide support for object migration and (partial) replication. These include call-by-share (which is employed for the language Orca, see Bal(1991)), call-by-unification (which is employed in DLP), and call-by-move and call-by-visit (which are supported by the language Emerald, Black and Hutchinson(1986).No definition or explanation is given for these mechanisms.
Eliëns also provides a very half-hearted attempt at providing an overview of the problem of persistent objects -or maybe the brunt of the research into this area was carried out after 1995 -after all, for example, Michael Blaha and William Premerlani’s Object-Oriented Modeling and Design for Database Applications was published in 1998.
From the title of the book, one would expect more than the three chapters devoted to the subject (3. Object-oriented design, 4. Software engineering perspectives, 11. Libraries and environments) but they are rather disappointing. This is not the author’s fault, the book simply reflects that at the time there was more work being carried out on the semantics of classes, inheritance, polymorphism, delegation and objects, the design of object-oriented programming classes and the exploration of the programming paradigm.
To Eliën’s credit he manages to underline the growing importance of callbacks and the MVC pattern -which he overviews in a section titled The MV(C) paradigm. He also points out the growing number of analysis and design diagrams (use cases, domain object models, subsystems, block model, interaction, dynamic model, functional model, timing state, process model, CRC) being proposed at the time in methods such as Objectory, OMT, Fusion and Booch’s work -which were on the brink of leading to UML-, but also warns about the lack of precise semantics for many of those diagrams and the difficulties in enforcing or checking consistency between different kinds of diagrams.
There is a fascinating section on Guidelines for design on topics which turned out to be rather of a dead end in research, at least in the simplistic way they are covered in the book: metric suites based on a weighted sum of methods per class, the depth of inheritance, the number of subclasses, coupling between objects (or classes) measured just by the number of invoking and invoked methods between the objects (or classes) and a rather airy-fairy definition of cohesion. The author picks up Chidamber and Kemerer’s 1991 evaluation criteria for metrics (non-coarseness, non-uniqueness, permutation, implementation, monotonicity, interaction and combination) and exhaustively shows which evaluation criteria are satisfied by which metrics and which are not. However, this all remains disconnected from reality. For example it is one thing to state which evaluation criteria the weighted sum of methods satisfies, and another to state what sort of a number constitutes a good design or forces the designer to reconsider his classes. A stack class is defined by six methods (one to construct a new, empty stack, push, pop, top and a method that returns whether or not a stack is empty, a deque requires nine methods, but how many methods are required in a nice, useful design of a string class? Is it better to have more or rather less methods? For example if I change the stack class so that pop and top are combined into just one method, is my class design better or worse? The underlying mistake is to reduce the notion of coupling to a number of methods, without taking into account the amount and kind of information carried by the method’s invocation. By reductio ad absurdum, one can arbitrary reduce the amount of coupling between objects by defining one gigantic object with no methods, but then the object has no coherence. And, as Eliën wittily observes, designing a system as a host of tiny objects wildly communicating between them leads to hard to understand and reuse ravioli code, the object-oriented equivalent to spaguetti code in procedural programming.
Eliën’s book was also published too early to cover testing object-oriented software, a topic which I feel only began to take off after Kent Beck and Erich Gamma developed JUnit and the use of mock objects in testing began to be thoroughly explored and developed.
Eliën occasionally suggests confusing object-oriented designs. For example, in the context of modeling a Library he proposes a class called Book and another class called Person. Lending a book links a Person object to a Book object and viceversa, however Eliën confuses the design by defining borrow and return methods, as well as a query method inLibrary to the Book class and allocate and deallocate methods to the Person class. Thus, in Eilen’s design, in order to lend a book b to a person p, some unknown object needs to send a message to the book b passing p as a parameter -that is b.borrow(p)- and also needs to send a message to the p person to allocate him or her the book b -that s p.allocate(b). This is needlessly complicated and pretty unsafe -Eliën’s example does not enforce that the person returning a book has to be the same person who borrowed it, or that the book being deallocated is a book previously allocated him, or even that in order to lend a book it must be available, or that to lend a book it must both be borrowed and allocated consistently. If we see this example from an Entity-Relation data model viewpoint, we can see that a more natural model entails defining two entities, Book and Person and a relation, say Lent between them. In Eliën’s model, the Relation is not a class and thus needs to be split up and forced into the classes modeling the entities. Eliën’s design is interesting, but books have become strangely aware of who they are lent to and whether they are in the Library or not…
Chapter 11, Libraries and environments is quite peculiar and throws together quite a mixed bag of topics. By looking at Eiffel libraries, he covers such topics as naming conventions for methods in library classes, the use of an obsolete clause and appropriate taxonomies of classes. In particular, he highlights Eiffel’s access taxonomy of container classes:
ContainerThe author also mentions non-standard subtyping also known as non-strict inheritance which highlights the confusion between using inheritance as programming shorthand and using it as subtyping. Take for example the class of Rectangle objects and the class of Square objects. Conceptually, Square should be a subclass of Rectangle (standard subtyping), which means that squares may respond to methods requesting their length and width and the Square class may include a new method called side since in a square its length is equal to its side. However from a programming point of view this may be inefficient, since Square inherits both a length and a width attribute, when one single side attribute suffices. Thus from a programming (non-standard subtyping) point of view a Rectangle should be defined as a subclass of Square! As far as I know every formal reasoning framework extant for object-oriented design eschews or at least frowns on non-standard subtyping.
→ Container
-----→ Collection
---------→ Set
----------→ Bag
----------------→ Dispenser
----------------------→ Stack
----------------------→ Queue
----------------→ Cursor
----------------------→ List
----------------------→ Tree
-----→ Table
---------→ Indexable
---------→ Hash
While I found it fun to take time out to read this book, I would not recommend it to readers who have been introduced to object-oriented programming and are looking to broaden or deepen their knowledge. I would recommend this book to readers with a good working knowledge of an object-oriented programming language and a historical interest in formal specifications, type theory or concurrency.
Displaying 1 of 1 review