|
|
从耦合关系谈起
耦合关系直接决定着软件面对变化时的行为
-模块与模块之间的紧耦合使得软件面对变化时，相关模块都要随之更改
-模块与模块之间的松耦合使得软件面对变化时，一些模块更容易被替换或者更改，但其他模块保持不变
抽象部分变化慢，细节（具体）部分变化快；高层部分变化慢，底层部分变化快。
当我们对于系统的认识无法梳理出上面的图时，最好不要一开始就用设计模式，设计模式其实是一个演绎的过程。当我们对软件认识不断深化时，慢慢就会知道哪些是主要的，哪些是次要的，就能梳理出一个抽象和具体的层次，再考虑用哪种设计模式。
第二幅图满足了依赖倒置原则，中间的主线是变化慢的部分，分支都是用接口相连。这样的松耦合使得模块与模块之间的连接用接口连接，接口是相对稳定的部分，接口的实现是相对变化的部分。例如：去帮我买一条毛巾，只告诉了是毛巾这样事物，而毛巾的具体品种、颜色并没有具体的需求。大自然创造的世界，遍地都是松耦合、高内聚。例如屋子里的凳子和桌子、床单和被子等，当我们需要换床单时，是不需要换床的。床和床单之间有一个接口，床是主线，床需要床单的接口，只要具体的床单满足这个尺寸接口，就可以接上。主逻辑的变化成本比辅逻辑的变化成本高，所以尽量让辅逻辑的变化较少的影响主逻辑。因此我们设计软件的原则是，先稳定下接口，再考虑具体实现。
动机（Motivation）
在软件系统张中，经常面临着“某个对象”的创建工作：由于需求的变化，这个对象（的具体实现）经常面临着剧烈的变化，但是它却拥有比较稳定的接口。如何应对这种变化？如何提供一种“封装机制”来隔离出“这个易变对象”的变化，从而保持系统中“其他依赖对象的对象”不随着需求改变而改变？
结构（Structure）
例说Factory Method应用
汽车
汽车测试
但是这种测试只能测试一种Car，如果要测试其他类型的Car，需要修改代码并重新编译。为了应对这种改变，我们需要把Car先变成抽象类。
然后我们在客户程序使用的时候，把所有的Car都换成抽象的AbstractCar，这样客户程序就不需要了解具体测试的是哪个Car了。客户程序如下
但这种代码明显是错误的，抽象类不能直接实例化，因此我们比较好的方法是把抽象的Car传递进来
如果现在我们需要Car的多个实例，那么参数只接收一个抽象的Car就显得不那么适用了。我们可能想到的方法是把传进来的Car做一个浅拷贝Memberwise，但是浅拷贝是一个protected方法，并且不能拷贝引用，但是这也是有办法解决的，这种克隆的做法可以，但是现在我们研究另一种做法。我们希望能有一个创建Car的工厂，这样我们在客户程序就不需要关心Car的实例，只管用这个工厂去创建具体的Car。
Car的具体实现
Car工厂
（纠正：CarFactory类中的CreateCar方法应该返回抽象的AbstractCar类型，CarFactory的类和具体HongqiCarFactory的类在实际中应该放在两个不同的文件夹中）
因为客户程序需要用到CarFactory，所以CarFactory中不应该涉及到Car的具体实现，CarFactory应该是一个抽象的工厂类，因此HongqiCar的工厂需要一个继承自抽象CarFactory的具体工厂。在应用程序调用的时候，传入客户程序的工厂应该是具体的HongqiCarFactory工厂。
当想换具体Car的时候，只需要创建一个新的Car继承自AbstractCar，并新建一个具体CarFactory工厂继承自抽象CarFactory。然后在具体的应用中把具体的Car工厂参数修改即可。当然，完全可以让具体应用的代码也不用修改，把变化转嫁到配置文件中去。
Factory Method模式的几个要点
Factory Method模式主要用于隔离类对象的使用者和具体类型之间的耦合关系。面对一个经常变化的具体类型，紧耦合关系会导致软件的脆弱。
Factory Method模式通过面向对象的手法，将所要创建的具体对象工作延迟到子类，从而实现一种扩展（而非更改）的策略，较好地解决了这种紧耦合关系。
Factory Method模式解决“单个对象”的需求变化；
AbstractFactory模式解决“系列对象”的需求变化；
Builder模式解决“对象部分”的需求变化；
it知识库：C#面向对象设计模式纵横谈：Factory Method 工厂方法模式，转载需保留来源！
郑重声明：本文版权归原作者所有，转载文章仅为传播更多信息之目的，如作者信息标记有误，请第一时间联系我们修改或删除，多谢。
