Soft Test Architect 9 Design PatternPosted by Dam Nymann on February 7th, 2021 full text links: https://www.cnblogs.com/nullering/p/9684820.html There are many in-depth design patterns. Here I simply list some concepts in the exam. If you wish to have a deep understanding, you are able to refer to this big man's weblog: https://www.cnblogs.com/zuoxiaolong/category/509144.html Concept: design pattern Pattern is some repeated use, most people know, after classification cataloging, code design experience summary. The objective of using design patterns is to reuse code, make it easier for the others to comprehend, and ensure the reliability of code. Design pattern gets the benefit of "adapting to the change of requirement". Basics: modules should be available to expansion, but closed to modification, aiming at interfaces rather than composition, abstraction must not depend on details, details should count on abstraction basic classification: there are 23 patterns, 3 categories, creation type, 5 structure type, 7 structure type Behavior type 11 object instantiation mode, and creation type mode can be used to decouple the item instantiation process. Definition: (provides an interface for making a set of related or interdependent objects without specifying their specific classes. ) The so-called abstract factory pattern is always to provide an interface for creating families of related or dependent objects without the need forSpecify specific classes explicitly. It allows customers to use abstract interfaces to make a set of related services and products and never having to concern themselves using what the actual products are. In this way, clients could be decoupled from specific products. Its advantage is that it isolates the generation of specific classes, so your client does not need to understand what has been created. Its disadvantage is that it's troublesome to include new behaviors, because when adding a new product object, it is more necessary to change the interface and all its subclasses. Definition: (defines an interface for creating objects, and lets subclasses decide which class to instantiate. Factory methods delay the instantiation of a class to its subclasses. ) The factory method mode is quite in keeping with the "open close principle". Once we have to add a new product, we just need to put in a specific product class and the corresponding specific factory, and there is no need to modify the original system. At the same time, in the factory method mode, the consumer only has to know the particular factory of the merchandise, and does not need to know the creation procedure for the item, and even the particular product class name. Although it is well on the basis of the "open close principle", but because each new product needs to add two classes, it's going to inevitably lead to the increase of system complexity. definition: (separates the construction of a complex object from its representation, so the same construction process can create different representations. ) Usage scenario: ● when the same method, different execution sequence and various event answers are generated, the builder mode can be utilized. ● multiple components orAll parts may be assembled in to one object, but the running email address details are different, so this mode can be utilized. The merchandise class is very complex, or the calling order in the item class is different, leading to different performance. It is very appropriate to make use of the builder mode currently. definition: (specify the type of created objects with prototype instances, and create new objects by copying these prototypes. ) definition: (ensure that the class has just one instance, and instantiate it by itself and offer it to the entire system. ) Usage scenarios: ● a host that needs the generation of an original serial number; ● a shared access point or shared data, like a counter on a website, is needed in the entire project, so it is unnecessary to record every refresh to the database, and the singleton mode is used to keep consitently the value of the counter and make sure that it really is thread safe; ● the usage scenarios are as follows: Creating an object consumes way too many resources, such as for instance accessing IO, database and other resources; ● within an environment where a large numbers of static constants and static techniques (such as tool classes) have to be defined, singleton mode can be used (of course, static mode may also be declared directly). When only one instance object is necessary in the machine or just one public access point is allowed in the machine, and the instance can't be accessed through other access points except this public access point, singleton mode can be used. The main advantage of singleton mode is to save yourself system resources, improve system efficiency, and strictly control customers' access to it. Maybe it's becauseThere is one instance in the machine, and so the responsibility of singleton class is too heavy, which violates the "single responsibility principle". At the same time, there's absolutely no abstract class, therefore it is difficult to expand. Implementation: 1) lazy type - thread unsafe 2) hungry type - thread safe: if uniqueinstance is directly instantiated, you will have no thread unsafe problem. But the direct instantiation method also loses the resource saving advantages of delayed instantiation. 3) lazy -- thread safety 4) make sure lock -- thread safety 5) static inner class 6) enumeration combines classes or objects to make a larger structure. Definition: (decouples abstraction and implementation in order to change independently. ) Use scenarios: ● scenarios where inheritance is not expected or applicable ● scenarios where interfaces or abstract classes are unstable ● scenarios with high reusability requirements note: bridge mode can be considered when n layers of class inheritance are observed. Bridge mode mainly considers how to separate abstraction and implementation. definition: (dynamically add some additional responsibilities to an object. In terms of adding functions, decoration mode is more flexible than subclass generation. ) Usage scenarios: ● it's important to increase the functions of a class or add additional functions to a class. You'll need to include functions to an object dynamically, and these functions could be cancelled dynamically. ●Need for several siblings to modify or add features, of course, may be the preferred decoration mode. definition: (provides a proxy for other objects to regulate usage of this object. ) definition: (transforms the interface of a class into yet another interface expected by your client, in order that two classes that could not interact due to interface mismatch can perhaps work together. ) Usage scenario: when you are motivated to change an interface that's been put in production, adapter mode could be the the most suitable mode for you. For example , if the machine is extended, you should employ an existing or newly established class, but this class doesn't conform to the device interface. What should I do? Use the adapter pattern, that will be also mentioned inside our example. Note: in the step-by-step design stage, the adapter mode should not be considered. The main scenario is in the extended application. definition: (the utilization of shared objects can effectively support a large number of fine-grained objects. ) Usage scenarios: ● there are a many similar objects in the device. Fine grained objects have close external state, and the inner state has nothing in connection with the environmental surroundings, in other words, objects haven't any specific identity. Scenarios that want buffer pools. Note: ● the shared meta mode isn't thread safe. We must rely on experience and consider thread safety where necessary. Generally in most scenarios, we don't need to ponder over it. You will find as much meta objects that you can in the thing pool until they are enough. Performance security: the very best external state is the basic JavaType as a flag, such as string, int, can improve efficiency. definition: (it requires that the communication between the outside and the within of a subsystem should be carried out through a unified object. Facade mode provides a high-level interface, making the subsystem simpler to use. ) Usage scenarios: ● provide an interface for external access for a complex module or subsystem ● the subsystem is relatively independent - external usage of the subsystem can only be achieved by black box operation > To prevent the risk diffusion caused by low-level personnel note: ● a subsystem can have several facade ● facade will not be involved in the company logic in the subsystem definition: (objects are combined right into a tree structure to represent the "part whole" hierarchy, in order that users may use an individual object and a composite object consistently. ) Usage scenarios: ● maintain and display the part whole relationship, such as tree menu, file and folder management. A scene by which some modules or functions can be separated from the whole. Note: so long as it is a tree structure, consider utilising the combination pattern. how classes and objects interact, and how responsibilities and algorithms are divided. Definition: (encapsulates some operations that act on the current weather of a data structure. It can define new operations that act on these elements without changing the data structure. ) definition: (defines a one to many dependency between objects, in order that every time an object changesAll objects that depend onto it will be notified and automatically updated. ) Usage scenarios: ● associated behavior scenarios. It must be noted that the association behavior is separable, not really a "composite" relationship. Multi level event triggering scenario. Cross system message exchange scenarios, such as message queue processing mechanism. Note: ● broadcast chain problem in an observer mode, for the most part one object is both observer and the observed, in other words, the message may be forwarded once (delivered twice) for the most part. ● asynchronous processing problem there are many observers and the processing time is relatively long. Asynchronous processing can be used to consider thread safety and queue. definition: (capture the internal state of an object without destroying encapsulation, and save yourself the state away from object. In this way, the thing could be restored to its original saved state later. ) Usage scenarios: ● relevant state scenarios that need to truly save and recover data. Provide a rollback operation. In the replica scenario that needs to be monitored. The transaction management of database connection may be the memo mode. Note: ● duration of memo ● performance of memo avoid memo mode in the scenario of frequent backup establishment (such as in a for loop). definition: (defines the framework of an algorithm within an operation, and delays some steps to subclasses. bringSubclasses can redefine some specific steps of an algorithm without changing its structure. ) definition: (when an object's internal state changes, it really is allowed to change its behavior, and the thing appears to change its class. ) Usage scenarios: ● scenarios by which behavior changes with state changes this really is also the essential kick off point of state mode, such as for example permission design. Different states of personnel will cause different results even if indeed they perform the same behavior. In this case, it is necessary to consider using state mode. The choice of condition and branch judgment sentence note: state mode does apply to when an object changes in its state, its behavior also changes greatly, in other words, state mode can be utilized if the behavior is constrained by state, and the object's state shouldn't exceed five. definition: (encapsulates a request in to an object, to enable you to parameterize the customer with different requests, queue requests or record request logs, and offer command revocation and recovery functions. ) definition: (a mediation object encapsulates some object interactions, and the mediator makes the objects interact with each other without display, in order that they are loosely coupled and can change their interactions independently. ) Usage scenario: mediator mode is relevant to the case of tight coupling between multiple objects. The typical of tight coupling is: spider web structure appears in the class diagram, that is, each class has direct reference to other classesDepartment. definition: (it supplies a solution to access the current weather of a container object without exposing the internal information on the thing. ) definition: (given a language, define a representation of its grammar, and define an interpreter, which uses the representation to interpret sentences in the language. ) Use scenario: ● the interpreter mode can be used for repeated problems ● an easy syntax has to be explained note: don't use the interpreter mode in important modules, otherwise maintenance will be a big problem. In the project, shell, jruby, groovy and other scripting languages can be used instead of interpreter mode to create up for the shortcomings of java compiler language. definition: (enables multiple objects to have the opportunity to process the request, hence preventing the coupling relationship between your sender and the receiver of the request. Connect these objects right into a chain and pass the request along the chain until an object processes it. ) definition: (define several algorithms, encapsulate each algorithm, and cause them to become interchangeable. ) Usage scenarios: ● multiple classes only have slightly different algorithms or behaviors. The scene where the algorithm must switch freely. Scenarios that require to mask algorithm rules. Note: if the number of specific strategies exceeds 4, the mixed mode is highly recommended Finally, both MVCs are not only architecture style, but also design pattern filter pattern. Java. Net's common options for registration and access 1, strategy 2, observer, 3, decoration 4, factory five, list six, command 7, adapter 8, template 9, combination 10, status what is the look pattern for? It really is an over-all solution to a class of problems four elements: pattern name, problem, solution and effect a class has only one basis for its change. There must be only one responsibility. Each responsibility is an axis of change. If a class has multiple responsibility, these responsibilities are coupled together. This leads to fragile design. When one duty changes, other duties might be affected. In addition , the coupling of multiple responsibilities will affect the reusability simply put, a class is in charge of one responsibility. It can reduce steadily the complexity of a class. A class is only accountable for one responsibility, and its particular logic is a lot simpler than that of multiple responsibilities. The principle of single responsibility is well observed. When one function is modified, it could significantly reduce steadily the effect on other functions. The alleged principle of Dependence Inversion（Dependency inversion principle is to count on abstraction, not concrete. The important thing to understand the open close principle is abstraction, and the concrete implementation comes from abstraction. If the open close principle may be the goal of object-oriented design, then counting on the reversal principle is the main means of object-oriented design. Definition: higher level modules shouldn't rely on low level modules, both of these should depend on their abstractions; abstractions should not count on details; details should rely on abstractions. Popular point: it really is required to program the abstract, not the implementation, so as to decrease the coupling between the client and the implementation module. Low level modules should have abstract classes or interfaces, or both. the declaration kind of variables must be abstract class or interface so far as possible. The use of inheritance follows the Riemannian substitution principle. The literal meaning of the principle is that using multiple isolated interfaces is preferable to utilizing a single interface. The purpose is to reduce steadily the coupling between classes, and design pattern is a software design idea, beginning the large computer software architecture, for the ease of upgrade and maintenance. For that reason it appears many times above: reduce dependence, reduce coupling. Original definition: the customer must not rely on interfaces it doesn't need; the dependence of just one class on yet another must certanly be based on the smallest interface. The meaning of interface isolation principle is: begin a single interface, not really a single interfaceEstablish a huge and bloated interface, refine the interface whenever possible, and minmise the techniques in the interface. In other words, we have to begin a special interface for each class instead of trying to create a huge interface for all classes that depend on it to call. In this example, the principle of interface isolation is used to alter a huge interface to three dedicated interfaces. In programming, it really is more flexible to rely on several special interfaces than on a thorough interface. Interface may be the "contract" set to the exterior in design. By defining multiple interfaces in a decentralized way, it may stop the diffusion of external changes and enhance the flexibility and maintainability of the system. At this time, many people believe that the interface isolation principle is quite like the previous single responsibility principle, however it is not. First, the principle of single responsibility is targeted on responsibility, whilst the principle of interface isolation centers around the isolation of interface dependence. Secondly, the principle of single responsibility is especially about constraint classes, accompanied by interfaces and methods, which aim at the implementation and information on the program; as the principle of interface isolation is especially about constraint interfaces, mainly about abstraction, and the construction of the general framework of this program. The interface should be no more than possible, but limited. It's true that refining the interface can increase the flexibility of program design, but if it's too small, it will cause a lot of interfaces and complicate the style. So it must be moderate. Custom services for interface dependent classes are just subjected to the strategy that the calling class needs, whilst the methods that it doesn't need are hidden. Only when we focus on providing customized services for a module, can we establish the minimum dependencyIt depends on the partnership. Improve cohesion and reduce external interaction. Make the interface do the most in the least way. The open close principle is that it's available to extension and closed to modification. When the program has to be expanded, we can not modify the first code to attain a hot swap effect. So in short, in order to make this system extensible, easy to maintain and upgrade. To do this effect, we truly need interface oriented programming. baidu baiduLike it? Share it! |