• 适用场景：

代码中经常会出现：根据条件创建实现了同一个接口的不用类实例，而这些判定条件可能随时变动，导致我们这个不得不去改动很多代码。

备注：工厂方法在Head First中，被认为不是设计模式的一种，但人们经常使用，大家习惯性的叫，久了也就言传为“工厂方法模式”。

• 解决了什么问题

例如：

string dbName=string.Empty;            dbName="Access";            MemberDaoBase memberDao=null;                        if(dbName.ToUpper()=="ACCESS"){                memberDao=new Access.MemberDao();            }            else if(dbName.ToUpper()=="SQLSERVER")            {                memberDao=new SqlServer.MemberDao();            }            memberDao.Create(new Member());            memberDao.Modify(new Member());            memberDao.Remove(0);            

如果代码中不再变动还好，但这种情况很多时候是不存在的，当来了一个新的领导，领导说Sqlite的性能好，而且免费，那你就不得不去重新去写一个Sqlite.MemberDao,之后再在这里的判断条件中添加上

1 else if(dbName.ToUpper()=="SQLITE")2 {3       memberDao=new SqlServer.SqliteDao();4 }

当某天另外一个领导说我们不再支持SqlServer了，我们就不得不把else if(dbName.ToUpper()=="SQLSERVER") {...} 这块代码给注释了。我们就痛苦在这种“变动”中。

问题分析：

不稳定部分：

 1 string dbName=string.Empty; 2             dbName="Access"; 3             MemberDaoBase memberDao=null; 4              5             if(dbName.ToUpper()=="ACCESS"){ 6                 memberDao=new Access.MemberDao(); 7             } 8             else if(dbName.ToUpper()=="SQLSERVER") 9             {10                 memberDao=new SqlServer.MemberDao();11             }

稳定部分：

 

1 memberDao.Create(new Member());2 3 memberDao.Modify(new Member());4 5 memberDao.Remove(0);

 

如果我们将不稳定的部分给交给两外一个类单独管理，就能把这种耦合变得低一点，当我们需要“变动”时，只用去关系这个管理类；而这管理来是用来new 实例的，我们习惯。

“扩展” 类：

（Factory method）工厂方法设计模式