The object-oriented thought process (4th ed.)

It is generally acknowledged that the successful development of a software product essentially depends on the process. Although important, technical considerations often play a minor role in producing successful software. The development process rationalizes the series of actions and decisions to make the end product meet the initial goals.

This book aims to guide the reader through the main concepts of object orientation, including encapsulation, inheritance, and composition. The book begins with elementary definitions of objects and classes before moving on to advanced topics such as design guidelines, serialization, persistence, and web services.

The book is written in a pleasant fashion, making it easy to read. Most topics are illustrated with comprehensible scholarly examples.

Having said that, I admit that I found the book rather disappointing. There are three main reasons for this. First, it is written as if it were a transcript of hand-waving discussions. For example, a class is a factory of objects, and not really a blueprint as the author states (page 17). The central notion of polymorphism (page 28) is unfortunately blurred into contrived examples without making the point clear. Polymorphism refers to the ability of a variable to hold object references that share a common interface. The circle, shape, and stack examples illustrate this point, but the section fails to present polymorphism in a crystal-clear fashion. On page 145, which is about abstract class, the author states: “An abstract class is a class that contains one or more methods that do not have any implementation provided.” This is inexact. An abstract class is a class that is considered incomplete by its author. As a consequence, an abstract class may indeed have implementations for all its methods (as was the case in an early version of JUnit, for example).

The second weak point of the book is its incompleteness. Whereas the benefits of inheritance and the use of frameworks are discussed at length, method overriding and super calls are not even mentioned. How can a framework be reasonably designed without mentioning these points? Unit testing is also not mentioned. It is widely acknowledged that clear design principles are hard to stick to without unit testing.

The third and maybe weakest point is the lack of a clear takeaway. The book offers many interesting discussions and examples about the relevance of thinking first about encapsulation, responsibilities, and promoting clear and efficient object design. However, these topics have been presented in many other books. The book does not specify any good and easy-to-apply techniques for promoting object-oriented design, which is still the source of many debates.

Although the author has made significant and lengthy efforts in this book (already in its 4th edition, covering nontrivial topics), I would not consider it an absolute must-read if one were looking for ways to become a better programmer.

Effective JavaScript : 68 specific ways to harness the power of JavaScript

The JavaScript wave began in 1995, and has largely become established as the new standard for creating lightweight client applications. JavaScript has a not-so-flattering reputation among programming language experts because it contains many odd features. Consider the (in)famous command, “3 + true,” which surprisingly returns 4. JavaScript was rapidly conceived (in about 10 days, according the preface of this book) and has been rapidly adopted, meaning that odd and suboptimal aspects of the language are likely to stay with us for a long time. So we have to deal with them, and this book is about exactly that: how we cope with the mysterious aspects of JavaScript.

The author aims to uncover many of the details and oddities an experienced JavaScript programmer might easily stumble on. The book reviews 68 items of the language that are considered error prone (for example, “Item 32: Never modify __proto__”) or counter-intuitive (for example, “Item 3: Beware of implicit coercion”).

The book concisely details obscure aspects of JavaScript. For example, it describes how to operate the lookup function over the parent and prototype links (Item 30). The book makes intensive use of short and independent examples, which are easily reproducible with a text editor and a web browser. The book is well written, with a pleasant writing style and format. Having the content broken down into items makes it easy to browse and search for particular solutions.

By focusing on singular aspects of JavaScript, the book often seems more intent on solving a technical challenge in JavaScript than on addressing practical software engineering issues. Several items gave me this feeling, including items 23, 24, 29, and 32. For example, “Item 23: Never modify the arguments object” advises the reader not to modify the collection of optional arguments. In fact, it is well known that programmers have a reputation of taking advantage of unthinkable situations, and modifying the “arguments” object indeed goes against all good programming practices. It is an easy path that produces hard-to-maintain software code. The reader is therefore left with the question of how often such problems occur in practice.

While he author highlights some important points about JavaScript, this book is not about learning the language. Authors who wish to learn JavaScript might consider reading another book [1]. On the other hand, people who make heavy use of JavaScript will find this book valuable. However, finding a particular point treated as an item in the book must not be taken as permission to use it in your own code. The book is about working with the oddities of JavaScript, and should not be considered as carte blanche to employ these mechanisms in your own code. Be kind to the engineer who will maintain your code in the future.

Practical Object-Oriented Design In Ruby

Crafting well designed software artifacts is tremendously difficult. As for most engineering activities, making the right choices is best achieved with the help of a wise and insightful guide. Practical Object-Oriented Design in Ruby is exactly such a guide.

The book brings the reader in a smooth journey into the realm of software design using Ruby, a dynamically typed object-oriented programming language. The book motivates and illustrates a fair number of programming design rules. The book innovates on essentially two points. First, it largely discusses the benefits of using a dynamically typed language. It presents "duck typing" as  a valuable asset to reduce development cost. Second, it highlights how Ruby's module nicely complements single class inheritance for a better productivity.

Unit testing is presented at the end of the book, in the last chapter. In my opinion, testing could have been introduced much earlier since most of the examples given in the book come with an expression to illustrate the intended behavior of the code. Such expression can perfectly be embedded in an assert, turning an ad-hoc expression into an automatic and repeatable scenario. In addition, unit tests are a wonderful tool to identify the right interface for objects, especially when compared with UML sequence diagrams.

Ruby, as well as most programming languages, offers a reflective mechanism which includes keywords such as kind_of?, is_a? and responds_to?. it is widely knows that using these introspective facilities reflect a fragile programming style. Although their use is not particularly advocated by the author, how to avoid using them is hidden behind the notion of polymorphism without being more precise. The double dispatch pattern has been proposed to not need to know more about the object identify than the strict necessary. I wish Sandi would have emphasized this point.

Leaving these two critics aside, Practical Object-Oriented Design In Ruby is well written. Chapters are well balanced with the right amount of examples, experience relating and theory. The writing style is both entertaining, easy to follow and accessible (I am here thinking about non-native English readers).

Although primarily written for Ruby programmers, fans of another programming language will  found valuable material. Beside Chapter 7, which is about sharing roles behaviors using Ruby modules, all the remaining chapters are pretty much loosely tied to Ruby. 

The book does not target people who wish to learn Ruby. Instead, it focuses on seasoned programmers who want to fine tune their design skills. Practical Object-Oriented Design In Ruby will nicely complement a reference on design patterns. 

Elemental Design Pattern

Design patterns have become a crucial piece of most curriculum in software engineering. Few software engineering techniques have been as successful as design patterns. Whereas the relevance of design pattern is indeed uncontested, the ground on which they are built on is still unclear. 

The book provides a strong foundation that is both programming language agnostic and meaningful to practitioners. It gives high level discussions and concrete anecdotes about the necessity to consider design patterns not only as a "tribal muse" or Art, but also as a science. Elemental design patterns are about understanding the reason why design patterns are the way they are. 
From a practical point of view, the book distances practitioners from the classical description on design patterns. Instead of giving a recipe as most of other books do, it teaches how to make and taste a good dish. 

For example, the Decorator is a rather complex design pattern for which understanding its range of application is not easy to grasp. As soon as one face a situation different from a scholar one, then deciding the applicability of the Decorator brings its own bag of incertitudes. Smith argues that the Decorator pattern is composed of four elemental patterns: Abstract Interface, Inheritance, Trusted Redirection, and Extend Method. Each elemental pattern being is simple concept, which, when put all together, describe "a fairly high-level abstraction".

The book presents 16 elemental design patterns. It then gives 5 intermediate patterns, themselves used to express 6 design patterns. Although the author does not claim all design patterns can be expressed with elemental patterns, it makes a strong case about a possible generalization.

This book is not yet another description of design patterns. If you wish to know more about design patterns, then this book is probably not ideal, as the author suggests.  However, if you have a clear need to go one step further than the classical literature on the topic, then Elemental Design Pattern brings fresh ideas. 

In particular, experimented software engineers who need a tool to express new patterns will find this book insightful. Researchers on design patterns will also find the book appealing. An example that is unfortunately not mentioned by the authors but very relevant is about code understanding. Mining design patterns is known to be a hard task. Since design patterns are expressed in terms of elemental patterns, then mining elemental design patterns may bring new research perspective that have not been considered so far. 

Applying a dynamic threshold to improve cluster detection of LSI

Program source code essentially fulfills two functions: telling the computer what it should do and telling human readers what the program is supposed to do. Unfortunately, human readers are not as good as compilers to understand what a programmer wish to tell. Latent semantic indexing (LSI) is commonly employed to cluster source code identifiers based on their frequency in a set of source codes. One compelling application of LSI is to give a meaning to the terms employed in source code.

Current LSI-based approaches require an arbitrary fixed threshold to say whether two identifiers are semantically related or not. One limitation of using a fixed threshold is to not be able to identify cluster in case of an asymmetric balancing. Dynamic hybrid cut "improves the effectiveness of LSI for detecting concerns in source code".

The approach is reasonable and intuitive. I particularly like the fact that their approach have been tried out on two industrial case studies. The article is easy to read, however it requires to be knowledgeable in LSI techniques.

Continuous delivery

"Continuous delivery" is about releasing reliable software through continuous and automated build, test and deployment. The principles of software delivery given in the book have been identified from multiple exposure by the authors to painful and costly maintenance issues. As said by the authors, the book is primarily recommended to developers, systems administrators, test and software managers.

This book is not recommended for a public greedy of academic and theoretical problems and solutions. The book adopted a practical stance to face problems regularly encountered by practitioners in the field.

The book is organized into 3 parts (foundations, the deployment pipeline and the delivery ecosystem) and totals 15 chapters. The first part gives the bit of theory that introduces the causes of reliability failure and motivates the need for a strong discipline among practitioners. The second part is about how to automatize the process that pulls a software from a version control to a deployment phase. The final part solves the technical obstacles encountered in practices, including managing the infrastructure and environment, software components dependencies and getting a good command of version control system.

By directly addressing the problems faced today by practitioners, the book describes technical tools such as version control systems. These tools are however fragile against evolution and new emerging tools, making the relevance of some chapters not sustainable. For example, CVS and Subversion are described, but not GIT, a new distributed version control system. The spread of GIT among projects will probably turn Subversion obsolete one day, as CVS has been replaced by Subversion. Even if some chapters may painfully ages, the problems and solutions given in the book will remain identical. Another weak point, is the short description of Hudson. Hudson is a popular continuous integration server. It has gained a large acceptance. A few pages on how to install and use it will have reduced the dependency of the book on external information source.

I highly recommend this book. It crystalizes in a easy-to-read manner the hard time given by achieving software reliability and maintenance. The problems and approaches to solve them apply to a very large range of software types. Even if the biography of the authors may suggest, this book does not solely apply to large industrial software but also to academic open-source small projects. As soon as you started to write code, a few classes or functions, tests and a delivery processes have be made explicit.

Touch of Class

As stated in the first sentence of the preface, «[Touch of class] is not just about learning to program but about “Learning to Program Well”». Meyer’s last book provides teaching material which has been gathered for more than a half a decade. It transmits an impressive experience in the field of computer science in general, going well beyond software engineering. This book does not assume any prior programming knowledge. It goes all the way up to modern programming by conveying wise advices, methodology, practices and historical anecdotes on how to achieve quality when programming. Software engineering concerns other than programming appears in the last chapters. The book's target audience is students and teachers.

Touch of class covers many different topics including the object paradigm, boolean logic, hardware, algorithm and many more. The goal of the book is certainly not to be exhaustive. Chapters named “Just enough ...” convey indispensable tools for good programming.

Object orientation and design by contract are central to the book. It successfully presents formals methods without loosing clarity. Instead of using complex mainstream languages, Eiffel Studio is the support for programming. Meyer argues in a convincing manner why Java is probably not the best language on Earth for an introductory course on programming.

A high importance is given to the vocabulary. Never a technical word is used without being carefully introduced. The large quantity of provided information is well organized. For example, “Touch of Style” boxes provides important and helpful advices on programming style whereas “Touch of Methodology” boxes give advices on programming methodology.

The book contains many figures. Rare are the pages left without a picture or a drawing. Colors are plentiful and character fonts plays an important role. The quality of the paper is high, making the tossing pleasant.

The book has a website (touch.ethz.ch), which contains supplementary material. At the time of writing this review, the website is announced but not yet available.

Coming from a father of object-orientation and software quality, it is not a surprise to find Touch of class an excellent book. It makes «the difference between a programmer who just “hacks code” and one who is able to produce correct, robust and durable software elements.»