1.2. The Three Extremes

Abstraction, separation of concerns , and readability underlie many of the guidelines. These notions parallel some of the ideas in Extreme Programming. If abstraction is good, Extreme Abstraction is better; if separation of concerns is good, Extreme Separation is better; and if readability is good, Extreme Readability is better. Many of the guidelines present an extreme position, so you can differentiate it from your current practices. You might wind up finding your own in-between position that balances the tradeoffs in a manner appropriate to your situation.

1.2.1. Abstraction

Abstraction is one of the key principles in an object-oriented system. You specify operations without specifying the details of how those operations will be implemented ”the "what" and not the "how." On one level, a system can be described with enough abstraction that either a manual, computer-aided, or automated procedure could implement it. However, sometimes a system is described so abstractly that you cannot imagine how it will operate until you can see a concrete realization, such as a prototype.

The flow of this book parallels abstraction. Operations and interfaces are stated in a language-insensitive manner, using only those facets such as classes, interfaces, and exceptions that are common to all object-oriented languages. Pseudocode is used to present the sequence and logic that an implementation might encompass . To demonstrate that the abstractions can become reality, code is shown after the interfaces have been defined on an abstract level.

As an example of Extreme Abstraction, one guideline suggests that concepts never be described with primitives (e.g., int or double ).

1.2.2. Separation of Concerns

Separation of concerns deals with splitting responsibilities between different classes, different methods , and different variables . As we will see in the sample system, a typical class is the Customer class. One can assign to this class any method that deals with the Customer class. Alternatively, one can create several classes that deal with the customer. These classes could include a CustomerData class for just holding the data; a CustomerPersistence class responsible for making the data persistent; a CustomerGUIDisplay class containing the widgets for displaying and inputting a Customer from a graphical user interface (GUI); a CustomerImportExport class that reads and writes textual representations of the data; a CustomerModel class that contains the behavior; and a CustomerBusinessRule class that contains the alterable rules for that behavior.

By separating a class into multiple classes, you allow for changes in one of the classes not to affect the other classes. If you change the GUI, for example, you do not have to change the business rules class. You might not necessarily want to split every one of your classes into as many classes as we do in the example system, but at least you should recognize that this is a possibility.

1.2.3. Readability

Code communicates to the computer and to the reader. Code should be written in a style that is understandable to all developers. The closer that code is to the requirements statement, the easier it is to match those requirements. As an example of Extreme Readability, one guideline suggests that your client or customer be able to read your code.