读《大话设计模式》有感之简单工厂模式

　　现在有这么一个面试题：用一种面向对象的语言实现一个计算器控制台程序。

　　只要是学过写代码的同学都是可以很简单就搞定这么一个程序的，但是，只要能实现的程序就是好程序么？这是不尽然的。这个题中是有陷阱的，为什么它要求要用一种面向对象的语言来实现这么一个程序呢？那么就要你在写程序中体现面向对象的原则。

　　来分析一下，一个计算器的控制台程序，需要几个对象呢？如果就总的来讲，那么就计算器一个对象就好了。但是这样思考就太简单了。其实只要将计算器的前端显示和后台计算分开。分为运算类和客户端类就ok了。

　　试试看呐。



图 1



图 2

　　不知道大家是不是和我写得一样呐，这样写就完全把界面和计算完全分离开了，但是大家有想过一个问题么？就是如果笔者希望给这个计算器增加一个计算平方的功能，那么是不是我们就又要到Calculate类中的case语句进行修改了，对于现在的程序来说，其实并不困难，但是，这样把大部分代码开放给你，代码出错的可能性就会大大提高了。

　　接下来，笔者为大家介绍一个简单的工厂模式。



图 3



图 4



图 5



图 6

　　（图 3）是计算器类的父类，而（图 4）是计算器类的子类，这个子类分别为“加”、“减”、“乘”、“除”类，（图 5）是计算器工厂类。这样如果要再增加一个算法，就只要再建一个类，并且让这个类继承计算器父类，重写getResult方法，并且在计算器工厂类中添加一句case语句就可以了，并不会看到其他算法的计算逻辑。

　　这个是从结构上来看，发现了简单工厂模式的好处，来简单介绍一下简单工厂模式。

　　而简单工厂模式的实质是由一个工厂类根据传入的参数，动态决定应该创建哪一个产品类（这些产品类继承自一个父类或接口）的实例。

　　简单工厂模式的优点是：工厂类是整个模式的关键，包含了必要的逻辑判断，根据外界给定的信息，决定究竟应该创建哪个具体类的对象。通过使用工厂类，外界可以从直接创建具体产品对象的尴尬局面摆脱出来，而不必管这些对象究竟如何创建及如何组织的。明确了各自的职责和权利，有利于整个软件体系结构的优化。

　　但是简单工厂模式的缺点也是很明显的。因为在工厂类集中了所有实例的创建逻辑，将全部创建逻辑集中到了一个工厂类中；它所能创建的类只能是事先考虑到的，如果需要添加新的类，则就需要改变工厂类了。那么，当系统中的具体产品类不断增多时候，可能会出现要求工厂类根据不同条件创建不同实例的需求。这种对条件的判断和对具体产品类型的判断交错在一起，很难避免模块功能的蔓延，对系统的维护和扩展非常不利。

　　部分段落摘自《大话设计模式》，谢谢~