Learning Object-Oriented Programming, Design with TDD in Pharo

I started to write this book back in 1998 when I wrote around 900 pages in preparation for ''Learning Programming with Robots''. Apparently I needed to write to understand what I wanted to explain and how. From this I extracted ''Learning Programming with Robots'', which was a book to teach simple concepts such as variables, loops, procedures and to help people teach kids how to program. But in fact, I got really frustrated because to be understandable by everyone I had to remove what I like: object-oriented programming and good object-oriented design. At that time, I met Harald Wertz, who gave me nice ideas and pointers such as L-systems, then asked why I focused on procedural thinking and suggested that I teach object-oriented programming instead. And he was right. This remark was like a bee in my bonnet for more than ten years. In fact, it was my original objective but I was exhausted after my first attempt. Now, nearly fifteen years later, I'm ready to write a book to start with object-oriented programming. In fact I rewrote everything I got from that time. I hope that you will enjoy it as much as I did — even if, for me, writing a book is a really long and daunting task because I want to make it great.

I would like to present the concepts that I want to teach you and that hopefully you should acquire. What is key to understand is that I will focus on the ''key'' conceptual elements. It is easy for me because I will not explain OOP/D in general but within the context of Pharo and Pharo is the essence of Object-Oriented programming since its object model is minimal but it covers the key and essential aspect of OOP. For example we will not present method modifiers, types, overloading (which is a bad concept).

We will focus on object-oriented ''programming'' concepts:

• Objects / Classes
• Messages / Methods
• self and its semantics
• Inheritance
• super and its semantics

…and on object-oriented ''design'' concepts:

• Class responsibility collaboration
• Delegation
• Message sends are choice
• Message sends are plans for reuse
• The "Don't ask, tell" Principle
• Tests are your life ensurance
• Polymorphism

In addition we will also present

• Tests
• Software refactorings

About growing software. Often books present a problem and its solution. Now for non trivial problems, the solution does not fall from the sky or get developed in one stroke but it is the constant evolution of a first solution that evolves over time. Such an evolution is often difficult and tedious because the developer jumps from one stable state to a situation where his code may not work anymore. This is where Test Driven Design and refactorings really help. Test Driven Design helsp to focus on new features and captures them as executable entities: tests. Refactorings helps by transforming code without breaking its invariants. Note that tests do not forbid to break code, they help identifying when previous invariants or constraints got violated. Sometimes violated tests identify a bug but they may be broken just because the requirements changed and that the tests should be updated. In this book, I wanted to see how software grows in little steps. This is is what I do frequently during my coding sessions and I think that this is important to cover the hidden paths in software creation.