CLASS DESIGN PRINCIPLESLecture 2

The quality of the architecture• What is a good design? It is the design that at least does

not have signs of “bad”.• What is a bad design? • Signs of a bad design:

• Rigidity• Fragility• Monolithic• Viscosity• Unjustified complexity• Duplication• Obscurity

Rigidity• Design is rigorous if one change involve cascade of

subsequent changes in the dependent modules.• The more modules change, the more the project is

rigorous.

Fragility• The project is fragile, if when you make one change to the

program is «destroyed» in many places.• New problems often occur in places that are not

associated with the changed component.• In the process of fixing bugs new errors appear.

Monolithic• The project is a monolithic one, if it contains components

that can be reused in other systems, but the effort of involving the isolation of a component are too large.

• As a result the duplication of source code increases.

Viscosity• The project is viscous, when you implement any

functionality much easier with “wrong” methods (actually using anti-patterns).

• When implementing the functionality with “wrong” methods the probability of making a mistake is high, and the implementation of the “correct” methods is too complicated.

• As a result the cost and time of implementation the functionality unnecessarily increases.

Unjustified complexity• The project has unjustified complexity if it contains

elements that are not used at the present time (and probably will never be used).

• It occurs when developers try to foresee possible changes in the code and conduct activities associated with these potential changes.

Architecture principles • Robert Martin made a list of the five principles of

improving the design:

1. the principle of uniqueness responsibility (SRP, The Single Responsibility Principle),

2. the principle of openness/closeness (OCP, The Open Closed Principle),

3. the principle of the Liskov substitution (LSP, The Liskov Substitution Principle),

4. the principle of separation of interface (ISP, The Interface Segregation Principle),

5. dependency inversion principle (DIP, The Dependency Inversion Principle).

Coupling• Coupling (connectivity) is a measure that determines how

tough one item is associated with other elements, or how many data about the other elements it has.

• The design needs to ensure the lowest coupling.• The element with a low degree of coupling depends on a

not very large number of other elements and has the following properties:

1. A small number of dependencies between classes (subsystems)

2. Weak dependence of one class (subsystem) on the changes in the other class (subsystem).

3. A high degree of re-use subsystems.

Cohesion• Cohesion (functional connectivity) is a measure of the

focus responsibilities of the class.• An object possesses a high degree of cohesion, if its

responsibilities are closely linked.• Object with a low degree of cohesion performs many

different functions or unconnected responsibilities.• A weak cohesion leads to the following issues:

• the difficulty of understanding• the complexity of re-use• the complexity of support• insecurity and constant exposure to changes

The principle of uniqueness responsibility

• A class or a module must have one and only one reason to change.

• Consequences of the violation:• Monolithic• Potential duplication• Big classes

• The effect of the use:• Compact classes• Reduction of coupling• Increase of cohesion

The principle of uniqueness responsibility

• Let us have a class representing a certain product with a built-in data validation.

The principle of uniqueness responsibility

• Suppose that the object of the product was used by some object “CustomerService” that uses a different algorithm validation:

The principle of uniqueness responsibility

• It is very likely that soon the new algorithms of validation will be added. It becomes clear that a separate object must be responsible for the validation of the data.

The principle of uniqueness responsibility

• The implementation of the class of product will change as follows:

The principle of uniqueness responsibility

• Now the object will be used as follows:

The principle of openness/closeness• The software entities should be open for extension but

closed for changes• Consequences of the violation:

• Fragility

• The effect of the use:• Increase flexibility of the system. • Simplify testing.

The principle of openness/closeness• Let us consider a hierarchy of classes used to represent

objects in the database (so-called meta-object). The root essence of such a hierarchy would be the following class:

The principle of openness/closeness• Let us denote classes tables and views:

The principle of openness/closeness• Class Field might look like this:

The principle of openness/closeness• Let us now consider the class SqlDumpGenerator, which allows to get an SQL script

that creates the specified database objects:

The principle of openness/closeness• This class violates the principle of openness/closeness,

because in order to add a new functionality (for example, a new child of the class MetaObject) you need to modify the function “Generate”.

• It is obvious that the observance of the principle should create a method “GetCreateScrip”t in class “MetaObject”

The principle of openness/closeness• Now when you add new objects, there is no need in

modification of the method “Generate”, it suffices to add the class child of MetaObject.

• Note, however, that if the function “Generate” should add scripts to create in a different order (for example, first add all the tables, and then all of the views), there arises a need in modification.

• Generally speaking, there is always such a change, which would require modification but not addition to the source code. The developer must determine the most likely changes and create abstractions that help to guard against these changes.

The Liskov Substitution Principle• Let q(x) is the property faithful relatively concerning x of

type T. Then q(y) should be true for objects y of type S, where S is a subtype of type T.

• Functions that use references to base classes must be able to use objects of derived classes without knowing it.

• Consequences of the violation:• Violation of abstractions.• The difficulty of the test.

• The effect of the use:• Clear definition of abstractions. • Simplify testing. • Simplification of understanding of the code.

The Liskov Substitution Principle• Consider the classic example of violation of this principle.

We define the class rectangle:

The Liskov Substitution Principle• Let now our system required a class of the square. As is

known, the square is a special case of the rectangle, in other words, a square is a rectangle.

The Liskov Substitution Principle• However, all sides of the square are equal, therefore, we

are forced to announce methods of setting the width and height of the virtual class rectangle and block them in the class square accordingly.

The Liskov Substitution Principle• The obvious problem seems obvious redundancy data in

the class of the square (enough to keep only one way). But suppose that we are not concerned with the problem of saving memory. Consider the following simple test.

The Liskov Substitution Principle• Note that by themselves classes of square and rectangle

are correct. • However, the above tests assumed that the width and

height of the rectangle are independent, that is, the class Square violated the invariant of the Rectangle class.

• This means that inheritance relationship also applies to the behavior of objects. From this perspective, the «square» is not «rectangle».

The Interface Segregation Principle• Clients should not depend on the interfaces that are not

needed.• Consequences of the violation:

• Complication of a code.• The occurrence of unnecessary dependencies between modules.

• The effect of the use:• Simplification of understanding of the code. • Reduction of connectedness.

The Interface Segregation Principle• As a practical demonstration of violation of this principle,

consider the following example. We consider the classes representing the two types of workers with the methods of Work and to Eat:

The Interface Segregation Principle

The Interface Segregation Principle• Note that if the specified system classes we want to add a

class robot prove that the method implementation Eat in this class will be empty:

The Interface Segregation Principle• Another drawback of the specified interface shows class

Manager which manages employee as follows.• This class uses only part of the interface IWorker.

The Interface Segregation Principle• The above examples demonstrate the violation of the

principle. • The solution is to split the interface IWorker:

The Interface Segregation Principle• Now in class Robot there is no need to create a dummy

implementation methods:

• Class Manager depends only on the part of the interface, which requires:

The Dependency Inversion Principle• Modules upper level should not depend on the lower level

modules. Both should depend upon abstractions. • Abstractions should not depend on the details. • Details should depend upon abstractions. • Abstraction is the abstract classes (interfaces)that

describe the basic nature of the system.• Consequences of the violation:

• Monolithic.Fragility.

• The effect of the use:• Increase flexibility of the system.• The reusability of the code.• Simplify testing.

The Dependency Inversion Principle• Consider a simple application that prints to console the

SQL-dump the contents of a table. The Central object of our application will object DataScripter, and the client code that uses it, will be as follows:

The Dependency Inversion Principle• Class DataScripter looks as follows:

The Dependency Inversion Principle• Class InsertDataDumper may have the following form:

The Dependency Inversion Principle• Function GetSqlDump may be a bit overloaded

knowledge and responsibilities:• knows what InsertDataDumper generates the SQL-dump-

is line;• able to create an object InsertDataDumper.

The Dependency Inversion Principle• Let us now consider the application of the principle of

dependency inversion.• For this purpose we interface IDataDumper:

The Dependency Inversion Principle• Now instead of creating an object InsertDataDumper

inside the method GetSqlDump, pass the object DataScripter the appropriate option:

The Dependency Inversion Principle• Now the code to use the object DataScripter will look as

follows:

The Dependency Inversion Principle• Application of the principle of dependency inversion

reduces connectivity, enabling us to easilychange the method of generating the dump rows with INSERT the UPSERT:

The Dependency Inversion Principle• Note that the dump data always fully retained in the string.

This approach can lead to excessive consumption of memory. Change the mechanism to record data and apply the principle of dependency inversion. For this purpose, available in the library .NET abstraction TextWriter:

The Dependency Inversion Principle• Now the code that dumps the data in the console, will be

as follows:

The Dependency Inversion Principle• To output data to a file, you can use the following code: