Smalltalk Best Practice Patterns

by Kent Beck

The topics covered are the daily tactics of programming: • How do you choose names for objects, variables, and methods? • How do you break logic into methods? • How do you communicate most clearly through your code?

.pob

The advice is broken into 92 patterns. Each pattern presents: • a recurring daily programming problem; • the tradeoffs that affect solutions to the problem; and • a concrete recipe to create a solution for the problem.

how each pattern is represented in the book?

The patterns don’t stand in isolation, 92 independent bits of advice. Patterns work together, leading you from larger problems to smaller. Together they form a system or language. The system, as a whole, allows you to focus on the problem at hand, confident that tomorrow you can deal with tomorrow’s problems.

Programming—If you program in Smalltalk, these patterns will give you a catalog of techniques that work well. You will have discovered or invented many of them yourself, but the patterns may give you a fresh perspective on why they work or present nuances you hadn’t considered.

q: why should you read this book?

Managing—If you manage Smalltalk projects, you may be struggling with how to apply good software engineering principles to Smalltalk. These patterns don’t address that topic directly, but they can become the basis of a common vocabulary for your developers.

q: why should you read this book?

This book is for people who have programs to write and want to do so as quickly, safely, and effectively as possible.

pob: this book is about nuts and bolts of object oriented programming - as DHH puts it.

Best Practice—Best practice is a legal term. Looked at positively, best practice is the set of procedures and skills that professionals recognize and use.

def: best practice

Patterns—A pattern is a decision an expert makes over and over. For example, naming an instance variable after the role it plays is a pattern. Even though all the results (in this case, all the variable names) are different, they have a quality that is constant. The heart of this book is 92 such patterns.

def: Patterns

diff: coding process as agile method not as water fall model.

We aren’t always good at guessing where responsibilities should go. Coding is where our design guesses are tested. Being prepared to be flexible about making design changes during coding results in programs that get better and better over time. Insisting that early design ideas be carried through is short sighted. Often, I see some ugly code in an object. Based on the patterns in this book (most often Composed Method), I’ll suggest that the code be moved to another object.

q: why complete intial design(waterfall model) is short sighted?

My inspiration for the material in this book is my experience reviewing code. As I write, I remember more and more incidents, “Oh, yeah. That client was doing that wrong and it was really killing them. What can I say about that?” The advice I give in such situations is tactical, coding advice of necessity. I don’t have time for a deep understanding of their problem. I’m constantly amazed at how even a little help cleaning up small problems reveals the source and solution of much bigger problems.

ao: Tactical solution reveals source of bigger problems.

If you’re programming along, doing nicely, and all of a sudden your program gets balky, makes things hard for you, it’s talking. It’s telling you there is something important missing.

q: How your program talks to you?

Many of the patterns tell you what to do when your program talks to you. Sometimes you need to create a new method, sometimes a new object, sometimes a new variable. Whatever the needed response, you have to be listening before you can react.

q: Patterns tell you what to do when programms talk?

Some of the biggest improvements come from figuring out how to eliminate: • Duplicate code (even little bits of it) • Conditional logic • Complex methods • Structural code (where one object treats another as a data structure)

Some biggest improvments come from eliminating the following:

These patterns will give you a toolbox of problems to look for and ways to fix them. As time goes on, you’ll find yourself creating fewer and fewer problems in the first place. I hope you get better than me, though, at writing patterns correctly the first time. I still get myself into a pickle far too often.

q: How patterns will help programmer?

I can’t say it often enough—the bottlenecks throughout development come from limitations in human communication. Over and over in the patterns, you will read “You could do this or you could do that, but this over here communicates best, so that’s what you should do.”

q:most common source of bottlenecks?, link: clean code - intention revealing code.

If there’s a radical thought here, that’s it; that when you program, you have to think about how someone will read your code, not just how a computer will interpret it.

link: purpose of writing is for readers to understand. purpose coding is to write for interpretor to make a computer do an intended action and more importantly for the reader of code to understand it clearly.

I wrote the patterns so developers of all skill levels could learn more quickly and spend less time on the mechanics of engineering good software in Smalltalk.

I wrote these patterns from my experience of seeing which little things most often hurt projects.

There are a few things I look for that are good predictors of whether a project is in good shape. These are also properties I strive for in my code.

list: what follows is a list of predictors of good shape of project.

When you can extend a system solely by adding new objects without modifying any existing objects, then you have a system that is flexible and cheap to maintain.

***

Moving objects—Another property of systems with good style is that their objects can be easily moved to new contexts. You should be able to say, “This object in this system does the same job in that system.”

• Rates of change—A simple criteria I use all the time is checking rates of change. I learned this criteria from something Brad Cox said a long time ago. I’ve since generalized it to—don’t put two rates of change together. Don’t have part of a method that changes in every subclass with parts that don’t change. Don’t have some instance variables whose values change every second in the same object with instance variables whose values change once a month. Don’t have a collection where some elements are added and removed every second and some elements are added and removed once a month. Don’t have code in an object that has to change for every piece of hardware, and code that has to change for every operating system. How do you avoid this problem? You got it, lots of little pieces.

I did not understand the reason for this completely.

q: what follows is list of topics not covered in the book.

Performance tuning often sacrifices clarity for speed.

**

The definition of “coding” in the first section of this chapter, namely tactical programming decisions, excludes many topics.

Book Organization Here are the chapters:

how book is organized?

Whole hog—Read the patterns through once quickly. Then set this book on your lap as you program. Every time you are about to do anything—write a method, name a variable, name a message—look it up first. When you are sure you are following a pattern, you can quit looking it up. At first, this is sure to be frustrating, and the more experience you have before you start, the more frustrating it will be.

q: how I will be using this book?

Why does this work? I think it is because when I used to program, I would constantly have two parallel conversations going on in my head—what should I name this variable and how should I approach naming this variable. I was always looking for exceptions to my rules, trying to gain some small advantage. When I chose to follow the patterns explicitly, that second conversation disappeared and I paid more attention to the problem I was solving.

one of the most important benefit of pstterns: it allows your mind to focus completely on solving problem. it frees mind from programming language related aspects- u already know the approach.

Interest in software reuse reveals a recognition that software engineering is just as repetitious as other engineering disciplines.

def: pattern. a common solution to a general problem.

Patterns lead naturally one to the other, forming a kind of flexible fabric of decisions that can solve large scale problems.

Here is the Big Assumption: There are only so many things objects can do. Not in the sense that there are a limited number of applications, because there will always be new domains to model, but in the sense that the same structures of objects keep appearing over and over, regardless of the application. The problems in the construction of objects are universal. You have to name classes, relate classes via inheritance and delegation, relate methods in the same class and different classes, name variables, and so on. Patterns record these problems and how to approach solving them.

***, what patterns do?

When the hardest problem is solved, something else becomes the hardest problem. The next bottleneck in software engineering is human communication. When we say that 70 percent of the development budget is spent on maintenance, we mean that the poor maintainers have to wade through piles of documentation and code to discover the intent of the original programmer.

q: why 70% of software project is maintenance ?

When you want to improve communication, you have two choices; either increase the bandwidth so you can communicate more bits or increase the context shared between sender and receiver so the same number of bits mean more. The first is impractical, especially in the presence of reuse (one developer can only be sliced into so many pieces), so we must find some way to make our words mean more.

Patterns are a literary form for capturing and transmitting common practice.

***, link: How patterns relates to writing?

Objects model the world through behavior and state. Behavior is the dynamic, active, computational part of the model. State is what is left after behavior is done, how the model is represented before, after, and during a computation.

***, o: seperating computations into messages and methods and dynamically sending messages to apt classes is small change that makes big difference.

Well, separating computation into messages and methods and binding the message to the method at run time, based on the class of the receiver, may seem like a small change from an ordinary procedure call, but it is a small change that makes a big difference.

q: how oop makes big difference? diff: message vs method: Message(call in traditional oops languages) is what is being sent to the receiver. Method is what message gets binded to in the receiver.

Methods must do the work they are supposed to do but they must also communicate the intent of the work to be done.

p: methods should serve 2 purposes: 1)Computation 2)Intention revealing names

Carefully breaking a computation into methods and carefully choosing their names communicates more about your intentions to a reader than any other programming decision, besides class naming.

Methods are the granularity of overriding. A well factored superclass can always be specialized by overriding a single method, without having to copy part of the superclass code into the subclass.

small methods not only communicates bteer but also help in minimizing duplication, allows better overrding etc...

Overall, the goal of breaking your program into methods is to communicate your intent clearly with your reader, provide for future flexibility, and set yourself up for effective performance tuning where necessary.

q: breaking the program in small methods to improve code readability.

You are implementing a method named with an Intention Revealing Selector (p. 49).

Selectors are name that are used to select a method or anything else. analogy: css selector

The decision is complicated by the many factors affecting it and the history of programming practice that has traditionally optimized machine resources at the cost of people’s time.

his: historically (when machines were very costly) machine resources(time) were costlier than developer time.

Messages take time. The more small methods you create, the more messages you will execute. If all you were worried about was how fast your program would run, you would arrange all of your code in a single method. This radical approach to performance tuning invokes enormous human costs and ignores the realities of performance tuning well-structured code, which often results in several order-of-magnitude improvements.

q:why small intentions revealing method is better than optimized program that are hard to read.

The opportunity to communicate through intention revealing message names is the most compelling reason to keep methods small.

**

Small methods ease maintenance. They let you isolate assumptions. Code that has been written with the right small methods requires the change of only a few methods to correct or enhance its operation.

***, o: Small methods isolate assumptions.

Small methods also make inheritance work smoothly. If you decide to specialize the behavior of a class written with large methods, you will often find yourself copying the code from the superclass into the subclass and changing a few lines. You have introduced a multiple update problem between the superclass method and the subclass method. With small methods, overriding behavior is always a case of overriding a single method.

o: small methods make inheritence smooth.

Divide your program into methods that perform one identifiable task. Keep all of the operations in a method at the same level of abstraction. This will naturally result in programs with many small methods, each a few lines long.

***, link:keeping all the operations of a function at the same level of abstraction, In other words function name should be at a one higher abstraction level than the operations of the function. DHH mentions this rule as single most important rule that results in good. Uncle Bob also emphasizes on this rule. https://7php.com/interview-dhh/

You can use Composed Method top-down. While you are writing a method, you can (without having an implementation yet) invoke several smaller methods. Composed Method becomes a thought tool for breaking your development into pieces. Here is an example of a top-down Composed Method: Controller>>controlActivity self controlInitialize. self controlLoop. self controlTerminate You can also use Composed Method bottom-up, to factor common code in a single place. If you find yourself using the same expression (which might be only 3 or 2 or even 1 line of code), you can improve your code by putting the expression in its own method and invoking it as needed.

top-down and bottom-up ways of ways of composing methods. Both ways have their advantages.