- Single Responsibility Principle (SRP) - On a category, it should only be one causes of change
- Opening - closing principle (the OCP) - software entities (classes, modules, functions, etc.) should be extended, but can not be modified
- Alternatively Richter principle (LSP) - must be able to replace them subclasses base type
- Dependency Inversion Principle (DIP) - abstract should not depend on the details. Details should depend on the abstract.
- Interface Segregation Principle (ISP) - customers should not be forced to rely on the method of their unused. Interfaces belonging to the customer, it does not belong in the class hierarchy.
- Reuse-order principle release, etc. (REP) - reuse granularity is released granularity.
- Common Closure Principle (CCP) - All classes in a package of changes for the same type of property should be common closed. If a change is generated on the impact of a package, it will have an impact on all the classes in a package, but does not affect other packages.
- Reuse common principles (CRP) - a package of all classes should be common reusable. If you reuse a class package, then it would reuse all classes in the package.
- Acyclic Dependencies Principle (ADP) - present in the ring does not allow the package dependency graph.
- Principle dependent stability (SDP) - toward a stable direction dependency.
- Stable abstract principle (SAP) - level of abstraction and its package should be consistent with the degree of stability.
- Synthetic / polymeric multiplexing principles (CARP) - To make full use of synthetic / polymeric, try not to use inheritance
- …..
Awareness - principles of conduct
Adhere to the principle of innovation
First talk about the design template, template I believe is a very good thing for every developer and designers, because it can be "quickly" build "mature" code, structure, or UI. "Ism" boom ever in the industry, in terms of a template for architects also have this effect, in the design process, we often encounter a lot must not important "tasteless" module, without which the system will become incomplete, and their presence does not add any "features" for the system, such as: user management, role management or system settings. Common practice is to direct the use of existing third-party modules or from other projects with similar multiplexing module, you are such a right? At least I always do this, because our projects are usually Chinese-style "acceptance driven" through acceptance, mature enough available. If the entire project is just a template of various types of modules, then the project did not really need an architect, because there is no design, all the work should be a "fusion" (Fusion). May be a lot of people would say Tucao say this is a "resource integration" capability, from a "rush project" point of view that no non-tasty, but said the technical content and design components of any nature does not exist, this type of assembly or "copy" of the project requires the project manager with only a few senior programmer will be able to complete.
I was in the " expression control thinking and methodology referred to" a paper methods of communication and marketing, among them a: "Name at least three of the characteristics of the system," This statement has implications for markets outside sales, in fact, is for architects play an important role also in establishing remind one design principles:
Assembled architecture template design is inevitable, it is important to be added yours design features
It was hard to remember the entire software designer, and very easy to remember the great features of a particular designer. "Characteristics" is an important mark in the software architect left, also in where the team with the architect of significance. Design a fully templated reuse design is a skill, and date of this design is the emergence of an enterprise when architects leave within small and medium enterprises, and perhaps this is the moment of the Chinese architect War. Maintain the characteristics to keep their jobs, you know.
Stick to the principle of nature
The only constant is change itself - Jerry Marktos "Mythical Man-Month"
Just the same desire to change is eternal - Swift
- The user needs to change - they need to add more features, more demanding quality user experience.
- Code changing - constantly refactoring, testing, continuous integration, so that the code reads the contents become stable.
- The boss's idea to change - because the market demand is changing, the need to add more features to the software to meet the market.
- Architecture is changing - the use of newer technology system, to obtain more efficient productivity, more stable, secure operating environment.
Change is like a table, unstable and customizable; nature is a core, must be stable, scalable, and can not be modified; changes can be fixed into the core.
"Merchant Code" principle
Never invest in the future, not the design function does not return
I do not know whether you have a similar experience:
- Communication with clients, your boss and managers are constantly depicted the "future" picture of customers, but in a lot of features which contains almost no customers need?
- When you design the overall architecture, there is an impulse to make you want to be an inspiration triggered by the function or module for the "future" of the need to expand the system useful to join it?
- In your code there are a number of methods or classes can be deleted, but you think they can be used for "future" expansion and "men leave code" of it?
- Do you have a manager or a project leader for whether the increase is likely to be featured and debated it you realize it is a function?
Measure ruler in the hands of architects, if there are numerous of these "future functionality" appears in the design, how would you treat it? Is a direct cut or wrapped as "features" mean? At this time, the architect not only require a technician's point of view as to consider this feature is available in the future, but more of a need to consider the "cost." Each function or even every line of code is required to pay the "man - months' costs, once the costs out of control, the software will be the embodiment of" crying wolf "swallow your project, and finally can only regret not having found a" silver bullet. " Each "future" how to function not bring immediate returns of the existing project, you must cut off! Even if this function how wonderful, profound or extraordinary significance in the future, or put it in "laboratory" has become the technical reserves other projects now. Businessman standing position: every penny of the cost of inputs, we need to have enough interest returns .
The future is always good, but also full of clouds, but the reality is often full of skinny. Overdraft in the architecture or code in a handful of future returns available, because these "investments" are just some of the unpredictability of attempts, in addition to the product "marketing strategy" requires too much out of this type of investment you have to have caught "Maintenance future" psychological consciousness. New features, future characteristics should be collected, as it releases an option, through detailed market research to reconsider added to the product. Of course, for the principle of large software companies are basically superfluous, because many mature software companies control the demand and extremely strict specifications. But if your business where there are no such management awareness, or an aloofness of design freedom, then this principle is very important, we are people who use the code to change money, less code to change more money is our the most basic survival needs.
Reconstruction of the principle of priority
In the absence of the code should be reconstruction, reconstruction method is to write elegant code rather than simply modify the code theory.
Camels and tents story
Filled with sand in the desert, camels in looking for a warm home. Later it finally found a tent, but the tent is someone else (maybe your situation is saying the same)!
Initially, camel begging that the owner, I feel dead, let me put your head to ease warm it! Poor master it, agreed. After a while, the camel said, the owner, my shoulder froze numb, let me come a little bit! Poor master it, he agreed. Then, camel constantly requested, trying to put the whole body.
Owner of a little hesitation, on the one hand, he was afraid of coarse camel's nostrils; on the other hand, outside of the sand so much, he seems to need such a partner, and he co-resist cold and dangerous. So he turned to go back somewhat reluctantly, to camel free up more seats. Camels and wait until the full spirit can take control of the tent when it is said impatiently, the owner, the tent is so small that even I turned very difficult, you gave me out of here
This is a very moral of the story, if it is a metaphor for the development process is also very interesting. For the "smelly" or even "rotten" the code we will immediately say, "reconstruction", but if you can reconstruct solve all the problems? Have you tried to reconstruct failure? Reconstruction under what circumstances it is not available? If these problems in your heart there is no accurate answer, I suggest once again to read "Refactoring" book. I believe that the reconstruction is not simply a method of development and review of the code used, but an ideological guide the design and coding! In the design phase should apply the principles of reconstruction, whether it can "preservative" mean? The answer is clearly determined. Reconstruction is often not simply the code, but the idea of developers, designers, non-execution or no code specifications, any name, free copy / paste, free call these must be eliminated. I do not mean in the design of the reconstruction does not need reconstruction, but the significance of doing so can significantly reduce the cost of the discovery of "stinking" Reconstruction of code away.
This can also be said that the principle of the development of a team, at the beginning of the project have to have a unified coding standard (direct use of official specifications), the base code reconstruction method and remodeling also included in the specification, in the development process enforce norms, codes for any possible "corrupt" absolute "zero" tolerance, the pain is only temporary, but the benefit is long-term.
Code design principles
Open - Closed Principle
Open Closed Principle, also known as open - closed principle Open-Closed Principle (OCP)
Software entities (such as classes, modules, functions, etc.) should be extended, but it can not be modified.
OCP is a very well-known design principles of a simple sentence can be summed up when the "open" to when the "closed." This sentence seems very simple, a look will feel that they seem to comprehend what chew felt within the meaning unlimited, how in the end it should be understood these words and apply it to design it? I refer to a lot of domestic data summarized this principle, the feeling is smoke and mirrors, no way to find the most appropriate explanation.
I would like to explain several aspects of this principle:
From the perspective of design class
Open Application class designed - closing principle is a principle of control of the class "polymorphism." Opening and closing the principles in the design of the base class or superclass by important, it can simply geography for the members of the object's scope and members can "reload" Control Guidelines principles. Press "Richter replace the principle of" base class members are usually for subclass should be seen, that is the smallest scope scope base class members should protect, if the emergence of a large number of private members should consider private members separated into other categories, these members do not apply because its progeny violated "substitution principle", and more suitable "principles synthetic / polymeric."
When using the virtual keyword to be very heavy consideration, except for some special design patterns such as "decorative" virtual mode requires a lot of outside support, in the absence of the necessary circumstances to avoid. Rewritable defined subclass members reserved the room "behavioral change", but also as a subclass of violation "substitution principle" laid mines. When a large number of subclasses override member appears in the time you have to consider whether the sub-class also should inherit to such family, because a large number of subclasses in violation of "substitution principle" means that it meets the separated family class condition. Similarly, in C #, but need to achieve a base class inside a subclass needs to taken into account when the same interface.
Note: Substitution Principle Leeb is open - an important complement Closed Principle, usually use in class design.
From the perspective of a modular design
Module Design "opening - closing principle" is focused on the control of the interface. And this is particularly important in the overall architecture, as between modules "open - closed" is a direct impact on the system level coupling. Opening and closing need to "weigh the cost" between modules, not all the details are open to using modules is highly scalable will have a high degree of reuse. First look at to understand that:
Openness and maintenance costs proportional
Open interfaces must with instructions for use, this will increase the cost of a team of communication open while a change in the interface but will likely bring additional "descriptive reconstruction" cost. In some cases it is easy to be "highly scalable" the lure will expose a lot of "likely" to be multiplexed by extending the interface. When the temptation of this highly scalable leading designer of thinking, along with an increase in the module becomes large projects, will enter slowly designer created his own "Notes nightmare" in.
Openness and proportional to the degree of coupling
Interface modules having open conductive coupling effect, the coupling between the control modules can be controlled to a large extent the coupling degree. Dependencies among the modules, the lower the degree of coupling is more easily possible to change the degree of coupling concentrated in one of the two modules (eg: Facade mode), rather than scattered among modules. High coupling module has naturally become the "core" modules, but in fact the "external" modules will need to maintain their closure, this design is easily adapted to many changes in the unknown.
This positive relationship between the two combine to achieve cost control on us to make two of the most simple and practical reasoning:
Corollary 1: "Please remain closed under normal circumstances, the absence of necessary not open."
Corollary 2: "focus on openness, so keep the strange inter-module"
Open - Closed Principle talk there will be a lot of content in theory, but the implementation is very simple, it focuses on C # The easiest way to control the control module is an open scope: internal, public.
3. Design from the function / method angle
I used to think OCP extreme case is applied to the method level, is well known: the fewer the better use of parametric methods. Opening - closing principle can be simply understood as a control parameter value will return to the amount of
Here I want to talk about - "Opening the Closed Principle" in C # is. First methodological design, C # gives designers and developers a great deal of space to the 4.5 method parameters we can even use async methods to control simple asynchronous method, then the first to sum up the kind of C #.
- Fixed parameters: public void methodName (string a, out b, ref c);
- Dynamic parameters: public void methodName (string a, string b = "defautlString")
- Variable parameters: public void methodName (params string [] a);
- Expression (injection method): public void methodName (Func <string> func, Action act);
- Generic parameters: public void methodName <T> (T a) where a: class;
In C # we need from you to think and give full play to the characteristics of the language itself, to simplify the code to enhance readability effect "injected" in this regard. Here to talk about "injected" mainly refers to two aspects, one is the "code injection", the second is "the type of injection."
"Code injection" method is to pass a "proxy" class inside the method is to open up a "scalable" to perform part of the unknown, variable functions, then we can enhance its relatively "closed" approach " open "nature.
By using the generic method, we can relatively common operation type "closed" in the case of type "open" up, so that the composite can be used largely replaced generic class inheritance, polymorphism reduced class Coupling.
Richter Substitution Principle (LSP)
Where applicable local base class, subclass necessarily apply
- A large number of members who appear subclass does not apply, it should be from a subclass inheritance
- Where a large number of base class virtual member, the class lost condition becomes the base class
Dependency Inversion principle (DIP)
To rely on the abstract, do not rely on concrete.
Interface Segregation Principle (ISP)
Using multiple specialized interface is better than the applicable single interface
Synthetic / polymeric multiplexing principles (the CARP)
To make full use of synthesis / polymerization, try not to use inheritance
Coad only when the following conditions are met, you should use inheritance:
- Subclass is a special kind of super-class, rather than the role of a super class. Distinguish "Has-A" and "Is-A". Only "Is-A" relationship is consistent with inheritance, "Has-A" relationship should be used to describe the polymerization.
- "Is-A" is representative of a class of another class;
- "Has-A" on behalf of a class is another role of a class, not the other kind of a special class.
- Never appear necessary to subclass into another case of a subclass of class. If you are not sure whether the future will become another subclass then, do not use inheritance.
- Subclass superclass with extended responsibilities, instead of having a replacement out (override) or written off (Nullify) responsibility superclass. If a child requires a lot of class displaces the superclass behavior, then this class should not be a subclass of the superclass. (Note: The method comprises the new C #, attributes and internal implementation is equivalent to a single base class interface nullify)
- Only meaningful taxonomic point of view, you can use inheritance. Do not inherited from the tools.
Synthesis of (Composite) - the value of polymerization (Aggregation by value)
public class Keyboard{} public class Mouse{} public class Monitor{} public class Computer { private Keyboard keyboard; private Mouse mouse; private Monitor monitor; public Computer() { this.keyboard=new Keyboard(); this.mouse=new Mouse(); this.monitor=new Monitor(); } }
It is seen from this example, so-called "value (the Value)" Synthesis internal member "Computer" in the constructor, like the individual functional components assemble into a single powerful product. All dependencies are "off" within the constructor, if the use of the plant can be dependent on external (Factory Pattern) and a combination mode (Composite Pattern) evolve.
public class Item{}; public class Keyboard:Item{} public class Mouse:Item {} public class Monitor:Item{} public ComputerFactory { public Item Keyboard() { return new Keyboard(); } public Item Monitor() { return new Monitor(); } public Item Mouse() { return new Mouse(); } } public class Computer { public List<Item> Items{get;set;} public Computer(ComputerFactory factory) { this.Items.Add(factory.Keyboard()); this.Items.Add(factory.Mouse()); this.Items.Add(factory.Monitor()); } }
Polymerization (Aggregation) - references polymerization (Aggregation by reference)
public class Computer { public Mouse Mouse{ get;set; } public Monitor Monitor{ get; set; } public Keyboard Keyboard {get;set;} } public class Host { public static void Main() { var computer=new Computer() { Mouse=new Mouse(), Monitor=new Monitor(), KeyBoard=new KeyBoard() }; } }
Hold live polymerization class is a reference to the instance of the class, not only is the value. Polymer of class that references a concentration-dependent, is also said that this class Computer Facade pattern from a certain sense. In this way the entrance is common in large-scale class object model, such as the Office of the Application object, such a design can be for developers to "find" a reference to the class. While the design can also be used as context: .net in System.Web.HttpContext. It is noted that: the aggregate class with caution is needed for convergence of the class itself is coupled referenced class, while also having a characteristic coupling polymerization type conduction, by the constructor. Take EF say do it, we all need to access the database with EF code like this:
public void OrderManager { public List<Order> GetOrder() { using (var ctx=new DbContext( ) { //… } } }
When this new code will appear in the entire bad dishes! The coupling structure referenced once every call to increase one point, when even layer over the entire access system DBContext is a super-giant coupling unalterable tumor! To resolve this problem in one piece or mode may be configured with self IoC, DI is configured to move to a central place, to prevent the spread of the coupling structure.
summary
Reproduced in: https: //www.cnblogs.com/Ray-liang/p/3859024.html