Basic principles of c sharp object orientation
- 2020-05-05 11:50:03
- OfStack
Basic principles of object orientation C#
I. interface oriented programming rather than implementation [Code to an interface than to an implementation]
2. Prioritize composition over inheritance
SRP: The single responsibility principle single responsibility
Each object in the system should have a single responsibility, and all objects should focus on the completion of their own responsibilities. [Every object in your system have a responsibility,and all s s Each responsibility is a design variable, and when requirements change, the change in requirements is reflected as a change in class responsibilities. When all the objects in your system have only one reason to change, you have followed the SRP principle very well. If a class has too many responsibilities, it is coupling them together. A change in one responsibility may impair or inhibit the ability of other responsibilities of that class. This design can lead to fragile designs. When change occurs, the design can suffer unexpected damage. SRP makes the system easier to manage and maintain because not all problems are mixed up.
Cohesion [Cohesion] is actually another name for the SRP principle
DRY: Don't repeat yourself Principle avoid code duplication principle
Avoid code duplication by extracting common parts and placing them in one place DRY is simple, but key to ensuring that our code is easy to maintain and reuse. By trying to avoid duplication of code, you are actually ensuring that every requirement and function is implemented only once in your system, otherwise there is waste! There is no intersection of system use cases, so our code should not be duplicated. From this point of view, DRY is not just talking about code.
DRY focuses on information and behavior within the system in a single, obvious place. Just as you can guess the position of the regular expression in.net, you can guess it because it makes sense.
DRY principle: how to segment system functions well! A clear line of responsibility guarantees some degree of code simplicity.
OCP: Open-Close Principle principle of open and closed
Classes should be closed for modifications and open for extensions. [Classes should open for extension,and closed for modification.]
OCP is about flexibility. Changes are made by adding code, not by changing existing code.
The application of OCP is limited to changes that may occur, and similar changes that may occur later
are isolated by creating abstractions The OCP principle conveys the idea that once you write code that works, try to keep it working. That's kind of the bottom line. Raise the bar a little bit, and once we get to a level of code quality, we do our best to keep the code quality going. This requirement prevents us from solving a problem in a haphazard way, or in a laissez-faire way; For example, code adds an infinite amount of processing to specific data, more and more specialized code, and the code's intentions start to be ambiguous and degenerate.
The mechanism behind OCP: encapsulation and abstraction; Closure is built on the basis of abstraction, using the abstraction to obtain the closure of the display; Inheritance is the simplest example of OCP. In addition to subclassing and method overloading we have more elegant ways of doing it like composition; How do you change its behavior without changing the source code? The answer is abstraction, and the mechanism behind OCP is abstraction and polymorphism. There are bound to be changes, and it's impossible to be completely closed off. It's not a good idea to abstract away every part of a program; the right thing to do is for developers to abstract only the parts that change frequently. The rejection of premature abstractions is as important as the abstraction itself. OCP is at the heart of many of OOD's claims, and if this principle is applied effectively, we can achieve greater maintainability, reusability, flexibility and robustness. LSP is one of the main principles that made OCP possible.
6. LSP: The Liskov substitution principle
Subclasses must be able to replace base classes. [Subtypes must be substitutable for their base types.]
LSP is concerned with how to use inheritance well. It must be clear whether to use an Method or to extend it, but definitely not to change it.
LSP clearly points out that the IS-A relationship of OOD is in terms of the behavior mode, which can be reasonably assumed and is dependent on by the client program.
LSP leads us to an important conclusion: a model, if viewed in isolation, is not truly valid. The validity of the model can only be expressed by its clients. It must be viewed against the reasonable assumptions made by the users of the design. Assumptions are hard to predict, and you don't deal with them until the design smells show up.
The violation of LSP is also a potential violation of OCP.
7. DIP: dependency inversion principle
Higher level modules should not depend on lower level modules both should depend on abstractions, abstractions should not depend on details details should depend on abstractions.
What is a high-level module? The high-level modules contain important policy choices and business models in the application. These high-level modules differentiate the applications they reside in from the others. If high-level modules depend on low-level modules, it becomes difficult to reuse high-level modules in different contexts. However, if the high-level module is independent of the low-level module, then the high-level module can be easily reused. This principle is the core principle of framework design. The inversion here is not only the inversion of dependencies but also the inversion of interface ownership. With DIP we find that it is often the customer who has abstract interfaces from which the server derives. This is known as the Hollywood principle :"Don't call us us we call you. By inverting we create a structure that is more flexible, more durable, and easier to change.
DIP's simple heuristic rules: rely on abstractions; This is a simple statement, and the rule suggests that you should not rely on concrete classes, that is, your program should aggregate all its dependencies on abstract classes or interfaces. If a class is stable, relying on it won't hurt. However, most of our own concrete classes are unstable and can be isolated by hiding them behind abstract interfaces. Dependency inversion can be applied to any place where there is a message from one class to another, and the dependency inversion principle is the basic underlying mechanism for realizing the many benefits claimed by many object-oriented technologies, and the hallmark of object orientation.
ISP: interface isolation principle
Clients should not be forced to rely on methods they do not need to use.
Interfaces are not highly cohesive, and an interface that can be divided into N groups of methods needs to be handled using ISP.
The partitioning of the interface is determined by the client that USES it, and the interface that the client is separating from should be.
When there are too many behaviors in an interface, resulting in abnormal dependencies between their clients, what we need to do is to separate the interfaces and achieve decoupling.
After applying ISP, the client sees multiple cohesive interfaces.
I. interface oriented programming rather than implementation [Code to an interface than to an implementation]
2. Prioritize composition over inheritance
SRP: The single responsibility principle single responsibility
Each object in the system should have a single responsibility, and all objects should focus on the completion of their own responsibilities. [Every object in your system have a responsibility,and all s s Each responsibility is a design variable, and when requirements change, the change in requirements is reflected as a change in class responsibilities. When all the objects in your system have only one reason to change, you have followed the SRP principle very well. If a class has too many responsibilities, it is coupling them together. A change in one responsibility may impair or inhibit the ability of other responsibilities of that class. This design can lead to fragile designs. When change occurs, the design can suffer unexpected damage. SRP makes the system easier to manage and maintain because not all problems are mixed up.
Cohesion [Cohesion] is actually another name for the SRP principle
DRY: Don't repeat yourself Principle avoid code duplication principle
Avoid code duplication by extracting common parts and placing them in one place DRY is simple, but key to ensuring that our code is easy to maintain and reuse. By trying to avoid duplication of code, you are actually ensuring that every requirement and function is implemented only once in your system, otherwise there is waste! There is no intersection of system use cases, so our code should not be duplicated. From this point of view, DRY is not just talking about code.
DRY focuses on information and behavior within the system in a single, obvious place. Just as you can guess the position of the regular expression in.net, you can guess it because it makes sense.
DRY principle: how to segment system functions well! A clear line of responsibility guarantees some degree of code simplicity.
OCP: Open-Close Principle principle of open and closed
Classes should be closed for modifications and open for extensions. [Classes should open for extension,and closed for modification.]
OCP is about flexibility. Changes are made by adding code, not by changing existing code.
The application of OCP is limited to changes that may occur, and similar changes that may occur later
are isolated by creating abstractions The OCP principle conveys the idea that once you write code that works, try to keep it working. That's kind of the bottom line. Raise the bar a little bit, and once we get to a level of code quality, we do our best to keep the code quality going. This requirement prevents us from solving a problem in a haphazard way, or in a laissez-faire way; For example, code adds an infinite amount of processing to specific data, more and more specialized code, and the code's intentions start to be ambiguous and degenerate.
The mechanism behind OCP: encapsulation and abstraction; Closure is built on the basis of abstraction, using the abstraction to obtain the closure of the display; Inheritance is the simplest example of OCP. In addition to subclassing and method overloading we have more elegant ways of doing it like composition; How do you change its behavior without changing the source code? The answer is abstraction, and the mechanism behind OCP is abstraction and polymorphism. There are bound to be changes, and it's impossible to be completely closed off. It's not a good idea to abstract away every part of a program; the right thing to do is for developers to abstract only the parts that change frequently. The rejection of premature abstractions is as important as the abstraction itself. OCP is at the heart of many of OOD's claims, and if this principle is applied effectively, we can achieve greater maintainability, reusability, flexibility and robustness. LSP is one of the main principles that made OCP possible.
6. LSP: The Liskov substitution principle
Subclasses must be able to replace base classes. [Subtypes must be substitutable for their base types.]
LSP is concerned with how to use inheritance well. It must be clear whether to use an Method or to extend it, but definitely not to change it.
LSP clearly points out that the IS-A relationship of OOD is in terms of the behavior mode, which can be reasonably assumed and is dependent on by the client program.
LSP leads us to an important conclusion: a model, if viewed in isolation, is not truly valid. The validity of the model can only be expressed by its clients. It must be viewed against the reasonable assumptions made by the users of the design. Assumptions are hard to predict, and you don't deal with them until the design smells show up.
The violation of LSP is also a potential violation of OCP.
7. DIP: dependency inversion principle
Higher level modules should not depend on lower level modules both should depend on abstractions, abstractions should not depend on details details should depend on abstractions.
What is a high-level module? The high-level modules contain important policy choices and business models in the application. These high-level modules differentiate the applications they reside in from the others. If high-level modules depend on low-level modules, it becomes difficult to reuse high-level modules in different contexts. However, if the high-level module is independent of the low-level module, then the high-level module can be easily reused. This principle is the core principle of framework design. The inversion here is not only the inversion of dependencies but also the inversion of interface ownership. With DIP we find that it is often the customer who has abstract interfaces from which the server derives. This is known as the Hollywood principle :"Don't call us us we call you. By inverting we create a structure that is more flexible, more durable, and easier to change.
DIP's simple heuristic rules: rely on abstractions; This is a simple statement, and the rule suggests that you should not rely on concrete classes, that is, your program should aggregate all its dependencies on abstract classes or interfaces. If a class is stable, relying on it won't hurt. However, most of our own concrete classes are unstable and can be isolated by hiding them behind abstract interfaces. Dependency inversion can be applied to any place where there is a message from one class to another, and the dependency inversion principle is the basic underlying mechanism for realizing the many benefits claimed by many object-oriented technologies, and the hallmark of object orientation.
ISP: interface isolation principle
Clients should not be forced to rely on methods they do not need to use.
Interfaces are not highly cohesive, and an interface that can be divided into N groups of methods needs to be handled using ISP.
The partitioning of the interface is determined by the client that USES it, and the interface that the client is separating from should be.
When there are too many behaviors in an interface, resulting in abnormal dependencies between their clients, what we need to do is to separate the interfaces and achieve decoupling.
After applying ISP, the client sees multiple cohesive interfaces.