A股上市公司传智教育(股票代码 003032)旗下技术交流社区北京昌平校区

 找回密码
 加入黑马

QQ登录

只需一步,快速开始

© 严明 初级黑马   /  2012-6-25 18:35  /  1736 人查看  /  2 人回复  /   0 人收藏 转载请遵从CC协议 禁止商业使用本文

一直以为涉及到什么"模式"的都是很高深,很难理解的,其实只是我们心里害怕而已,只要去了解,也不过如此!
工厂模式:用一个小示例解释:

public abstract class Product //建一个抽象类,描述产品的
{

}

public class ConcreteProductA extends Product   //产品A继承Product
{

}


public class ConcreteProductB extends Product   //来个产品B
{

}

public class Creator    //一个工厂按客户要求制造产品,由客户传入参数str
{
        public static Product createProduct(String str)
        {
                if("A".equals(str))
                {
                        return new ConcreteProductA();
                }
                else if("B".equals(str))
                {
                        return new ConcreteProductB();
                }
               
                return null;
        }
}



public class Client   //客户调用工厂来生产符合自己要求的产品
{
        public static void main(String[] args)
        {
                Product productA = Creator.createProduct("A");
               
                System.out.println(productA.getClass().getName());
               
                Product productB = Creator.createProduct("B");
               
                System.out.println(productB.getClass().getName());
        }
}



有人会问:为什么这么麻烦呢?为什么不直接  ConcreteProductA  productA= new ConcreteProductA("A"); ConcreteProductB = new ConcreteProductB("B");
这样多省事,

如果创建ConcreteProductA  实例时所做的初始化工作不是像赋值这样简单的事,可能是很长一段代码,如果也写入构造函数中,那代码很难看了,

初始化工作中要做的工作很多,将很多工作装入一个构造方法中,有背于Java面向对象的原则,面向对象的封装(Encapsulation)和分派(Delegation)告诉我们,尽量将长的代码分派“切割”成每段,将每段再“封装”起来(减少段和段之间偶合联系性),这样,就会将风险分散,以后如果需要修改,只要更改每段,不会再发生牵一动百的事情。


在本例中我们将创建实例的工作与使用实例的工作分开了,让创建实例所需要的大量初始化工作从 ConcreteProductA  的构造函数中分离出去。

而且以后还会有产品C 产品D 等等.....这样就有更大的可扩展性和尽量少的修改量












评分

参与人数 1技术分 +1 收起 理由
黄奕豪 + 1 赞一个!

查看全部评分

2 个回复

正序浏览
陈淑飞 发表于 2012-6-25 19:28
谈谈我对工厂模式的理解
优点
此模式捯饬,应该是 对象的使用者,并不需要知道,如何实例化一个类。只需要 ...

例子很恰当
回复 使用道具 举报
谈谈我对工厂模式的理解
优点
此模式捯饬,应该是 对象的使用者,并不需要知道,如何实例化一个类。只需要传一个 参数,告诉它 我需要什么,你给我来什么。
  我不需要了解你,你是怎么创建的,如何去实例化这些细节的。
打个比如:
  我现要打算去,北京黑马去培训,我告诉A工厂,你给我来个拉法利 跑车。我不需要了解它 拉法利跑车是怎么构造的,是不是要四个轮子的,拉风的外形和牛逼的发动机。这些细节让工厂帮你搞定得了。
   我又不想用 拉法利跑车了,我告诉工厂,给我来个吉安特自行车。 我也不需要了解它, 这个自行车是如何构造的,是不是两个轮子。这些我都不关注,我只要我的对象即可。

缺点
但就它的 标准设计模块 靠 if或case 等来判断,这个是 违背了 开放-封闭原则的。 我们的开放-封闭原则,告诉我们,应该对修改关闭,对扩展是开放的。
如果,我某天,突发奇想,告诉工厂,给我来个东风卡车吧。
这时工厂悲剧了,上面代码中,设计创建个新品东风卡车没问题。不会对原有代码修改。
但靠 if或case 来判断,我给它的命令是 东风卡车, 它得去修改 if或case 语句了。此时就不太好了。

牛逼的应该是反射吧,大家以后可以了解下,哪个框架中没有用到反射,呵呵。
回复 使用道具 举报
您需要登录后才可以回帖 登录 | 加入黑马