《Android之大话设计模式》--设计模式 建立型模式 第一章:简单工厂模式

《Android之大话设计模式》--设计模式 建立型模式 第一章:简单工厂模式

简单工厂模式 ⼀见钟情的代价 
简单工厂模式应用场景举例: 
       “你知不知道大学的规矩啊?”,MM有些不满的问道。“什么规矩?固然不知道了啊。”,GG傻
傻的说道,很明显这个MM已经对GG的不懂事和不主动有些不满了。“在大学里,当两我的肯定恋
爱关系时,都是要请女友同寝室的人去吃饭的”,MM带着⼀些不满又有⼀些撒娇的口气说道。
“啊?我不知道哎,请众美女吃饭我还梦寐以求呢,何时有时间啊,肯定是时间和地点,我随
叫随到!”GG很激动很爽快的答应道。MM笑着抬头看了⼀样这个傻GG,“那好,让我想一想,咱们…
咱们下周六下午有时间,要么这样,你带咱们去麦当劳吧”,“⼀言为定”,“那咱们在下周六下午五
点在中心商业街南边的麦当劳分店见,据说那边的口味还不错:-O”,“好的,只要你开心就好,不
见不散”GG回答道,“不见不散!”MM就这样嫣然⼀笑的欢天喜地的离开了。
       想一想前几天GG和MM由于很是偶然的因素相见的情景,GG再次涌起了⼀种没法言喻的幸福和
激动。那⼀天,GG见到了MM,仿若晴天霹雳,整个地球在颤抖,她甜美而柔和的声音、她极具
古典气息的是秀发、她超棒的身材、她恰到好处的着装、她极尽秀美而恬静的娇容、她似音乐般
的举止顿时令他完全的迷醉了,仿佛整个世界只有她⼀人,仿佛⼀切都是为她而生的,忽然,两
人目光交错,眼神相遇…就这么⼀见钟情!GG想,到麦当劳也好,反正我不会作饭,再说了,即
使会作也不能去作啊,众口难调啊,更况且是⼀群美女,到麦当劳让她们自个儿去挑吧^_^不过我
这⼀个月的生活费怕是要泡汤了,难怪别人说大学里最高的消费是花费的女友身上的消
费~~~~(>_<)~~~~
       千呼万唤,终于到了周六下午。被感情冲昏大脑的GG忽然间变的再也不那么笨了,此次他提早
预约了座位,是⼀个能够容纳8我的的座位。并且具体告诉了MM座位的位置,这样你们都清楚位
置是比较好的,避免了到时候没有位置的尴尬。赶往麦当劳路上的GG心潮澎湃可是有些担忧,毕
竟要面对六个美女,并且女友也是刚认识几天。“亲爱的,如今到哪了?”手机中MM发过来了⼀
条短信,GG⼀看时间,天啊,光顾着去傻想,还有几分钟就五点了,第⼀次若是都迟到那就太不
好了,因而当即回复到,“宝贝儿,我就到了!”,由于麦当劳就在对面,抬头就能够看到的。GG
跑上了麦当劳的二楼的用餐处,见到诸位美女,紧张的还没说不话来,“这是我男友”MM拽着GG
的手臂说,“你们好,你们好”,GG紧张的说道。忙又补充到:“咱们先点餐,你们自便,都不要客
气啊”,“我要吃鸡翅”,“我要麦香鱼套餐”,我要“板烧鸡腿套餐”,我要“奶昔”,我要“薯条”,…,大
家都点好本身的喜欢的食品,而后GG和MM分别又加了几份食品,有GG把订单拿到前台交给了服
务员,服务员清算了⼀下全部花费,GG立即晕倒^_^。看来⼀个月的生活费是确实的泡汤了,不
过仍是故做振做,微笑着来到众美女中,和众美女坐在那里等着慢慢享用美食,而剩下的⼀切就
交给服务员了…
简单工厂模式解释: 
       简单工厂模式(Simple Factory Pattern)属于类的创新型模式,又叫静态工厂方法模
式(Static FactoryMethod Pattern),是经过专门定义⼀个类来负责建立其余类的实例,被建立的

实例一般都具备共同的父类。 sql

简单工厂模式的UML图: 
       简单工厂模式中包含的角色及其相应的职责以下:
       工厂角色(Creator):这是简单工厂模式的核心,由它负责建立全部的类的内部逻辑。固然
工厂类必须可以被外界调用,建立所须要的产品对象。
       抽象(Product)产品角色:简单工厂模式所建立的全部对象的父类,注意,这里的父类能够
是接口也能够是抽象类,它负责描述全部实例所共有的公共接口。
       具体产品(Concrete Product)角色:简单工厂所建立的具体实例对象,这些具体的产品每每
都拥有共同的父类。
简单工厂模式深刻分析:
       简单工厂模式解决的问题是如何去实例化⼀个合适的对象。
       简单工厂模式的核心思想就是:有⼀个专门的类来负责建立实例的过程。
       具体来讲,把产品看着是⼀系列的类的集合,这些类是由某个抽象类或者接口派生出来的⼀个
对象树。而工厂类用来产生⼀个合适的对象来知足客户的要求。
       若是简单工厂模式所涉及到的具体产品之间没有共同的逻辑,那么咱们就可使用接口来扮演
抽象产品的角色;若是具体产品之间有功能的逻辑或,咱们就必须把这些共同的东西提取出来,
放在⼀个抽象类中,而后让具体产品继承抽象类。为实现更好复用的目的,共同的东西老是应该
抽象出来的。

       在实际的的使用中,抽闲产品和具体产品之间每每是多层次的产品结构,以下图所示: 数据库

简单工厂模式使用场景分析及代码实现: 
       GG请本身的女友和众多美女吃饭,可是GG本身是不会作饭的或者作的饭很很差,这说
明GG不用本身去建立各类食物的对象;各个美女都有各自的爱好,到麦当劳后她们喜欢吃什么直
接去点就好了,麦当劳就是生产各类食物的工厂,这时候GG不用本身动手,也能够请这么多美女

吃饭,所要作的就是买单O(∩_∩)O哈哈~,其UML图以下所示: 编程

       实现代码以下:
       新创建⼀个食物的接口:
package com.diermeng.designPattern.SimpleFactory;
 
/*
 * 产品的抽象接口
 */
public interface Food {
    /*
     * 得到相应的食物
     */
    public void get();
}
接下来创建具体的产品:麦香鸡和薯条
package com.diermeng.designPattern.SimpleFactory.impl;
import com.diermeng.designPattern.SimpleFactory.Food;
 
/*
 * 麦香鸡对抽象产品接口的实现
 */
public class McChicken implements Food{
    /*
     * 获取⼀份麦香鸡
     */
    public void get(){
        System.out.println("我要⼀份麦香鸡");
    }
}
package com.diermeng.designPattern.SimpleFactory.impl;
import com.diermeng.designPattern.SimpleFactory.Food;
 
/*
 * 薯条对抽象产品接口的实现
 */
public class Chips implements Food{
    /*
     * 获取⼀份薯条
     */
    public void get(){
        System.out.println("我要⼀份薯条");
    }
}
如今创建⼀个食物加工工厂:
package com.diermeng.designPattern.SimpleFactory.impl;
import com.diermeng.designPattern.SimpleFactory.Food;
 
 
public class FoodFactory {
 
    public static Food getFood(String type) throws InstantiationException,
IllegalAccessException, ClassNotFoundException {
        if(type.equalsIgnoreCase("mcchicken")) {
            return McChicken.class.newInstance();
 
        } else if(type.equalsIgnoreCase("chips")) {
            return Chips.class.newInstance();
        } else {
            System.out.println("哎呀!找不到相应的实例化类啦!");
            return null;
        }
 
 
    }
}
最后咱们创建测试客户端:
package com.diermeng.designPattern.SimpleFactory.client;
import com.diermeng.designPattern.SimpleFactory.Food;
import com.diermeng.designPattern.SimpleFactory.impl.FoodFactory;
 
/*
 * 测试客户端
 */
public class SimpleFactoryTest {
    public static void main(String[] args) throws InstantiationException,
IllegalAccessException, ClassNotFoundException {
 
        //实例化各类食物
        Food mcChicken = FoodFactory.getFood("McChicken");
        Food chips = FoodFactory.getFood("Chips");
        Food eggs = FoodFactory.getFood("Eggs");
 
        //获取食物
        if(mcChicken!=null){
            mcChicken.get();
        }
        if(chips!=null){
            chips.get();
        }
        if(eggs!=null){
            eggs.get();
        }
 
 
    }
}
输出的结果以下:
哎呀!找不到相应的实例化类啦!
我要⼀份麦香鸡
我要⼀份薯条
简单工厂模式的优缺点分析: 
       优势:工厂类是整个模式的关键所在。它包含必要的判断逻辑,可以根据外界给定的信息,决
定究竟应该建立哪一个具体类的对象。用户在使用时能够直接根据工厂类去建立所需的实例,而无
需了解这些对象是如何建立以及如何组织的。有利于整个软件体系结构的优化。
      缺点:因为工厂类集中了全部实例的建立逻辑,这就直接致使⼀旦这个工厂出了问题,全部的
客户端都会受到牵连;并且因为简单工厂模式的产品室基于⼀个共同的抽象类或者接口,这样
⼀来,但产品的种类增长的时候,即有不一样的产品接口或者抽象类的时候,工厂类就须要判断何
时建立何种种类的产品,这就和建立何种种类产品的产品相互混淆在了⼀起,违背了单⼀职责,
致使系统丧失灵活性和可维护性。并且更重要的是,简单工厂模式违背了“开放封闭原则”,就是违
背了“系统对扩展开放,对修改关闭”的原则,由于当我新增长⼀个产品的时候必须修改工厂类,相
应的工厂类就须要从新编译⼀遍。
      总结⼀下:简单工厂模式分离产品的建立者和消费者,有利于软件系统结构的优化;可是因为
⼀切逻辑都集中在⼀个工厂类中,致使了没有很高的内聚性,同时也违背了“开放封闭原则”。另外
,简单工厂模式的方法⼀般都是静态的,而静态工厂方法是没法让子类继承的,所以,简单工厂
模式没法造成基于基类的继承树结构。
简单工厂模式的实际应用简介: 
       做为⼀个最基本和最简单的设计模式,简单工厂模式却有很很是普遍的应用,咱们这里
以Java中的JDBC操做数据库为例来讲明。
        JDBC是SUN公司提供的⼀套数据库编程接口API,它利用Java语言提供简单、⼀致的方式来
访问各类关系型数据库。Java程序经过JDBC能够执行SQL语句,对获取的数据进行处理,并将变
化了的数据存回数据库,所以,JDBC是Java应用程序与各类关系数据进行对话的⼀种机制。
用JDBC进行数据库访问时,要使用数据库厂商提供的驱动程序接口与数据库管理系统进行数据

交互。 设计模式

客户端要使用使用数据时,只须要和工厂进行交互便可,这就致使操做步骤获得极大的简化,操 做步骤按照顺序依次为:注册并加载数据库驱动,⼀般使用Class.forName();建立与数据库的链 接Connection对象;建立SQL语句对象preparedStatement(sql);提交SQL语句,根据实际状况使 用executeQuery()或者executeUpdate();显示相应的结果;关闭数据库。 舒适提示:         严格意义上讲,简单工厂模式并不算是⼀种设计模式,简单工厂模式更像是⼀种编程习惯,而 这被普遍的应用。可是由于简单工厂模式在“高内聚”方面的欠缺,同时更致命的是违背了严格意义 上的“开放封闭原则”,或者说只对“开放封闭原则”提供某种程度上的支持,这就使得每次新增长⼀ 个产品的时候是很是麻烦的,由于每当增长⼀种新的产品的时候,工厂角色必须知道这个产品, 同时必须知道如何建立这个产品,还要以⼀种对客户端有好的方式提供给客户端使用。简而言之 ,就是每增长⼀个新的产品就必须修改工厂角色的源代码。因此简单工厂模式是不利于构建容易 发生变化的系统的。而“需求老是在变化”,“世界上没有⼀个软件是不变的”。因此使用简单工厂模 式的时候必须慎重考虑。 注意:该文档参考和使用了网络上的免费开放的图片和内容,并以避免费开放的方式发布,但愿为移 动互联网和智能手机时代贡献绵薄之力!能够随意转载,但不得使用该文档谋利。
相关文章
相关标签/搜索