Principles

Communicate

• Code should be easy to read and understand. Focus on communication. This affects profitability too.

Flexibility

• Flexibility comes at a cost. Don’t worry so much about writing something so that it may be flexibile tomorrow - because you don’t know whether you will need that flexibility when you come back to change the code.
• Writing flexible code is good when immediate benefits are borne.

Principles

(a) Local Consequences

Ideally you don’t want to read 10 different files before understanding something now. Nor do you want to fear 10 other files given you are working on a particular piece of code.

(b) Repetition

If you repeat something, the cost of change becomes expensive. But if you avoid repetition, then watch out: because any change you make will apply everywhere.

(c) Logic and Data Together

• Because if you change one you are likely to change the other. And if they are together, then changes can be localised.

(d) Symetry

• e.g. add() comes with remove(), or in Rails, consider the ! bang method often accompanies a change. Symetry: you realise this and get this for free, without having to look up a manual.

(d) Declarative Expression

Ideally you don’t want to read 100 other things to understand what some code is doing.

(e) Rates of Change

If variables change roughly at the same rate, then apply them together. i.e. if two fields change, basically at the same time. e.g. when one method is invoked, it might be better to separate them out in a different object.

class Person
	string name
	date date_of_birth
	list shopping_items
end

# In the above, the list of shopping items changes at a different rate to the person's name, and their date of birth. Accordingly, it might be better to separate them out into a different class.

Motivation

• Software is expensive when it cannot be understood, or maintained.
• Generally, it is very difficult to pre-empt future software requirements - so don’t do it, especially if you have to put down a significant amount of time today, in order to get it done.

Class

Naming

• Find a good, short, expressive name.
• Sub-classes, should communicate that they are a sub-class, and should be accurate.

Many patterns are introduced:

(b) Abstract Interface

• Introduce flexibility (via interfaces) generally when you need it. And it is hard to predict when you will actually need it.
• Some things in software will not need to change; other things will, for a variety of reasons.

(c) Abstract Class

(d) Versioned Interface

• Extend an interface if changing an existing one is too costly. But then you’ll have to downcast whenever you need to use it.

(e) Value Object

• We want to create a mathematical world - of pure functions, rather than holding (and managing state). Beck encourages us to do the former as much as possible.

• You must make clear / draw boundaries between value style objects, and objects which change state. e.g. Transaction is like a value object, but the Account object holds the changing state of the account.

I kinda wish that that AutoCAD .net API offered a value styled way of thinking of drawings, rather than a Database style way of thinking of them. You can translate lines itself, rather than create new lines and persist them to the database. Perhaps this would have been a better and easier way of managing the database than the current API. In the Tekla API, things are confusing. Is this mutable? Does this return a value? Who knows! Such APIs frustrate users.

Beck offers the following as an example:

bounds.translateBy(10,20) # this is a mutable rectange
bounds = bounds.translateBy(10,20) # value style recctange. Beck encourages this style.

Sometimes you may have a combindation of state changes objects and objects representing mathematical objects.

(f) Subclass

• Instance specific behaviour may be confusing to new readers.
• The more if statements, the more paths of execution, and the higher the likelihood of bugs etc, especially if those conditionals are duplicated.
• Beck illustrates where delegation can be useful: pros/cons. Evaluating this can only be gained with experience.
• Pluggable Selector: Beck is not clear with the examples here, nor the purpose.