Ooad design mode-behavior mode __ design mode and modeling

I. Patterns of behavior

Behavior patterns are concerned with the behavior of objects. What this type of pattern needs to do is to abstract the behavior that is likely to change, by encapsulating the scalability of the entire architecture. A policy pattern, for example, is to abstract a potentially changing policy or algorithm into a separate interface or abstract class to enable future policy expansion. Other behavioral design patterns are similar, either encapsulating a request (a command pattern), or encapsulating a state (state mode), or encapsulating the access (visitor pattern), or encapsulating the traversal algorithm (the iterator pattern). The behavior that these patterns encapsulate is precisely the most volatile part of the software architecture and the most likely to be expanded. By encapsulating these behaviors, the use of abstract features provides the possibility of expansion.

There are 11 kinds of behavioral design patterns in Gof mode. Among them, behavioral class design patterns use inheritance to assign behavior between classes, including the template method pattern (Template methods) and the interpreter mode (interpreter) altogether two kinds. The Behavior object pattern uses an object combination rather than inheritance, which describes how a group of objects can collaborate on tasks that cannot be accomplished by a single object, including the responsibility chain pattern (Chain of responsibility), Command mode (commands), iterator mode (iterator), Nine kinds of mediation mode (mediator), Memo mode (MEMENTO), observer mode (Observer), status mode (state), policy mode (strategy), visitor mode (Visitor).

1.1 Template Method mode template

The main process steps of a known process, but when some specific implementation is unknown, the abstract class controls the specific process and implements the class to implement specific step details. Use inheritance only.

By defining the skeleton of an algorithm in an operation, and delaying some steps into subclasses, the template method allows subclasses to redefine certain steps of the algorithm without altering the structure of an algorithm.

The template method pattern is intended to control the top-level logic by the abstract parent class, and to defer implementation of the basic operations to subclasses, by means of inheritance to achieve the reuse of objects, while also adhering to the opening and closing principles.

Move the invariant behavior to the superclass, removing the duplicated code in the subclass to reflect his advantage.

When unchanging and mutable behavior is mixed together in a method, the invariant behavior repeats itself in subclasses, and the template method pattern is to move the invariant behavior to a superclass, avoiding duplication of code.

1.2 Policy mode strategy

There are too many algorithms for a problem in the business, different implementations of different environments, the algorithm is abstracted into an interface, in the specific use of the class in combination to invoke.

Define a series of algorithms: the function of a policy pattern is to define a series of algorithms that enable these algorithms to be replaced by each other. Therefore, a common interface is defined for this series of algorithms to constrain the functionality to be implemented by a series of algorithms.

Avoid multiple conditional statements and better scalability.

Disadvantages:

Customers must understand the difference between each strategy.

Increased number of objects.

Only suitable for the flat structure of the algorithm: the strategy of a series of algorithm status is equal, can be replaced, in fact, constitute a flat algorithm structure, that is, under a policy interface, there are multiple equal strategy algorithm, is equivalent to the sibling algorithm. And at runtime only one algorithm is used, which limits the level of the algorithm used, can not be nested use. For situations where multiple algorithms need to be nested, such as folding, rewinding, and so on, you need to combine or nest multiple algorithms, consider using a decorative pattern, or a distorted chain of responsibilities, or AOP.

Scope of application:

There are many related classes, only the behavior is different, you can use the policy pattern to use one of the multiple behaviors to configure a class of methods to achieve dynamic switching algorithm;

The same algorithm, there are many different implementations of the situation, you can use the policy model to implement these "different implementations" into an algorithm class level;

In order to avoid exposing these algorithms-related data structures, we need to encapsulate the algorithm and the data related to the algorithm.

You can use the policy pattern instead of the conditional statements that appear to abstract a class that defines a lot of behavior, and to select these behaviors through multiple if-else statements.

1.3 Observer Mode

Defines a one-to-many dependency between objects, and when the state of an object changes, all objects that depend on it are notified and automatically updated.

Effect and realization essentials

1. Using object-oriented abstraction, the Observer pattern allows us to change the target and the observer independently, thus making the dependency between the two mutually loosely coupled.

2. When a target sends a notification, no observers are specified, and notifications (which can carry notification information as parameters) are automatically propagated. The observer himself decides whether to subscribe to the notification. The target is ignorant of this.

3. An event in C #. Delegates act as abstract observer interfaces, while objects that provide events act as target objects, and delegates are designs that are more loosely coupled than abstract observer interfaces.

Applicability

1. When an abstract model has two aspects, one aspect relies on the other. Encapsulate the two in separate objects so that they can be changed and reused independently of each other.

2. When a change to an object needs to change other objects at the same time, do not know how many objects to be changed.

3. When an object must notify other objects, it cannot assume that the other object is. In other words, you don't want these objects to be tightly coupled.

[Java] View Plain Copy public class product extends observable{               private String name;               private float price;           Public string getname ()  {           return  name;       }          public  Void setname (string name)  {            this.name = name;       }           public float getprice ()  {            return price;       }          public  void Setprice (Float price)  {           this.setchanged () ;           this.notifyobservers (price);            this.price = price;       }   }   [Java] View Plain copy import java.util.observable;   import java.util.observer;       public class priceobserver implements observer{           public void update (observable o, object arg)  {            // TODO Auto-generated method stub           Product pro =  (Product) o;            if (Pro.getprice ()  >  (Float) arg) {                system.out.println ("Price:"  +  ( Pro.getprice ()  -  (Float) arg);           }else  if (Pro.getprice ()  <  (Float) arg) {                System.out.println ("Price:"  +  ((Float) Arg - pro.getprice ());            }       }