Reviews for The Design Patterns Smalltalk Companion

The average rating for The Design Patterns Smalltalk Companion based on 2 reviews is 4.5 stars.

Review # 1 was written on 2018-08-08 00:00:00 Thomas Allen Grady Booch is a well-known and highly respected software engineer who was one of the founders of the Unified Modelling Language (UML) used to develop object-oriented software. The first edition of this book predates UML, but both the second and the third edition are based on UML. In spite of Booch´s credentials and the fact that this book won an important award, I do not find this book very convincing or clear and would certainly not recommend it as an undergraduate textbook. To me, this book has the feel of having grown out of a collection of simplified case studies loosely tutored by Booch, prefaced by class notes and previous writings quickly cobbled together and in desperate need of masterful editing. The book is organized into three main parts Concepts Method ApplicationsIn my opinion, Applications is, hands down, the best part of the book and Concepts the worst. Having taught introductory object-oriented analysis and design courses for many years, I must admit that it is extremely hard to write a good textbook for this subject. You run the risk of falling into vague generalities on the one hand, and on the other, going into too much excruciating and painful detail. Unfortunately by postponing badly needed software examples until the third part of the book, the first two parts of the book were practically condemned to blow away into thin generalities. The first part of the book (Concepts) includes four chapters1. Complexity 2. The Object Model 3. Classes and Objects 4. ClassificationChapter one starts at a very general level and runs on for some five pages on the structure of plants and animals, the structure of matter and the structure of social organizations, before turning to the complexity of software and superficially touching some key aspects of software development: the complexity of its application domains, the difficulty of managing software development, software´s flexibility and so on. This chapter reads very much like a general introduction to systems engineering and tries, unsucessfully in my opinion, to provide a motivation and a narrative of how general system ideas eventually trickle down into algorithmic and object-oriented decompositions. Too many important terms and concepts are mentioned almost in passing without anchoring them deeply enough to make them intelligible and usable in a software development context. Chapter 2 (The Object Model) introduces such key concepts as abstraction, encapsulation, modularity, persistence, coupling, cohesion and typing with lots of hand waving, vague definitions and the occasional conceptual error. If you are an undergraduate student unfamiliar with these terms, you will find this chapter confusing; if you have some grasp of these concepts, I would recommend you skip this chapter. By chapter 3 (Classes and objects) and 75 pages into the book, the authors finally seem to be ready to come to grips with more substantial stuff, but again they shy away into the realms of the abstract and some humorous if not always pertinent drawings.. One would certainly expect one the founders of UML to provide a thoughtful, clear and precise introduction to UML class diagrams and the key relationships between classes, but unfortunately this is not the case, and again the reader must be satisfied with a rather vague and slipshod introduction. Thus we move into the second part of the book (Method) which is divided into three chapters, one on notation, one on process and one on pragmatics. The chapter on notation, which runs to about 100 pages, is an ok introduction to the 13 kinds of UML diagrams -to be honest I prefer Fowler´s UML Distilled or Miles and Hamilton´s Learning UML 2.0. The chapter on process distinguishes between agile processes and plan-driven processes and winds up adopting -unsurprisingly- a lightweight version of RUP. The book then distinguishes, rather confusingly between a development macro-process and a micro-process. The macro-process´s activities (requirements, analysis and design, implementation, test, deployment, project management, configuration and change management, and environment) are fit into inception, elaboration, construction and transition phases. A micro-process model is presented only for architectural and component analysis and design, its activities consist of identifying (object-oriented) elements, defining the collaboration between elements, defining the relationship between elements and defining the semantics of the elements (their attributes and behaviour). Thus, after 273 pages of introductory material, the book finally tackles the main subject of it´s title, object-oriented analysis and design. The book follows Krutchen´s well known 4+1 architecture view model, consisting of a requirements or use case view view, a logical view, an implementation view, a process view which describes the independent threads of control and a deployment view. The complete dearth of examples again hampers understanding, forcing most readers to attempt to fast forward into the applications and then come back to these chapters in order to make sense of such recommendations as: "Consider the presence of a semantic relationship between any two elements and establish an association if such a dependency exists". The part of the book devoted to method draws to an end with a chapter on pragmatics. Very few of the pragmatics are specifically related to analysis and design, and unfortunately the book again balloons up into generality on such topics as software development management, staffing, documentation and so on. Even the sections which are clearly important for analysis and design, such as Quality Assurance and Metrics manage to be singularly unhelpful. For example, the authors state that:Our primary focus here is on product metrics (sometimes called design metrics) that help the development team assess the artifacts of their analysis and design efforts. but defining the metrics and omitting guidelines or rules of thumb as to what the measures mean, hardly helps such assessment. The developers may come up with a number for, say, weighted methods per class (supposing one manages to come up with a reasonable weight scheme -another important omission) or the depth of an inheritance tree, but is that number telling him he has a good or a bad design on his hands? Booch et al stay mum on the subject, both in this chapter and in the applications sections where few if any metrics are reported. It is all well and good to say that in an inheritance tree, "...the more children a class has, the greater its impact on the software system´s design", but is this a positive or a negative impact? And adding that the greater impact is "...due to the reuse it produces" only further muddies the waters. Thus, ending what ought to be a key section on evaluating object-oriented analysis and design by stating:There is still disagreement about how object-oriented design principles contribute to software quality; consequently, there is still much debate about what constitutes an appropriate set of object-oriented metrics. is a cop-out and further adding We believe the metrics presented here provide a reasonable set of measures to assist the architect and component leads in assessing the quality of their object-oriented design. requires a blind leap of faith on the reader´s part. So after painfully slogging through 330 pages we finally reach the best part of the book, which describe the analysis and design of five applications:- A satellite-based navigation system; -A train traffic management system; -A simple cyptoanalysis application for deciphering single substitution cyphertexts; -Software for a weather monitoring station; -An employee vacation tracking system.In spite of the RUP-like framework, the analysis and designs lack unity, to me they show all the signs of having been tackled by different teams. Thus some of the case studies focus on the problem domain, while others (notably the vacation tracking system) focuses, in the inception phase, on a specific application environment, thus it starts by stating the design will implemented using Java, Java Server Pages (JSP), Tomcat,, J2EE, EJB ...that is to say, doing exactly the opposite of what has preached in the rest of the book by practically starting to the development from what appears to be more of a deployment, than a use case point of view. It is somewhat of a mystery to me why the applications are presented in the aforementioned order, since the most complex system is presented first and the simplest (the weather monitoring station software) almost last. In my opinion, there are many moot design decisions in most, if not all the case studies. For example, in the arguably simplest case study, the weather monitoring station there is a deep and narrow inheritance tree which derives temperature sensors and pressure sensors from trend sensors. This seems to place the cart before the horse, surely sensors do not capture trends, they capture point data. And surely it is overkill to define a pressure sensor as a subclass of a trend sensor which, in turn is a subclass of a historical sensor, which in turn is a subclass of a calibrating sensor? The train traffic management system is the case study that best states non-functional requirements, while the cryptoanalysis application makes a fine class project. Both the cryptoanalysis application and the vacation tracking systems more interesting aspects include the challenge of implementing rule-based systems. A blackboard-based approach is suggested for the cryptoanalysis framework while a more ad-hoc approach is proposed for the vacation tracking system. The satellite navigation system is the most complex but most original of the applications in an exciting but, for most students, little known domain. I particularly enjoyed each application´s section on post-transition in which the proposed architecture is "tested" by studying what changes would be required in order to add a a couple or so very reasonable new requirements. The one exception is the very poor corresponding section for the vacation tracking system. If you are interested in object-oriented analysis and design, by all means study the five applications carefully but take into account that, in my opinion, there are far better books on object-oriented analysis and/or design techniques by Martin Fowler, Robert C. Martin, Eric Evans and Craig Larman, amongst others.

Review # 2 was written on 2019-11-30 00:00:00 Donald Dunner The o-o bible according to my colleagues, so I worked through it and it did indeed have the whiff of being definitive. The revamped third edition has the advantage over the second in being generously illustrated with metaphors using cats and vegetables. A man after my own heart.