Headfirst design mode learning notes (C #): Duck and Strategy Mode

The policy pattern design principles are as follows:

1. ChangeCodeIndependent code should be separated from those that do not need to change frequently.

2. programming should be performed on interfaces rather than classes.

3. Multi-Purpose Combination and less inheritance should be used in the class.

Example:

We need to implement a duck simulator, which is described by the duck class, and the duck class has the following four actions:

1. Display

2. Swim

3. Fly)

4. Quack (called)

Swim is a feature of all ducks, and these features are the same for all ducks. Therefore, this method can be implemented directly in the duck class. The display method is also a feature of all ducks. However, the display method varies with the duck type. Therefore, the display method should be an abstract method of the duck class. Fly and quack are not the characteristics of all ducks. For example, they cannot fly or be called. Therefore, we can regard these two methods as two actions, and design each behavior into an interface. This can be completely different from the duck class. Because fly and quack have nothing to do with duck (other things may fly and quack), and different fly and quack are represented by classes that implement corresponding interfaces respectively.

The complete duck code is as follows:

Fly Behavior

// Flight Interface
Public   Interface Flybehavior
{
String fly ();
}

// Fei
Public   Class Flywithwing: flybehavior
{
Public String fly ()
{
Return   " Flying with wings " ;
}
}

// Feifei
Public   Class Flynoway: flybehavior
{
Public String fly ()
{
Return   " No Fly " ;
}
}

Quack Behavior

// Call
Public   Interface Quackbehavior
{
String quack ();
}
// Gaga
Public   Class Quack: quackbehavior
{
Public String quack ()
{
Return   " Gaga " ;
}
}

// Scream
Public   Class Squeak: quackbehavior
{
Public String quack ()
{
Return   " Scream " ;
}
}

// Not called
Public   Class Mutequack: quackbehavior
{
Public String quack ()
{
Return   " Not called " ;
}
}

Implement duck class

// Duck category
Public   Abstract   Class Duck
{
Protected Flybehavior;
Protected Quackbehavior;

Public Duck ()
{
// Default behavior
Flybehavior =   New Flywithwing ();
Quackbehavior =   New Quack ();
}
Public String swim ()
{
Return   " Swimming " ;
}
Public String response mfly ()
{
Return Flybehavior. Fly ();
}
Public String queue mquack ()
{
Return Quackbehavior. Quack ();
}
Public   Void Setflybehavior (flybehavior)
{
This . Flybehavior = Flybehavior;
}
Public   Void Setquackbehavior (quackbehavior)
{
This . Quackbehavior = Quackbehavior;
}
Public   Abstract String display ();
}

Create different duck classes

// Wild Duck
Public   Class Mallardduck: Duck
{
Public   Override String display ()
{
Return   " Green duck " ;
}
}

// Braised Duck
Public   Class Redheadduck: Duck
{
Public   Override String display ()
{
Return   " Braised Duck " ;
}
}

// Rubber Duck
Public   Class Rubberduck: Duck
{
Public   Override String display ()
{
Return   " Rubber Duck " ;
}
}

The relationship between interfaces and classes is as follows:

The call code is as follows:

Private   Void Printmsg (duck)
{
Txtmsg. appendtext (duck. Display ());
Txtmsg. appendtext (duck. interval mfly ());
Txtmsg. appendtext (duck. Fetch mquack ());
}
Private   Void Btnstrategy_click ( Object Sender, eventargs E)
{
Txtmsg. Clear ();

duck = New mallardduck ();
printmsg (duck);
txtmsg. appendtext " \ r \ n " );

duck = New redheadduck ();
duck. setquackbehavior ( New squeak ());
printmsg (duck);
txtmsg. appendtext " \ r \ n " );

Duck= NewRubberduck ();
Duck. setflybehavior (NewFlynoway ());
Duck. setquackbehavior (NewMutequack ());
Printmsg (duck );
Txtmsg. appendtext (duck. Swim ());
Txtmsg. appendtext ("\ R \ n");
}

The output result is as follows:

The green duck is screaming with wings
Braised Duck is screaming with wings
Rubber Duck cannot fly, cannot call swimming

Http://www.cnblogs.com/nokiaguy/archive/2009/02/11/1388168.html