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.