Open-Closed Principle

Software entities (classes, modules, functiones, etc.) should be open for extention, but closed for modification.
New functionality should be added by adding new code not by editing old code.

Common Closure Principle

The classes in a package should be closed together against the same kind of changes. A change that affects a package affects all the classes in that package.

Common Reuse Principle

The classes in a package are reused together. If you reuse one of the classes in a package, you reuse them all.

Interface Segregation Principle

Clients should not be forced to depend upon interfaces thet they do not use.

Liskov Substitution Principle

Functions that use references (or pointers) to base classes must be able to use objects of derived classes without knowing it.

Dependency Inverion Principle

• High level modules should not depend upon low level modules. Both should depend upon abstractions.
• Abstractions should not depend upon details. Details should depend upon abstractions.

Acyclic Dependencies Principle

The dependency structure between packages must be a Directed Acyclic Graph. That is, there must be no cycles in the dependency structure.

Law of Demeter

Each unit should have only limited knowledge about other units: only units closely related to the current unit.
Each unit should only talk to friends. Don’t talk to strangers.
A method should have lomited knowledge of an object model.
Inside a method, it is only permitted to access or send messages to the following objects:

• Arguments associated with the method (incl. “self”).
• Instance variables defined in the class containing the method being executed.
• Global variables.
• Temporary variables created inside the method.

Violation is characterised by:

1. Requesting an Object and then calling its method.

Functionality Rule

The classes should be partitioned according to use case functionality into packages.

Boundary – Controller – Entity Rule

The classes in a package should be divided into Boundary, Controller and Entity classes.

Specialisation and Generalisation Rule

Redundant behaviour and responsability should be taken out of the classes where it is found and placed in a single class.

Coherent Responsability and Interface Rule

The interface to a class should concentrate on providing a highly related set of operations.

Hierarchical, Modular and Layered Rule

• Large system should be build in layers.
• Within layers, classes should be organised hierarchicaly, with top level classes providing an interface to the layer, and the higher levels making calls to lower levels to fulfill detailed implementation.
• Within a layer, code should should be organized in loosely coupled and highly self-related classes.

Design by Contract

1. Separate queries from commands.
2. Separate basic queries from derived queries.
3. For each derived query, write a postcondition that specifies what result will be returned, in temrs of one or more basic queries.
4. For each command, write a postcondition that specifies the value of every basic query.
5. For every query and command, decide on a suitable precondition.
6. Write invariants to define unchanging properties of objects.

Encapsulation Rule

Interface should be separated from implementation.

Localize Depedency Rule

Entities should be defined in one place.

KISS

Keep it simple, stupid.

Tell, don’t Ask

Procedural code gets information then makes decisions.
Object-oriented code tells objects to do things.
Violation is characterised by:

1. Exposing Iterators instead of accepting orders.

Use Cases Role

Use Cases are used to describe an public interface of the system, not asa basis for the describtion of its internal sructure.
Violation is characterised by:

1. Massive use of “Control Objects” or “Managers”.
2. Parallel development of the Designs with the same functionality, but different implementations, which are difficult to merge later.