1 of 42

2 of 42

The team

Lazăr Mihnea

mihnea.lazar@accesa.eu

B.Eng. Automated Systems Engineering, Technical University of Cluj-Napoca

M.Eng. Medical Engineering, Technical University of Cluj-Napoca

Software Engineer, 4y experience

​

3 of 42

The team

Marieșan Bogdan

bogdan.mariesan@accesa.eu

B.Eng. Automated Systems Engineering, Technical University of Cluj-Napoca

M.Eng. Applied Informatics in Complex Systems, Technical University of Cluj-Napoca

Senior Software Engineer, 7y experience

​

​

4 of 42

Course structure

  • Course every week

​

  • Laboratory once every 2 weeks

​

  • 5 laboratory assignments, which will average to represent your grade

​

  • Course attendance will bring 2 extra points to the final grade (the total final grade can be 12, out of 10)

5 of 42

What are design patterns

  • General, reusable solutions to common recurring problems in software design

​

  • A template or recipe for solving certain problems

​

  • Have names for easier identification

6 of 42

Design patterns deal with

  • Relationships between classes or other collaborators when addressing a very common recurring problem type

​

  • Application and system design

​

  • Abstractions/Ideas on top of code

​

  • Problems that have already been solved

7 of 42

Today’s agenda

SOLID principles of good object oriented design

8 of 42

SOLID

  • Single responsibility

​

  • Open/closed

​

  • Liskov substitution

​

  • Interface segregation

​

  • Dependency inversion

Robert C. Martin

9 of 42

Robert C. Martin first proposed the SOLID principles

10 of 42

Importance of SOLID principles

  • The foundation of a well designed application

​

  • Make software designs more understandable, flexible and maintainable

​

  • Guidelines that can be applied while working on software to remove code smells

​

  • Part of an overall strategy of agile and adaptive programming

​

​

11 of 42

Principle 1: Single Principle Responsibility

A class or module should have one, and only one, reason to be changed, i.e. responsibility.

12 of 42

Single Principle Responsibility example

  • Consider a module that compiles and prints a report.
  • Imagine such a module can be changed for two reasons.
  • First, the content of the report could change.
  • Second, the format of the report could change.
  • These two things change for very different causes; one substantive, and one cosmetic.
  • The single responsibility principle says that these two aspects of the problem are really two separate responsibilities, and should therefore be in separate classes or modules. It would be a bad design to couple two things that change for different reasons at different times.

​

  • The reason it is important to keep a class focused on a single concern is that it makes the class more robust.

​

13 of 42

Separation of concern (SoC)

  • A design principle for separating a computer program into distinct sections, such that each section addresses a separate concern.

​

  • Can be general, such as intended for module.
  • Can be specific, such as the name of a class to instantiate.

​

  • A program that embodies SoC well is called a modular program.

​

  • Modularity, and hence separation of concerns, is achieved by encapsulating information inside a section of code that has a well-defined interface. Encapsulation is a means of information hiding.

14 of 42

Separation of concern (SoC)

  • Layered designs in information systems are another embodiment of separation of concerns (e.g., presentation layer, business logic layer, data access layer, persistence layer).

​

15 of 42

Separation of concern (SoC)

16 of 42

Principle 2: Open/Closed Principle

  • Software entities (classes, modules, functions, etc.) should be open for extension, but closed for modification

​

  • Such an entity can allow its behaviour to be extended without modifying its source code.

​

  • A module will be said to be open if it is still available for extension.

​

  • A module will be said to be closed if it is available for use by other modules, without modifying its underlying behavior.

17 of 42

Principle 2: Open/Closed Principle

  • ​

18 of 42

Principle 2: Open/Closed Principle

  • ​

19 of 42

Principle 3: Liskov Substitution principle

  • if S is a subtype of T, then objects of type T may be replaced with objects of type S (i.e. an object of type T may be substituted with any object of a subtype S) without altering any of the desirable properties of T (correctness, task performed, etc.). More formally, the Liskov substitution principle (LSP) is a particular definition of a subtyping relation, called (strong) behavioral subtyping;
  • Think Java method overwriting!
  • Derived classes must be usable through the base class interface, without the need for the user to know the difference;

20 of 42

Principle 3: Liskov Substitution principle

  • ​

21 of 42

Principle 4: Interface Segregation principle

  • No client should be forced to depend on methods it does not use;
  • ISP splits interfaces that are very large into smaller and more specific ones so that clients will only have to know about the methods that are of interest to them. Such shrunken interfaces are also called role interfaces;
  • Keeps a system decoupled and thus easier to refactor, change, and redeploy;
  • Example: Robert C. Martin, Xerox case;
  • The contents of an interface should be decided upon depending on the needs of the client;

22 of 42

Principle 5: Dependency Inversion principle

  • Refers to decoupling software modules.
  • The principle states:
    • High-level modules should not depend on low-level modules. Both should depend on abstractions.
    • Abstractions should not depend on details. Details should depend on abstractions.
  • When designing the interaction between a high-level module and a low-level one, the interaction should be thought of as an abstract interaction between them.

23 of 42

Principle 5: Dependency Inversion principle

  • Traditional layers pattern
    • lower-level components are designed to be consumed by higher-level components which enable increasingly complex systems to be built.
    • higher-level components depend directly upon lower-level components to achieve some task.

24 of 42

Principle 5: Dependency Inversion principle

  • Dependency inversion pattern
    • With the addition of an abstract layer, both high- and lower-level layers reduce the traditional dependencies from top to bottom.

25 of 42

Principle 5: Dependency Inversion principle

26 of 42

Principle 5: Dependency Inversion principle

27 of 42

Creational patterns

  • Factory
  • Builder
  • Prototype
  • Singleton

28 of 42

Creational patterns: Factory

  • This is an abstract base class for the concrete factory classes that will actually generate new objects.
  • This class could be a simple interface containing the signature for the factory method.
  • Generally an abstract class will be used so that other standard functionality can be included and inherited by subclasses.

29 of 42

Creational patterns: Factory

  • Solves problems like:
    • How can an object be created so that subclasses can redefine which class to instantiate?
    • How can a class defer instantiation to subclasses?
  • "Define an interface for creating an object, but let subclasses decide which class to instantiate. The Factory method lets a class defer instantiation it uses to subclasses." (Gang Of Four)

30 of 42

Creational patterns: Factory

  • ​

31 of 42

Creational patterns: Abstract Factory

  • ​

32 of 42

Creational patterns: Builder

  • The intention of the builder pattern is to find a solution to constructors with a large parameter list, leading to an exponential list of constructors.
  • Instead of using numerous constructors, the builder pattern uses another object, a builder, that receives each initialization parameter step by step and then returns the resulting constructed object at once.

33 of 42

Creational patterns: Builder

  • Advantages
    • Allows you to vary a product’s internal representation.
    • Encapsulates code for construction and representation.
    • Provides control over steps of construction process.
  • Disadvantages
    • Requires creating a separate ConcreteBuilder for each different type of Product.
    • Requires the builder classes to be mutable.

34 of 42

Creational patterns: Builder

  • ​

35 of 42

Creational patterns: Builder

  • ​

36 of 42

Creational patterns: Prototype

  • Used when the type of objects to create is determined by a prototypical instance, which is cloned to produce new objects.

​

  • Purpose:
    • avoid subclasses of an object creator in the client application, like the factory method pattern does.

​

    • avoid the inherent cost of creating a new object in the standard way (e.g., using the 'new' keyword) when it is prohibitively expensive for a given application.

​

37 of 42

Creational patterns: Prototype

  • To implement the pattern, declare an abstract base class that specifies a clone() method. Any class that needs a "polymorphic constructor" capability derives itself from the abstract base class, and implements the clone() operation.

​

  • The mitotic division of a cell — resulting in two identical cells — is an example of a prototype that plays an active role in copying itself and thus, demonstrates the Prototype pattern. When a cell splits, two cells of identical genotype result. In other words, the cell clones itself.

38 of 42

Creational patterns: Prototype

  • ​

39 of 42

Creational patterns: Singleton

  • Restricts the instantiation of a class to one object.
  • Useful when exactly one object is needed to coordinate actions across the system.

​

  • Solves problems like:
    • How can it be ensured that a class has only one instance?
    • How can the sole instance of a class be accessed easily?
    • How can a class control its instantiation?
    • How can the number of instances of a class be restricted?

​

40 of 42

Creational patterns: Singleton

41 of 42

Creational patterns: Singleton

42 of 42

Thank you for your attention!