The front part of the creation of a learning model and found that a design is more important than anything: the principle of design patterns. Design patterns for example, why this model to solve the problem this way, the other mode should it be done, and they follow behind the design is timeless principles. It can be said that the design principle is the soul of design patterns.
Object-oriented design the three basic principles:
1. For interface programming, rather than the realization of programming; 2. Priority target group of the whole, rather than type of inheritance; 3. Package change-point.
The following commonly used to start learning some of the specific design principles:
1. A single responsibility principle (SRP)
Single responsibility principle (SRP), on a category, it should be only one of the reasons for the changes caused by it. In other words, do not change the reasons for the different functions together, as the impact of different changes to the duties of irrelevant. Then put it in simple language that is, should not control the things you do not control, can manage things, and doing a great disservice to your own business is also doing a great disservice to their own people.
In software design, if a class too many responsibilities, it is equivalent to coupling with these responsibilities, and a change in duties may be weakened and the completion of this class inhibit the ability of other duties. This coupling will lead to the design of vulnerability, when the change occurs, the design will be subject to unexpected damage.
Software design really has to do what many of the content is found in those duties and responsibilities of mutual separation. If more than one type of motivation to change, then this category has a surplus on one of the duties, they should have to consider type of segregation of duties.
2. Open - closed principle (The Open-Closed Principle referred to as OCP)
Open - closed principle, or the open - closed principle is that the software entity (class, module, function, etc.) should be able to expand, but can not be amended. Without modifying means is "You can not add a new category, but do not modify the original class." From this point of view was much better to understand, in fact, here is a change isolation.
This principle, the two features: one is open for expansion; the other is for the change is closed.
We are in the design of the development of any system, can not count on the system needs to identify the beginning, will not change (to be so happy too, ha ha), which is unrealistic idea is unscientific. Since the demand that there is a certain change, then how in the face of demand changes, the design can be relatively easy to modify, not that one to the new demands, it replaced the entire process (which would allow programmers crazy has not, ha ha, you do not want you mad). What kind of design can change the face of demand can be maintained relatively stable, so that the system can be continuously since the first version introduced a new version of it? Open - closed principle is that we answer.
In program design, we should always consider the type of design as far as possible good enough, not going to amend the written, if there is new demand, we increase the number of categories to complete the new requirements, the original code can be fixed on the Fixed.
Absolute closure of the modification is not possible, no matter how the module is closed and will not, there are some changes to the closure, since can not be completely closed, designers need to design the modules for his kind of change should be closed to make choices, guess he must be the most likely changes in the types of changes, and then build to isolate those changes in the abstract.
Open - closed principle of object-oriented design core. Guided by the principle of object-oriented technology can bring great benefits generated, which is maintainable, scalable, reusable, good flexibility. Development process should only show part of the frequent changes made abstract, then, for each application are deliberately scheduled to be part of the same abstract is not a good idea, refused to abstract and immature as important as the abstract itself.
3. To rely on the principle of reverse
Rely on the reverse principle: the abstract should not be dependent on the details. Should depend on the details of the abstract; high-level should not be dependent on the ground floor, both of which should depend on the abstract. White said the interface is for programming, not for programming. Abstract is the most stable, in other words, we rely on the stability of it.
In fact, to rely on reverse can be said to be a sign of object-oriented design, and programming language which is not important, if the preparation is to consider are how to abstract the details of programming rather than programming, that is, all programs rely on the relationship between the are terminated with the abstract class or interface, that is, object-oriented design, on the contrary that is, the process of design.
4. Richter substitution principle
Richter substitution principle (LSP): sub-type must be able to replace the type of his father. It plainly is, if the use of a software entity is a parent, then must apply to sub-class, and he becomes aware of any parent objects and the distinction between sub-class objects, that is, in the software inside the parent class are replaced into his class, the program has not changed behavior.
Richter has been the replacement of the principle of inheritance is possible to take only when subclass can replace the parent category, the software is not affected parent can really be reused, while the sub-class can also be the basis in the parent add new behavior.
Richter has been the principle of substitution, to make an open - closed principle possible, it is precisely because the replacement of sub-types of the type of parent that makes the module is no need to change in the case of expansion.
5. Interface segregation principle (ISP)
Interface segregation principle (ISP): Customers should not be forced to rely on their methods used. Interface belonging to customers, it does not belong in the class hierarchy. This made it very clear that the, then popular spots that do not force customers to use their methods do not, if they are not forced to use the method used, then these customers will have to face as a result of these methods do not use the changes brought about by changes .
6. Dimitr law (LoD)
Dmitry law (Law of Demeter or abbreviated LoD) is also called the principle of least knowledge (Least Knowledge Principle or abbreviation for the LKP): If the two types of non-direct communication between each other, then the two categories should not occur is a direct correlation role. If one category to another category of the need to call a method, you can forward the call through a third party.
Dmitry is the premise of the law to emphasize at the outset of the structure in the design category, each category should be to minimize the cost of access to members.
Dmitry is the fundamental thinking of the law to emphasize that the coupling between the categories. Type coupling between the weaker, the more conducive to reuse a class in the weak-coupling is modified, would not have affected the relationship between the type of result.
7. Synthesis / aggregation principles of multiplexing (Composite / Aggregate Reuse Principle or CARP)
Synthesis / polymerization of the principle of multiplexing (Composite / Aggregate Reuse Principle or CARP): often also called the principle of synthesis of multiplexing (Composite Reuse Principle or CRP), is a new object which has been using some of the object, turning it into a new object part; new object to the appointment of these objects have been achieved functional reuse purposes. I am white is to minimize the use of synthetic / aggregation, as far as possible not to use inheritance.
Object-oriented design the three basic principles:
1. For interface programming, rather than the realization of programming; 2. Priority target group of the whole, rather than type of inheritance; 3. Package change-point.
The following commonly used to start learning some of the specific design principles:
1. A single responsibility principle (SRP)
Single responsibility principle (SRP), on a category, it should be only one of the reasons for the changes caused by it. In other words, do not change the reasons for the different functions together, as the impact of different changes to the duties of irrelevant. Then put it in simple language that is, should not control the things you do not control, can manage things, and doing a great disservice to your own business is also doing a great disservice to their own people.
In software design, if a class too many responsibilities, it is equivalent to coupling with these responsibilities, and a change in duties may be weakened and the completion of this class inhibit the ability of other duties. This coupling will lead to the design of vulnerability, when the change occurs, the design will be subject to unexpected damage.
Software design really has to do what many of the content is found in those duties and responsibilities of mutual separation. If more than one type of motivation to change, then this category has a surplus on one of the duties, they should have to consider type of segregation of duties.
2. Open - closed principle (The Open-Closed Principle referred to as OCP)
Open - closed principle, or the open - closed principle is that the software entity (class, module, function, etc.) should be able to expand, but can not be amended. Without modifying means is "You can not add a new category, but do not modify the original class." From this point of view was much better to understand, in fact, here is a change isolation.
This principle, the two features: one is open for expansion; the other is for the change is closed.
We are in the design of the development of any system, can not count on the system needs to identify the beginning, will not change (to be so happy too, ha ha), which is unrealistic idea is unscientific. Since the demand that there is a certain change, then how in the face of demand changes, the design can be relatively easy to modify, not that one to the new demands, it replaced the entire process (which would allow programmers crazy has not, ha ha, you do not want you mad). What kind of design can change the face of demand can be maintained relatively stable, so that the system can be continuously since the first version introduced a new version of it? Open - closed principle is that we answer.
In program design, we should always consider the type of design as far as possible good enough, not going to amend the written, if there is new demand, we increase the number of categories to complete the new requirements, the original code can be fixed on the Fixed.
Absolute closure of the modification is not possible, no matter how the module is closed and will not, there are some changes to the closure, since can not be completely closed, designers need to design the modules for his kind of change should be closed to make choices, guess he must be the most likely changes in the types of changes, and then build to isolate those changes in the abstract.
Open - closed principle of object-oriented design core. Guided by the principle of object-oriented technology can bring great benefits generated, which is maintainable, scalable, reusable, good flexibility. Development process should only show part of the frequent changes made abstract, then, for each application are deliberately scheduled to be part of the same abstract is not a good idea, refused to abstract and immature as important as the abstract itself.
3. To rely on the principle of reverse
Rely on the reverse principle: the abstract should not be dependent on the details. Should depend on the details of the abstract; high-level should not be dependent on the ground floor, both of which should depend on the abstract. White said the interface is for programming, not for programming. Abstract is the most stable, in other words, we rely on the stability of it.
In fact, to rely on reverse can be said to be a sign of object-oriented design, and programming language which is not important, if the preparation is to consider are how to abstract the details of programming rather than programming, that is, all programs rely on the relationship between the are terminated with the abstract class or interface, that is, object-oriented design, on the contrary that is, the process of design.
4. Richter substitution principle
Richter substitution principle (LSP): sub-type must be able to replace the type of his father. It plainly is, if the use of a software entity is a parent, then must apply to sub-class, and he becomes aware of any parent objects and the distinction between sub-class objects, that is, in the software inside the parent class are replaced into his class, the program has not changed behavior.
Richter has been the replacement of the principle of inheritance is possible to take only when subclass can replace the parent category, the software is not affected parent can really be reused, while the sub-class can also be the basis in the parent add new behavior.
Richter has been the principle of substitution, to make an open - closed principle possible, it is precisely because the replacement of sub-types of the type of parent that makes the module is no need to change in the case of expansion.
5. Interface segregation principle (ISP)
Interface segregation principle (ISP): Customers should not be forced to rely on their methods used. Interface belonging to customers, it does not belong in the class hierarchy. This made it very clear that the, then popular spots that do not force customers to use their methods do not, if they are not forced to use the method used, then these customers will have to face as a result of these methods do not use the changes brought about by changes .
6. Dimitr law (LoD)
Dmitry law (Law of Demeter or abbreviated LoD) is also called the principle of least knowledge (Least Knowledge Principle or abbreviation for the LKP): If the two types of non-direct communication between each other, then the two categories should not occur is a direct correlation role. If one category to another category of the need to call a method, you can forward the call through a third party.
Dmitry is the premise of the law to emphasize at the outset of the structure in the design category, each category should be to minimize the cost of access to members.
Dmitry is the fundamental thinking of the law to emphasize that the coupling between the categories. Type coupling between the weaker, the more conducive to reuse a class in the weak-coupling is modified, would not have affected the relationship between the type of result.
7. Synthesis / aggregation principles of multiplexing (Composite / Aggregate Reuse Principle or CARP)
Synthesis / polymerization of the principle of multiplexing (Composite / Aggregate Reuse Principle or CARP): often also called the principle of synthesis of multiplexing (Composite Reuse Principle or CRP), is a new object which has been using some of the object, turning it into a new object part; new object to the appointment of these objects have been achieved functional reuse purposes. I am white is to minimize the use of synthetic / aggregation, as far as possible not to use inheritance.