工厂模式
问题描述:披萨种类太多,我不想一个个判断
披萨店新推出了点单系统,披萨需要通过不同的制作,相同的烘焙,裁剪等工序才能完成。披萨的种类实在太多了,在构造披萨实例时,光是if else 语句就长的可怕,修改与维护更令人头疼。
问题分析:我就是个买披萨的,管他是怎么做的
披萨子类继承实现相同的基类,通过基类调用不同的子类,使得代码具有一定的弹性,将构造子类放入业务代码,导致了子类与业务代码的耦合,令修改与更新变得更加困难。
解决方法–简单工厂模式
简单工厂模式可以说不是设计模式,更像一种设计习惯,将经常变化的子类构造封装为一个工厂类,通过工厂类构造披萨子类,但子类变化时只需改变工厂类。
优点: 1、一个调用者想创建一个对象,只要知道其名称就可以了。 2、扩展性高,如果想增加一个产品,只要扩展一个工厂类就可以。 3、屏蔽产品的具体实现,调用者只关心产品的接口。
缺点:每次增加一个产品时,都需要增加一个具体类和对象实现工厂,使得系统中类的个数成倍增加,在一定程度上增加了系统的复杂度,同时也增加了系统具体类的依赖。这并不是什么好事。
涉及的设计原则:
封装变化

问题描述:我想要不同风味的披萨
披萨店越做越大,我们开了许多披萨店,不同地区的披萨店,风味并不相同,每家店都有自己的特色,简单工厂模式不能满足变化的需求了。
问题分析:开多几家工厂
披萨与披萨店的关联,就是产品类与工厂的关联,工厂类决定了产品类型,就像披萨店决定了披萨的风味。
解决方法–工厂模式
定义一个创建对象的接口,让其子类自己决定实例化哪一个工厂类,工厂模式使其创建过程延迟到子类进行。
涉及的设计原则:
依赖倒置原则
高层组件与底层组件都依赖于抽象
问题描述:披萨的原材料,需要匹配
为了保证披萨的味道,必须保证原材料的品质,不同地区采用不同的高品质原材料(因地制宜)。每个披萨店都有自己的一组原材料配置。
问题分析:工厂把相关的原材料都准备好了
工厂类必须通过一个创建一系列相关或相互依赖对象的接口。
解决方法–抽象工厂模式
提供一个创建一系列相关或相互依赖对象的接口,而无需指定它们具体的类。
优点:当一个产品族中的多个对象被设计成一起工作时,它能保证客户端始终只使用同一个产品族中的对象。
缺点:产品族扩展非常困难,要增加一个系列的某一产品,既要在抽象的 Creator 里加代码,又要在具体的里面加代码。