This is the third day of my participation in the More text Challenge. For details, see more text Challenge

Single Responsibility Principle

  1. Definition: For a class, there should be only one cause for its changes;

Open Close Principle

  1. Definition: Objects (classes, modules, functions, etc.) in software should be open for extension, but closed for modification;
  2. Application: When software needs to change, it should be done in an extended way, rather than by modifying existing code.

Liskov Substitution Principle

  1. Definition: All references to a base class must transparently use the objects of its subclasses;
  2. Description: The three major characteristics of object-oriented languages are inheritance, encapsulation, and polymorphism. The Richter substitution principle relies on inheritance and polymorphism. Through substitution principle on the Richter scale is simple to say, all the references to base classes must be able to use objects of derived classes without knowing its transparency, popular point: as long as the presence of a parent class can subclass can occur, and replaced with the tap also won’t produce any mistakes or yichang, the user may simply don’t need to know is the parent class or subclass. But not the other way around, there is a subclass appears where the parent class may not be able to adapt;
  3. Principle: abstract;
  4. Advantages and disadvantages of inheritance:
    • Advantages:
      1. Code reuse, reduce the cost of creating classes, each subclass has the methods and properties of the parent class;
      2. The subclass is similar to the parent class, but it is different from the parent class.
      3. Improve code extensibility;
    • Disadvantages:
      1. Inheritance is intrusive, as long as the integration must have all properties and methods of the parent class;
      2. It may cause code redundancy in subclasses and reduce flexibility because subclasses must have properties and methods of the parent class.

Dependence Inversion Principle

  1. Definition: Dependencies between modules occur through abstractions; dependencies between implementation classes do not occur directly; dependencies are generated through interfaces or abstract classesInterface oriented programming, or abstract oriented programming, where abstract classes refer to interfaces or abstract classes.;
  2. Key points:
    • High-level modules should not depend on low-level modules, both should depend on their abstractions;
    • Abstractions should not depend on details;
    • Details should rely on abstractions;
  3. Description: In the Java language, abstraction refers to an interface or abstract class, neither of which can be instantiated directly. The detail is the implementation class, the class that implements the interface or inherits the abstract class is the detail, and the characteristic is that it can be instantiated directly, that is, it can add the keyword new to produce an object. The high-level module is the calling end, and the low-level module is the concrete implementation class.

InterfaceSegregation Principles

  1. Definition:
    • A client should not rely on interfaces it does not need;
    • Dependencies between classes should be built on minimal interfaces;

Law of Demeter [LOD]

  1. Definition: An object should have minimal understanding of other objects;
  2. Description: A class should know as little as possible about the classes it needs to couple or call. The inner workings of the class are irrelevant to the caller or dependency. The caller or dependency needs to know only the methods it needs and nothing else.