Smalltalk, Objects, and Design by Chamond Liu (1999)
After reading Extreme Programming explained I wanted to learn more about Smalltalk. You may ask why but the whole Agile / XP / OOP stuff grew out of Smalltalk. I heard of it before and knew that it works with a complete integrated development environment which can be saved as images. I think a great concept.
So I looked up some books and this one was recommended. Also I want to learn about some pure OOP. I know most of the basics but most of the time it felt clumsy. However, like often, great concepts get bend over time and you can really see their true nature. That also why I like older books on some topics.
I have a bit of a feeling that Smalltalk is to ‘enterprise’ software as lisp is to AI & co.
Humans as a metaphor for objects, e.g. ‘this account should be clever enough to check the balance’
I’m astonished by how good the book is written so far. Wow. Somehow I feel like I found some ancient tome which was hidden and I can learn from the ancient masters. Or I watched too much Skyrim the last week.
- ‘Objects promote a common vocabulary’
- ‘It is more important to concentrate on clear objects than on the side effects; unless the objects are clearly understood, they will be neither produce nor resuable.’
- ‘class’ as a factory (not really a collection)
- Subclasses have more qualities than the superclass
Smalltalk implementations work with a image, there’s an build-in object browser, a debugger, source control and a testing suite. Incredible if you think about how modern it was years ago. It really feels like the equivalent to lisp but in the enterprise field.
- ‘no one can expect to produce resuable designs without considerable trial and error.’
- Sarkela: ‘Not until you try to reuse do you discover what’s wrong.’
abstract class = class without any instances
- abstract classes are a repository for expectations
- pure virtual function (C++) / abstract method (Java) / subclassResponsibility (Smalltalk)
- Class-Responsibility-Collaboration Cards
- Responsibility: What should instances of the class ought to be able to do?
- collaboration: What class uses other classes?
- ‘Better to have accomplish something than nothing at all’ – regarding over-engineering
When (not) to inherit
- Example: Face has a Mouth has a Tongue
- Face inherits from Mouth inherits from Tongue – can do more
- Alternative: mix-ins, e.g. Face inherits from both Mouth and Tongue. Looks like inheritance but is a composition
- ‘Inheriting, thereby tightly coupling two classes, is a long-term commitment’
- Code reduction
- Subversive superclass message
- ‘If in doubt, consider buying’
- ‘In short, multiple inheritance adds power to a programming langauge, but at a cost of complexity.’
Use cases and dynamic relationship
- ‘Testers test what software does’
- ‘for many diagrams the chief benefit comes through the human exchange in which they were created’
Designing the UI
- Designing UIs for games are easier because the underlying metaphor is clear
- Designer has to have a (coherent) conceptual model
- Polymorphism = several classes with the same method evaluated at runtime
- Substitutability = if it works for a class it has to work for its subclass
I won’t list the pattern but rather my experience about them. I noticed that I could do a lot of these things easier using functional programming.
‘In the years to following publication of Alexander’s books on patterns [the originator of design patterns in architecture], he realized that patterns alone did not ensure that the results would have “the quality without name.”‘
So I decided to reread Norvig’s presentation about Design patterns. It’s mind-boggling how we ended up with C++ and Java.
Incredible book. I love it. I didn’t want to learn Smalltalk to write Smalltalk but to understand OOP better and especially the paradigm of ‘everything is an object’. This book worked great for that. The author writes superbly and is extremely humble. A great book.