The open closed principle

  • A software entity such as classes, modules, and functions should be open to modification, that is, to extend its functionality without modifying a software entity

Interpretation of the

  • Build the framework with abstractions and extend the details with implementations.
  • New requirements should not be implemented by modifying existing classes, but rather by implementing preabstracted interfaces (or concrete classes inheriting abstract classes).

advantages

  • The advantage of practicing the open close principle is that you can extend functionality without changing the original code. The expansibility of the program is increased, and the maintenance cost of the program is reduced.

analogy

  • Motor vehicles:

    • Four wheels
    • A steering wheel
    • The top

  • Due to the constant changes in modern life, there are many different types of cars, such as engineering cars, ambulances, racing cars.

  • Design that does not follow the open and close principle

@interface Car : NSObject @property(nonatomic,copy)NSString *steeringWheel; @property(nonatomic,copy)NSString *tyre; // @property(nonatomic,copy)NSString *cover; @property(nonatomic,copy)NSString *carriage; @property(nonatomic,copy)NSString *tail; @property(nonatomic,copy)NSString *medical; // Medical device@endCopy the code
  • The car class declares the basic properties of the original car
    • The wheel
    • The steering wheel
    • The top
  • We added new attributes to the original vehicle class as required
    • The big car
    • Medical apparatus and instruments
    • The car tail
  • As a result, when we create an instantiation of a racing class, we will include member attributes that we don’t need. We can’t zoom in on cars and medical equipment on a racing car. Although we may not use these member attributes.
  • Obviously such a design is not a very good design
    • As the requirements increased, the previously created class, CAR, needed to be modified repeatedly
    • It also creates unnecessary redundancy for new classes
  • This is a failure to adhere to the modified closed, on – off extension development principle

Design that follows the principle of open and close

  • Base class for the car
@interface Car : NSObject @property(nonatomic,copy)NSString *steeringWheel; @property(nonatomic,copy)NSString *tyre; // @property(nonatomic,copy)NSString *cover; @ the end / / top coverCopy the code
  • The truck class
@interface Truck : Car @property(nonatomic,copy)NSString *carriage; / / @ end compartmentCopy the code
  • The ambulance class
@interface Ambulance : Car @property(nonatomic,copy)NSString *medical; // Medical device@endCopy the code
  • The car class
@interface Race : Car @property(nonatomic,copy)NSString *tail; / / tail @ the endCopy the code

advantages

  • 1. As the Car type increases, there is no need to repeatedly modify the original parent class (Car), just create a new subclass that inherits from it and add its own attributes and methods to the subclass
  • 2. The functions of each vehicle type are divided into different subclasses, and there is no redundancy in the attributes of each subclass
  • 3. When we added methods to the truck class, it didn’t affect ambulances and racers.

UML class diagram comparison

  • Not following the open and close principle

  • Observe the open and close principle

# # practice

  • Before we develop the project, we need to be clear about what data is constant in this scenario and what things are subject to change. It will be easy to abstract car interfaces or methods to better apply different requirements in the future