C # Object-oriented Basic principles _c# Tutorials

C # Object-oriented principles
One, interface-oriented rather than implementation [Code to a interface rather than to a implementation.]

Second, the use of a combination of priority rather than inheritance [favor composition over inheritance.]

Third, srp:the single responsibility principle sole responsibility
Each object in the system should have only one separate responsibility, and all objects are concerned with the completion of their own duties. [Every object in your system should have a single responsibility, and all the object s services should is focused on carry ing out of that single responsibility.]
Each responsibility is a design change, when demand changes, changes in demand are reflected in changes in the category of responsibilities. When the objects in your system have only one reason to change, you have followed the SRP principle very well. If a class takes on too much responsibility, it is tantamount to coupling these responsibilities together. A change in one's responsibilities may weaken or inhibit the ability of other responsibilities in this category. This design can lead to fragile design. When the change happens, the design will be destroyed unexpectedly. The SRP makes it easier for the system to manage maintenance because not all the problems are mixed up.
Cohesion [cohesion[is actually another name for the SRP principle. You wrote the high cohesion software, which means you've applied the SRP principle very well.

Iv. Dry:don ' t Repeat yourself principle avoid code duplication principle
Avoid code duplication by extracting the public parts in one place. [Avoid duplicate code by abstracting out things this are common and placing those in a single thing.]
DRY is simple, but it is the key to ensuring that our code is easy to maintain and reuse. You try to avoid duplicate code is actually making sure that every requirement and function is implemented only once in your system, otherwise there is a waste! System use cases do not have intersection, so our code should not be repeated, from this point of view dry can not just say the code.
DRY is concerned that information and behavior within the system are placed in a single, visible position. As you can guess, the regular expression is positioned in. NET, because it's reasonable to guess.
DRY principle: How to split the system function well! The clear boundaries of responsibility ensure the uniqueness of the code to some extent.

Five, Ocp:open-close principle open closure principle
The class should be closed to the modification and open to the extension; [Classes should is open for extension, and closed for modification.]
OCP is concerned with flexibility, and changes are made by adding code, rather than by altering existing code;
The application of OCP is limited to changes that may occur, isolating the same kind of changes that may occur later, by creating abstractions
The OCP principle conveys the idea that once you have written out the code that works, try to make sure that the code is working all the time. This can be said to be a bottom line. A little bit more requirements, once our code quality to a level, we have to do our best to ensure that the quality of the code is not back. Such requirements make it a problem not to use a patchwork approach to solve a problem, or a laissez-faire way to solve an issue; for example, the code added countless processing of specific data, more and more specialized code, the code intention began to be ambiguous, began to degenerate.
The mechanism behind OCP: encapsulation and abstraction; closure is based on abstraction, using abstraction to get the display of closure; Inheritance is the simplest example of OCP. In addition to subclasses and method overloading we also have some more elegant ways to implement such as composition, and how do you change the behavior without changing the source code (turning off the modification)? The answer is abstract, and the mechanism behind the OCP is abstract and polymorphic. There is no suitable model to adapt to all situations! There is bound to be a change, and it cannot be completely closed. It is not a good idea to have a wanton abstraction of every part of the program, and the right thing to do is to abstract the frequently changing parts of the developer. Rejecting immature abstractions is as important as abstraction itself. OCP is at the heart of many of Ood's assertions, and if this principle is applied effectively, we can be more maintainable, reusable, flexible, and robust LSP is one of the main principles that OCP becomes possible.

Vi. lsp:the Liskov substitution principle on the Richter replacement principle
Subclasses must be able to replace the base class. [subtypes must is substitutable for their base types.]
LSP is concerned with the good use of inheritance. It is important to know whether to use a method or to extend it, but it is definitely not changing it.
LSP clearly pointed out that the ood of the is-a relationship is in terms of behavior, behavior can be reasonable assumptions, is dependent on the client program.
LSP allows us to draw an important conclusion: a model, if viewed in isolation, does not have a true sense of validity. The effectiveness of the model can only be performed through its client program. It must be examined according to reasonable assumptions made by the user of the design. Assumptions are unpredictable, and they are not processed until the design stink comes up.
The breach of LSP also potentially violates the OCP.

DIP: The principle of dependency inversion
High-level modules should not be dependent on the underlying modules, both of which should be dependent on abstraction, and abstractions should not depend on details that should depend on abstraction.
What is a high-level module? The high-level module includes important policy choices and business models in the application. These high-level modules differentiate their applications from the others. If the high-level module relies on the underlying module, it becomes very difficult to reuse the high-level modules in different contexts. However, if the high-level module is independent of the underlying 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 dependency but also the inversion of interface ownership. Applying a dip we will find that customers often have abstract interfaces, and that the server derives from these abstract interfaces. This is the famous Hollywood principle: "Don t call us we'll call you." The underlying module implements an interface that is declared at a high-level module and invoked by a high-level module. By inverting, we create a more flexible structure that is more durable and easier to change.
The simple heuristic rule of dip: dependency on abstraction; This is a simple statement, which suggests that the rules should not rely on specific classes, which means that all dependencies of a program rollup should be planted in an abstract class or interface. If a class is stable, then relying on it does not cause harm. However, most of our own concrete classes are unstable and can be isolated by hiding them behind an abstract interface. Dependency inversion can be applied to any place where one class sends a message to another, and the dependency inversion principle is the basic underlying mechanism that implements many of the claims of object-oriented technology, and is the object-oriented symbol.

Viii. ISP: Interface Isolation principle
Client programs should not be forced to rely on methods that they do not need to use.
Interface is not high cohesion, an interface can be divided into n groups of methods, then this interface needs to use the ISP to deal with.
The division of an interface is determined by the client program that uses it, and the client program is a separate interface that should also be detached.
When there are too many behaviors in an interface, resulting in an abnormal dependency between their client programs, what we need to do is detach the interface and implement decoupling.
After the ISP is applied, the client program sees multiple cohesive interfaces.