Design Patterns Overview

Design pattern is a set of design pattern that is repeatedly used, known to most people, and classified,CodeSummary of design experience. The design pattern is used to make code reusable, make it easier for others to understand, and ensure code reliability.

There is no doubt that the design model is a win-win solution for others and the system. The design model enables code compilation to be truly engineered. The design model is the foundation of software engineering, just like the building blocks.

Gof's "Design Pattern" is the first time that it has elevated the design pattern to a theoretical level and standardized it. This book has proposed 23 basic design patterns. Since then, during the development of reusable object-oriented software, a large number of new design patterns are emerging.

I. Design Model and framework

Currently, reusable object-oriented software systems are generally divided into three categories:
ApplicationProgramToolbox and framework. The specific software we develop at ordinary times is an application; Java API is a toolbox; the framework is a group of collaborative classes that constitute a type of reusable design for specific software. EJB (enterprisejavabeans) is a Java framework applied to enterprise computing.

The framework usually defines design parameters such as the relationship between the overall structure class and object of the application system, so that specific application implementers can focus on specific details of the application. The framework mainly records the common design decisions in software applications, and emphasizes design reuse. Therefore, the design model must be used in the framework design.

In addition, the design patterns help you understand the framework structure. Mature frameworks usually use multiple design patterns. If you are familiar with these design patterns, you will no doubt be able to quickly master the structure of the Framework, if developers suddenly come into contact with ejbj2ee and other frameworks, they will feel particularly difficult to learn and master. Instead, they will first master the design mode, which is undoubtedly a powerful tool for you to analyze the EJB or J2EE system.

Ii. Design ModePrinciples

In recent years, everyone has begun to pay attention to the design model. So why should we use the design pattern? Why are so many design patterns designed? To be honest, I have never figured it out before. It's just a look at everyone's "design pattern", and the heart is a bit weak. So I bought the design model of the "four-person gang". The results showed that I understood it clearly. I forgot it later. It may be because I am relatively "stupid" :)) recently, I have some insights. "Joy is better than joy". I 'd like to share it with you and hope to give you some advice!
Why do we advocate "Design Pattern? The root cause is to reuse code and increase maintainability. So how can we achieve code reuse? There are several principles: "open-closed" principle (open closed principal), Lishi replacement principle, and synthetic Reuse Principle. The design pattern is to achieve these principles, so as to achieve code reuse and increase maintainability.

1. "Open-Close" Principle

This principle was proposed by "Bertrand Meyer. Original article: "software entities shocould be open for extension, but closed for modification ". That is to say, the module should be open for expansion, but closed for modification. The module should be extended without modifying the original (original) code. How can we scale it out? Let's look at the factory model "factory pattern": Suppose Zhongguancun has a hacker who sells pirated disk and wool film. We designed a "CD sales management software" for him ". We should first design a "cd" interface.
______________
| <> |
| Cd |
| _____________ |
| + Sell () |
|
| _____________ |
The pirated disk and the wool film are its sub-categories. The kid manages these CDs through "discfactory. Code:

Public class discfactory {
Public static disc getdisc (string name ){
Return (CD) class. forname (name). getinstance ();
}
}
How can someone buy a pirated disk?

Public class kiddies {
Public static void main (string [] ARGs ){
CD d = discfactory. getdisc ("pirated disk ");
CD. Sell ();
}
}

If one day, this kid finds his conscience and starts selling genuine software. It doesn't matter. We just need to create another sub-category "genuine software" of "cd. You do not need to modify the original structure and code. How is it? For extension development, disable modification. "Open-closed principle"
The factory model is to expand specific products. Some projects may require more scalability. To expand the "Factory", it becomes an "Abstract Factory model ".

2. Lee's replacement principle

The Li's replacement principle was proposed by "Barbara liskov. If the parent class is called, the sub-classes can be fully run. For example:
CD d = new pirated disk ();
D. Sell ();
Now I want to change the category of "pirated disk" to "fake disk". No problem, it can be fully run. The Java compiler checks whether the program complies with the Li's replacement principle. Do you still remember a principle inherited by Java? The access permission of the subclass overload method cannot be less than that of the method corresponding to the parent class. For example, if the "sell" access permission in "cd" is "public", the "sell" method in "pirated disk" and "Mao film" cannot be package or private, and compilation cannot pass. Why? You think: if the "selling" method of "pirated disk" is private. The following code cannot be executed:
CD d = new pirated disk ();
D. Sell ();
It can be said that the Li's replacement principle is a basis for inheritance reuse.

3. Principles of merging and reuse

That is to say, we need to use less inheritance and more synthesis relationships. I once wrote a program like this: There are several classes that need to deal with the database, so I wrote a database operation class, and other classes dealing with the database inherit this class. As a result, I modified a method of the database operation class, and each class needs to be modified. "Pull your whole body "! Object-oriented is to limit fluctuations to the smallest possible range.

In Java, you should try to program interfaces instead of implementing classes. In this way, changing the subclass does not affect the code that calls its method. We need to keep every category in touch with others as little as possible, "Don't talk to strangers ". In this way, the fire in the city will not affect the fish in the pool. Scalability and maintainability can be improved

After understanding these principles, let's look at the design model, just how to implement these principles on specific issues. Zhang Wuji learned Taijiquan. He forgot all his tricks and knocked down Xuan Mi, the so-called "No tricks in his mind ". The design pattern can be described as a trick. If you learn all kinds of patterns first, and forget all the patterns and do what you want, it can be described as the highest level of OO. Haha, funny, funny! (JR)

4. Dependency reversal Principle

Abstraction should not be dependent on details, but details should be dependent and abstract.

Programming for interfaces, rather than implementing programming.

PASS Parameters, or reference classes with high levels as much as possible in composite aggregation relationships.

We can dynamically create various specific objects when constructing objects. Of course, if some specific classes are stable, you do not have to create an abstract class as its parent class, this gives you the feeling of tongue-filling.

5 interface isolation principles

In the example of customized services, each interface should be a role, not many, and should not do anything that should not be done.

6 abstract classes

The abstract class does not have instances. It is generally inherited as a Child class of the parent class and generally contains the common attributes and methods of this series.

Note: In a good inheritance relationship, only leaf nodes are specific classes, and other nodes should be abstract classes, that is, specific classes

Is not inherited. Put as much common code as possible into the abstract class.

7 dumit's Law

Minimum knowledge principle. Do not talk to strangers.

3. Four Basic Elements of a model

The design pattern allows people to reuse the successful design and architecture more easily and easily. Expressing proven technologies into design patterns makes it easier for new system developers to understand their design ideas.

1. Mode name(Pattern name)

It uses one or two words to describe the model's problems, solutions, and effects. Naming a new pattern adds our design vocabulary. The design pattern allows us to design at a higher abstraction level. Based on a schema vocabulary, we can discuss patterns between ourselves and our colleagues and use them when writing documents. The model name can help us think about it, so that we can exchange design ideas and design results with others. Finding the proper pattern name is also one of the difficulties in designing pattern cataloguing.

2. Problem(Problem)

Describes when to use the mode. It explains the causes and consequences of design problems and problems, and may describe specific design problems, such as how to use objects to represent them.Algorithm. It may also describe the class or object structure that leads to inflexible design. Sometimes, the problem part includes a series of prerequisites that must be met by the usage mode.

3. Solution(Solution)

Describes the components of the design, the relationship between them, their respective responsibilities and collaboration methods. Because a pattern is like a template and can be used in many different scenarios, the solution does not describe a specific and specific design or implementation, instead, it provides an abstract description of the design problem and how to use a combination of general elements (class or object combination) to solve the problem.

4. Results(Consequences)

Describes the effect of the model application and the balance between the use mode. Although we do not always mention pattern effects when describing design decisions, they are important for evaluating design choices and understanding the cost and benefits of patterns. Most of the software results focus on measuring time and space. They also express language and implementation problems. Because reuse is one of the elements of object-oriented design, the pattern effect includes its impact on system flexibility, scalability, or portability, listing these effects explicitly is helpful for understanding and evaluating these patterns.

4. Some Basic Design Models

2. Abstract Factory: provides an interface for creating a series of related or mutually dependent objects without specifying their specific classes.
4. Adapter: converts an interface of a class to another interface that the customer wants. The A d a p t e r mode makes those classes that cannot work together due to interface incompatibility work together.
6. Bridge: separates abstract parts from their implementations so that they can all change independently.
8. Builder: separates the construction of a complex object from its representation, so that different representations can be created during the same construction process.
10. Chain of responsibility: to cancel the coupling between the request sender and receiver, multiple objects have the opportunity to process the request. Connect these objects into a chain and pass the request along the chain until an object processes it.
12. Command: encapsulate a request as an object so that you can parameterize the customer with different requests, queue requests or record request logs, and support cancelable operations.
14. Composite: combines objects into a tree structure to represent a "part-whole" hierarchy. It makes the customer's use of a single object and composite object consistent.
16. Decorator: dynamically add some additional responsibilities to an object. The extended function is more flexible than the subclass generation method.
18. Facade: provides a consistent interface for a group of interfaces in the subsystem. The facade mode defines a high-level interface, which makes this subsystem easier to use.
20. Factory method: defines an interface for creating objects, so that the subclass determines which class to instantiate. Factory method delays the instantiation of a class to its subclass.
22. Flyweight: uses the sharing technology to effectively support a large number of fine-grained objects.
24. Interpreter: for a given language, define a representation of its syntax and define an interpreter that uses this representation to interpret sentences in the language.
26. Iterator: provides a method to access each element of an aggregate object sequentially without exposing the internal representation of the object.
28. Mediator: uses an intermediary object to encapsulate a series of object interactions. The intermediary makes the objects do not need to be explicitly referenced to each other, so that the coupling is loose and the interaction between them can be changed independently.
30. Memento: capture the internal state of an object without compromising encapsulation, and save the state outside the object. In this way, the object can be restored to the Saved state.
32. Observer: defines a one-to-many dependency between objects, so that when the status of an object changes, all objects dependent on it are notified and automatically refreshed.
34. Prototype: Use a prototype instance to specify the type of the object to be created, and copy the prototype to create a new object.
36. Proxy: provides a proxy for other objects to control access to this object.
38. Singleton: ensures that a class has only one instance and provides a global access point to access it.
40. State: allows an object to change its behavior when its internal state changes. The object seems to have modified its class.
42. Strategy: defines a series of algorithms, encapsulates them one by one, and makes them replaceable. This mode makes the algorithm changes independent of the customers who use it.
44. Template Method: defines the skeleton of an algorithm in an operation, and delays some steps to the subclass. The template method allows the subclass to redefine certain steps of an algorithm without changing the structure of an algorithm.
46. Visitor: an operation that acts on each element in an object structure. It allows you to define new operations that act on these elements without changing the classes of each element.

Creation Mode: Abstract Factory, builder, factory method, prototype, Singleton;
Structural mode: adapter, bridge, composite, decorator, facade, flyweight, proxy
Behavior mode: chain of responsibility, command, interpreter, iterator, mediator, memento, observer, state, strategy, template method, visitor

Overview

Name factory Method
The intent defines an interface for creating objects, so that the subclass determines which class to instantiate. Factory method delays the instantiation of a class to its subclass.
Applicability when a class does not know the class of the object it must create.
When a class wants its subclass to specify the object it creates.
When a class delegates the responsibility of creating an object to one of multiple help sub-classes, and you want to localize the information of which help sub-classes are proxies.

Name Abstract Factory
The intent is to provide an interface for creating a series of related or mutually dependent objects without specifying their specific classes.
Applicability a system is independent of the creation, combination, and representation of its products.
A system must be configured by one of multiple product generations.
When you want to emphasize the design of a series of related product objects for joint use.
When you provide a product class library, instead of displaying their interfaces.

Name Builder
The intention is to separate the construction of a complex object from its representation so that different representations can be created during the same construction process.
Applicability when creating complex objects, algorithms should be independent of the components of the objects and their assembly methods.
When the constructor must allow different representations of the constructed object.

Name prototype
The intent is to use the prototype instance to specify the type of the object to be created, and create a new object by copying the prototype.
Applicability when the class to be instantiated is specified at the runtime, for example, through dynamic loading; or
To avoid creating a factory class level parallel to the product class level; or
When an instance of a class can only have one of several combinations of different States. Creating prototype and cloning them may be more convenient than manually instantiating this type with the appropriate state each time.

Name Singleton
The intent is to ensure that a class has only one instance and provide a global access point to it.
Applicability when a class can only have one instance and the customer can access it from a well-known access point.
When this unique instance should be extensible through subclass, and the customer should be able to use an extended instance without changing the code.

Name Adapter
It is intended to convert the interface of a class into another interface that the customer wants. The A d a p t e r mode makes those classes that cannot work together due to interface incompatibility work together.
Applicability you want to use an existing class, and its interface does not meet your needs.
You want to create a reusable class that can work together with other unrelated classes or unforeseen classes (that is, classes whose interfaces may not be compatible.
(Only applicable to object a d a p t e r) You want to use existing subclasses, but it is impossible to subclass each of them to match their interfaces. The Object Adapter can adapt to its parent class interface.

Name Bridge
The intent is to separate the abstract part from its implementation part so that they can all change independently.
Applicability you do not want to have a fixed binding relationship between the abstraction and its implementation. For example, this may be because the implementation part of the program should be selected or switched during the runtime.
Class abstraction and its implementation should be expanded by generating sub-classes. In this case, the B r I d G E mode allows you to combine different abstract interfaces and implementation parts and expand them separately.
The modification of an abstract implementation part should not affect the customer, that is, the customer's Code does not need to be re-compiled.
(C ++) You want to completely hide the abstract implementation part of the customer. In C ++, the class representation is visible in the class interface.
There are many classes to generate. Such a hierarchical structure indicates that an object must be divided into two parts. R u m B A u g h refers to this type of hierarchy as "nested generalization" (nested generalizations ).
You want to share the implementation among multiple objects (the reference count may be used), but the customer is not required to know this. A simple example is c o p l I e n s t r I N G class [c o p 9 2], multiple objects in this class can share the same string representation (s t r I n g r e p ).

Name: Composite
It is intended to combine objects into a tree structure to represent the "part-whole" hierarchy. C o m p o s I t e makes the use of a single object and a composite object consistent.
Applicability: the part of the object-the overall hierarchy.
You want to ignore the differences between a composite object and a single object. You will use all objects in the composite structure in a unified manner.

Name: decorator
Intention to dynamically add some additional responsibilities to an object. With the added function, the d e c o r a t o r mode is more flexible than the subclass generation mode.
Applicability adds responsibilities to a single object dynamically and transparently without affecting other objects.
Handle unrecoverable responsibilities.
When the subclass generation method cannot be used for expansion. One case is that there may be a large number of independent extensions. To support each combination, a large number of subclasses will be generated, resulting in explosive growth of the number of subclasses. Another scenario is that the class definition is hidden, or the class definition cannot be used to generate a subclass.

Name Facade
The intent is to provide a consistent interface for a group of interfaces in the subsystem. The f a c a d e mode defines a high-level interface, which makes the subsystem easier to use.
Applicability when you want to provide a simple interface for a complex subsystem. Subsystems tend to become more and more complex as they evolve. In most modes, More and smaller classes are generated. This makes subsystems more reusable and easier to customize, but it also brings some difficulties for users who do not need to customize subsystems. F a c a d e can provide a simple default view, which is sufficient for most users, those who need more customization can go beyond the f a c a d e layer.
There is a large dependency between the implementation part of the client program and the abstract class. Introducing f a c a d e to separate the sub-system from the customer and other sub-systems can improve the independence and portability of the sub-system.
When you need to build a layered sub-system, use the f a c a d e mode to define the entry points for each layer of the sub-system. If subsystems are mutually dependent, you can allow them to communicate only through f a c a d e, thus simplifying the dependency between them.

Name: flyweight
Intention to use the sharing technology to effectively support a large number of fine-grained objects.
Applicability an application uses a large number of objects.
Because a large number of objects are used, the storage overhead is very high.
Most States of an object can be changed to external states.
If you delete the external state of an object, you can replace multiple groups of objects with a relatively small number of shared objects.
Applications do not rely on object identifiers. Because the f l y w e I g h t object can be shared, the logo test returns the true value for an object that is conceptually distinct.

Name proxy
The intent is to provide a proxy for other objects to control access to this object.
Applicability when we need to replace simple pointers with common and complex object pointers, we use the p r o x y mode. The following are some common scenarios where the p r o x y mode can be used:
1) remote proxy provides a local representation of an object in different address spaces. Nextstep [add94] uses the N x p r o x y class to achieve this goal. Coplien [cop92] calls this proxy "Ambassador" (a m B A s a d o r ).
2) virtual proxy creates objects with high overhead as needed. The I m a G E P R o x y described in the motivation section is an example of such a proxy.
3) protection proxy controls access to the original object. Protection proxy is used when the object should have different access permissions. For example, in the C h o I c e s operating system [c I r m 9 3], k e m e l p r o x I e s provides access protection for operating system objects.
4) Smart reference replaces simple pointers and performs some additional operations when accessing objects. Its typical uses include:

The reference count pointing to the actual object. When this object is not referenced, it can be automatically released (also known as s m a r tp o I n t E R S [E d e 9 2]).
When a persistent object is referenced for the first time, it is loaded into the memory.
Before accessing an actual object, check whether it is locked to ensure that other objects cannot change it.

Name chain of responsibility
The intention gives multiple objects the opportunity to process the request, thus avoiding the coupling relationship between the request sender and the receiver. Connect these objects into a chain and pass the request along the chain until an object processes it.
Applicability there are multiple objects that can process a request, and the object that processes the request is automatically determined at the runtime.
You want to submit a request to one of multiple objects without specifying the receiver explicitly.
The object set that can process a request should be dynamically specified. R a n s a c t I o n) information systems are very common. A transaction encapsulates a group of changes to the data. The c o m a n d mode provides a method for modeling transactions. C o m a n d has a common interface that allows you to call all transactions in the same way. At the same time, it is easy to add new transactions to expand the system.
 
Name Interpreter
The intent is to give a language, define a representation of its syntax, and define an interpreter that uses this representation to interpret sentences in the language.
Applicability when a language needs to be interpreted and executed, and you can represent sentences in the language as an abstract syntax tree, you can use the interpreter mode. This mode works best in the following situations:
This grammar is simple for complex grammar, and the class layers of grammar become huge and cannot be managed. At this time, the syntax analysis program generator is a better tool. They can interpret expressions without building an abstract syntax tree, which saves space and time.
Efficiency is not a key issue. The most efficient interpreter is usually not implemented by directly interpreting the syntax analysis tree. Instead, they are first converted into another form. For example, regular expressions are usually converted to state machines. However, even in this case, the converter can still be implemented in interpreter mode, which is still useful.

Name iterator
The intent provides a way to access each element in an aggregate object sequentially without exposing the internal representation of the object.
Applicability accesses the content of an aggregate object without exposing its internal representation.
Supports multiple traversal of aggregate objects.
Provides a unified interface (supporting multi-state iteration) for Traversing different aggregation structures ).

Name Mediator
It is intended to encapsulate a series of object interactions with an intermediary object. The intermediary makes the objects do not need to be explicitly referenced to each other, so that the coupling is loose and the interaction between them can be changed independently.
Applicability a group of objects communicate in a well-defined but complex manner. The resulting dependency structure is confusing and hard to understand.
An object references many other objects and communicates directly with these objects, making it difficult to reuse the object.
We want to customize a behavior distributed in multiple classes without generating too many child classes.

Name: memento
The intention is to capture the internal state of an object without damaging encapsulation, and save the state outside the object. In this way, the object can be restored to the previously saved state.
Applicability must save the (partial) state of an object at a certain time point so that it can be restored to the previous state later.
If an interface is used to directly obtain these States for other objects, the implementation details of the object will be exposed and the object encapsulation will be broken.

Name: Observer
The intent defines a one-to-many dependency between objects. When the State of an object changes, all objects dependent on it are notified and automatically updated.
Applicability when an abstract model has two aspects, one of which depends on the other. Encapsulate the two in independent objects so that they can be changed and reused independently.
When changing an object, you need to change other objects at the same time without knowing how many objects need to be changed.
When an object must notify other objects, it cannot assume who the other objects are. In other words, you do not want these objects to be tightly coupled.

Name state
The intention is to allow an object to change its behavior when its internal state changes. The object seems to have modified its class.
APPLICABILITY The behavior of an object depends on its state, and it must change its behavior according to its state at runtime.
An operation contains a large number of conditional statements with multiple branches, and these branches depend on the state of the object. This state is usually represented by one or more enumerated constants. Generally, multiple operations contain the same condition structure. In the s t a t e mode, each condition branch is placed into an independent class. This allows you to take the object state as an object based on the object's own situation. This object can be independent of other objects.

Name: Strategy
Intent defines a series of algorithms, encapsulate them one by one, and make them replaceable. This mode allows algorithms to change independently of customers who use it.
Applicability many related classes only have different behaviors. "Policy" provides a method to configure a class with one of multiple actions.
Different variants of an algorithm are required. For example, you may define algorithms that reflect different space/time trade-offs. When these variants are implemented as class layers of an algorithm [h o 8 7], the policy mode can be used.
Algorithms use data that customers should not know. Policy modes can be used to avoid exposing complex algorithm-related data structures.
A class defines multiple behaviors, and these behaviors appear in the form of multiple conditional statements in the operations of this class. Move related condition branches into their respective s t r a t e g y classes to replace these condition statements.

Name Template Method
The intent defines the skeleton of the algorithm in an operation, and delays some steps to the subclass. Te m p l a t e m e t h o d allows the subclass to redefine certain steps of the Algorithm without changing the structure of an algorithm.
Applicability: implement the unchanged part of an algorithm at one time, and leave the variable behavior to the subclass for implementation.
Common behaviors in each subclass should be extracted and concentrated into a common parent class to avoid code duplication. This is a good example [o j 9 3] of "redecomposition to generalization" described by o p d y k e and J o h n s o n. First, identify the differences in the existing code and separate the differences into new operations. Finally, replace these different codes with a template method that calls these new operations.
Control subclass extension. The template method only calls the "h o k" operation at a specific point (see effect), so that the extension can only be performed at these points.

Name visitor
Indicates an operation that acts on each element in an object structure. It allows you to define new operations that act on these elements without changing the classes of each element.
Applicability an object structure contains many class objects with different interfaces, and you want to perform operations on these objects dependent on their specific classes.
You need to perform many different and unrelated operations on the objects in an object structure, and you want to avoid causing these operations to "pollute" the classes of these objects. Vi S I t o r allows you to set relevant operations in a class. When the object structure is shared by many applications, use the vi S I t o r mode to allow each application to only include the operations needed.
Classes that define the object structure are rarely changed, but new operations are often needed in this structure. Changing the object structure class requires redefining the interfaces for all visitors, which may be costly. If the object structure class changes frequently, it may be better to define these operations in these classes.

5. Three Steps to successfully adopt the design model

How can we combine the adoption of the design model with the approaching deadline, tight budget, and the limited team resources of many companies? The following are three steps for successful design model development.

Strong communication and training
Many organizations have advanced technologies and may have officially passed the arguments of the designer forum or informal recognized experts. The leading vendors will promote open communication in the design patterns and train teams developing specific design patterns. Communication should be performed across development teams and projects in advance to prevent the use of shafts and multiple unique implementations (remember the implementation of each developer/Project antipattern ). The training can adopt formal internal lunch-and-learns, formal internal class, or some employees can participate in external training. These training methods will promote the right design patterns of applications. If only a few audience members can attend the training, the best candidates are those who feel appropriate to be able to train their colleagues when they come back.

Guidance on Design Patterns

Name command
Structure
The intent is to encapsulate a request as an object so that you can parameterize the customer with different requests, queue requests or record request logs, and support unrecoverable operations.
The applicability is like the m e n u I t E M object discussed above, abstracting the action to be executed to parameterize an object. You can use the callback (c a l B A C K) function in the process language to express this parameterization mechanism. A callback function is a function that is registered at a certain place and will be called at a later time. The c o m a n d mode is an object-oriented alternative to the callback mechanism.
Specify, arrange, and execute requests at different times. A c o m a n d object can have a lifetime unrelated to the initial request. If the recipient of a request can be expressed in a way unrelated to the address space, the command object responsible for the request can be sent to another different process and implemented there.
Cancel the operation. The c o m a n d e x c u t e operation can store the status before performing the operation. This status is used to eliminate the impact of the operation when the operation is canceled. The c o m a n d interface must add a u n e x e c u t e operation, which cancels the effect of the last e x e c u t e call. The executed command is stored in a history list. You can traverse this list backward and forward and call u n e x e c u t e and redo ".
Logs can be modified so that the modifications can be redone when the system crashes. Add the loading and storage operations to the c o m a n d interface to maintain a consistent change log. Recovery from a crash involves re-reading the recorded commands from the disk and re-executing them with the e x e c u t e operation.
Construct a system with high-level operations built on primitive operations. Such a structure supports transactions (T
Design patterns can be used to benefit projects, but they may also cause damage to applications due to misuse. They should be encouraged, but their adoption should be reviewed and verified. The design pattern can be included in the design and development process. In either case, the use of design patterns should be validated and validated by reviewers. This may also occur during the review process. The additional design patterns are not applicable to the areas originally included. This step can be completed through peer review or team discussion even if no formal review is performed in the environment. Reviewers in this step are either members of the main team or establish open communications with them.
Guiding adoption is critical to the design pattern of the broad exposure category. These design patterns have many associated risks because they will create dependencies. These dependencies may be in some object classes. For example, they only work on the Data Access Object (DAO) in the wider DAO design mode Implementation scope) or cross-application boundary (for example, transmitting data between the application and application layers using the value object design mode ). These design patterns can also be implemented by others in the project or by people in different projects, and should be reused, different from creating another unique implementation.

Reuse implementation, not just the design mode
As long as you have met certain requirements when creating your own design patterns for implementation, teams and companies can gain more benefits when reusing occurs at the code layer, rather than when designing the creative layer. The initial design model that benefits enterprises is the implementation of improvement. However, the real goal is to reuse the implementation. Reuse implementation will lead to: a) other reusable classes (depending on public implementation); B) shorten development time and reduce costs; c) Shorten maintenance time and reduce costs; d) easy integration between applications and internally.
This reuse is very important (sometimes basic) to broad exposure design patterns ). These design patterns create external dependencies (integration will benefit from public implementations) or generate all custom class libraries (reusable if there is a public basis ). Isolated use design patterns can also benefit from reuse, but if they are customized based on specific circumstances, they are very difficult to reuse.
Sometimes you may ask yourself: "If reuse is better, why can't the design pattern and reusable implementations be applied together ?" This issue is discussed only when we discuss how design patterns benefit more readers. If possible, if the implementation has been predefined, it will be very difficult to achieve the goal of wide applicability. However, once the design pattern is applied to a special problem domain or technical infrastructure, the implementations generated in this environment can be reused.

Design Patterns in architecture
This looks like a terrible task. You need to know how the design model is applied in actual situations, how to build high-quality implementations, and how to promote reuse. One way to complete this task is to introduce the application architecture in the environment. The application architecture provides the structure required by the application so that the development team can focus on the application's domain logic. This includes the implemented design patterns. In addition to reusing the design pattern concept or a single implementation, You can reuse the architecture between multiple projects and applications. This shared public implementation ensures compatibility and provides a low-cost alternative for developing and maintaining multiple implementations. Compatibility provides the technical basis for reuse. There is not enough space to go into other important qualities of the architecture here, such as runtime monitoring and management, configurable application logic and adaptive behavior. You can learn more about the architecture from Carnegie Mellon Software Engineering Institute (www.sei.cmu.edu/ata/ata_init.html.