Interview Questions series (2) Four most common design models

Enter the several design patterns you are familiar. Examples:


The four most common design patterns are listed below


I. Strategy Mode


1. Two principles

Strategy
The mode embodies the following two principles:



1. Programming for interfaces, rather than implementing programming.



2. Multi-Purpose Combination and less inheritance.

2. Example:

Ii. iterator Mode

Provides a method to access each element in an aggregate object sequentially without exposing the internal representation of the object.
This design model is very common,
For example, in Java:
Public interface iterator {
Boolean hasnext ();
Object next ();
Void remove ();
}
And use ++ to access iterator in C ++ STL.

Iii. Singleton Mode


The following is a C ++ Singleton class:

1 # ifndef singleton_h <br/> 2 # define singleton_h <br/> 3 <br/> 4 # include "synobj. H "<br/> 5 <br/> 6 template <class T> <br/> 7 class Singleton {<br/> 8 class_uncopyable (Singleton) <br/> 9 public: <br/> 10 static T & instance () {// unique point of access <br/> 11 if (0 = _ instance) {<br/> 12 lock (_ mutex); <br/> 13 if (0 = _ instance) {<br/> 14 _ instance = new T (); <br/> 15 atexit (destroy); <br/> 16} <br /> 17} <br/> 18 return * _ instance; <br/> 19} <br/> 20 protected: <br/> 21 Singleton () {}< br/> 22 ~ Singleton () {}< br/> 23 private: <br/> 24 static void destroy () {// destroy the only instance <br/> 25 if (_ instance! = 0) {<br/> 26 Delete _ instance; <br/> 27 _ instance = 0; <br/> 28} <br/> 29} <br/> 30 static mutex _ mutex; <br/> 31 static T * volatile _ instance; // The one and only instance <br/> 32 }; <br/> 33 <br/> 34 template <class T> <br/> 35 mutex Singleton <t>:: _ mutex; <br/> 36 <br/> 37 template <class T> <br/> 38 T * volatile Singleton <t >:_ instance = 0; <br/> 39 <br/> 40 # endif/* singleton_h */

Iv. Factory method mode


The factory method mode generates objects with unified interface interfaces in different sub-factory classes. On the one hand, you can simplify and unify the client call process without worrying about the specific implementation of product objects. On the other hand, the system can be flexibly scalable.

Abstract class ballfactory {<br/> protected abstract ball makeball (); // factory method <br/>}< br/> class basketballfact extends ballfactory {<br/> Public ball makeball () {// The Factory method of the subclass determines which class to instantiate <br/> return new basketball (); <br/>}< br/> class footballfact extends ballfactory {<br/> Public ball makeball () {// The Factory method of the subclass determines which class to instantiate <br/> return new football (); <br/>}< br/> class basketball extends ball {<br/> Public void play () {<br/> system. out. println ("Play the basketball"); <br/>}< br/> class football extends ball {<br/> Public void play () {<br/> system. out. println ("Play the football"); <br/>}< br/> abstract class ball {<br/> protected abstract void play (); <br/>}< br/> public class test {<br/> Public static void main (string [] ARGs) {<br/> ballfactory = new basketballfact (); <br/> ball basketball = ballfactory. makeball (); <br/> basketball. play (); <br/> ballfactory = new footballfact (); <br/> ball football = ballfactory. makeball (); <br/> football. play (); <br/>}< br/>}