zoukankan      html  css  js  c++  java
  • 工厂方法模式1

      做Java一晃就十年了,最近手痒痒,也决定跟随一下潮流,整个博客,写点东西,就算对自己的知识进行一个梳理和总结,也跟朋友们交流交流,希望能坚持下去。
        先写写设计模式方面的内容吧,就是GoF的23个模式,先从大家最熟悉的工厂方法模式开始,这个最简单,明白的人多,看看是否能写出点跟别人不一样的东西,欢迎大家来热烈讨论,提出建议或意见,并进行批评指正,一概虚心接受,在此先谢过了!
        另外,大家也可以说说最想看到哪个模式,那我就先写它,呵呵,大家感兴趣,我才会有动力写下去!好了,言归正传,Now Go!

    工厂方法模式(Factory Method)

    1  场景问题

    1.1  导出数据的应用框架

            考虑这样一个实际应用:实现一个导出数据的应用框架,来让客户选择数据的导出方式,并真正执行数据导出。
            在一些实际的企业应用中,一个公司的系统往往分散在很多个不同的地方运行,比如各个分公司或者是门市点,公司没有建立全公司专网的实力,但是又不愿意让业务数据实时的在广域网上传递,一个是考虑数据安全的问题,一个是运行速度的问题。
            这种系统通常会有一个折中的方案,那就是各个分公司内运行系统的时候是独立的,是在自己分公司的局域网内运行。然后在每天业务结束的时候,各个分公司会导出自己的业务数据,然后把业务数据打包通过网络传送给总公司,或是专人把数据送到总公司,然后由总公司进行数据导入和核算。
            通常这种系统,在导出数据上,会有一些约定的方式,比如导出成:文本格式、数据库备份形式、Excel格式、Xml格式等等。
            现在就来考虑实现这样一个应用框架。在继续之前,先来了解一些关于框架的知识。

    1.2  框架的基础知识

    (1):框架是什么
            简单点说:框架就是能完成一定功能的半成品软件
            就其本质而言,框架是一个软件,而且是一个半成品的软件。所谓半成品,就是还不能完全实现用户需要的功能,框架只是实现用户需要的功能的一部分,还需要进一步加工,才能成为一个满足用户需要的、完整的软件。因此框架级的软件,它的主要客户是开发人员,而不是最终用户。
            有些朋友会想,既然框架只是个半成品,那何必要去学习和使用框架呢?学习成本也不算小,那就是因为框架能完成一定的功能,也就是这“框架已经完成的一定的功能”在吸引着开发人员,让大家投入去学习和使用框架。


    (2):框架能干什么
            能完成一定功能,加快应用开发进度
            由于框架完成了一定的功能,而且通常是一些基础的、有难度的、通用的功能,这就避免我们在应用开发的时候完全从头开始,而是在框架已有的功能之上继续开发,也就是说会复用框架的功能,从而加快应用的开发进度。
            给我们一个精良的程序架构
            框架定义了应用的整体结构,包括类和对象的分割,各部分的主要责任,类和对象怎么协作,以及控制流程等等。
    现在Java界大多数流行的框架,大都出自大师手笔,设计都很精良。基于这样的框架来开发,一般会遵循框架已经规划好的结构来进行开发,从而让我们开发的应用程序的结构也相对变得精良了。


    (3):对框架的理解
            基于框架来开发,事情还是那些事情,只是看谁做的问题
            对于应用程序和框架的关系,可以用一个图来简单描述一下,如图1所示:

     

     图1  应用程序和框架的简单关系示意图

            如果没有框架,那么客户要求的所有功能都由开发人员自己来开发,没问题,同样可以实现用户要求的功能,只是开发人员的工作多点。
            如果有了框架,框架本身完成了一定的功能,那么框架已有的功能,开发人员就可以不做了,开发人员只需要完成框架没有的功能,最后同样是完成客户要求的所有功能,但是开发人员的工作就减少了。
            也就是说,基于框架来开发,软件要完成的功能并没有变化,还是客户要求的所有功能,也就是“事情还是那些事情”的意思。但是有了框架过后,框架完成了一部分功能,然后开发人员再完成一部分功能,最后由框架和开发人员合起来完成了整个软件的功能,也就是看这些功能“由谁做”的问题。

             基于框架开发,可以不去做框架所做的事情,但是应该明白框架在干什么,以及框架是如何实现相应功能的
            事实上,在实际开发中,应用程序和框架的关系,通常都不会如上面讲述的那样,分得那么清楚,更为普遍的是相互交互的,也就是应用程序做一部分工作,然后框架做一部分工作,然后应用程序再做一部分工作,然后框架再做一部分工作,如此交错,最后由应用程序和框架组合起来完成用户的功能要求。
            也用个图来说明,如图2所示:

     

                图2  应用程序和框架的关系示意图


            如果把这个由应用程序和框架组合在一起构成的矩形,当作最后完成的软件。试想一下,如果你不懂框架在干什么的话,相当于框架对你来讲是个黑盒,也就是相当于在上面图2中,去掉框架的两块,会发现什么?没错,剩下的应用程序是支离破碎的,是相互分隔开来的。
            这会导致一个非常致命的问题,整个应用是如何运转起来的,你是不清楚的,也就是说对你而言,项目已经失控了,从项目管理的角度来讲,这是很危险的。
            因此,在基于框架开发的时候,虽然我们可以不去做框架所做的事情,但是应该搞明白框架在干什么,如果条件许可的话,还应该搞清楚框架是如何实现相应功能的,至少应该把大致的实现思路和实现步骤搞清楚,这样我们才能整体的掌控整个项目,才能尽量减少出现项目失控的情况。


    (4):框架和设计模式的关系
            设计模式比框架更抽象
           框架已经是实现出来的软件了,虽然只是个半成品的软件,但毕竟是已经实现出来的了。而设计模式的重心还在于解决问题的方案上,也就是还停留在思想的层面。因此设计模式比框架更为抽象。
          

           设计模式是比框架更小的体系结构元素
           如上所述,框架是已经实现出来的软件,并实现了一系列的功能,因此一个框架,通常会包含多个设计模式的应用。

            框架比设计模式更加特例化
           框架是完成一定功能的半成品软件,也就是说,框架的目的很明确,就是要解决某一个领域的某些问题,那是很具体的功能,不同的领域实现出来的框架是不一样的。
          而设计模式还停留在思想的层面,在不同的领域都可以应用,只要相应的问题适合用某个设计模式来解决。因此框架总是针对特定领域的,而设计模式更加注重从思想上,从方法上来解决问题,更加通用化。

    1.3  有何问题
           分析上面要实现的应用框架,不管用户选择什么样的导出格式,最后导出的都是一个文件,而且系统并不知道究竟要导出成为什么样的文件,因此应该有一个统一的接口,来描述系统最后生成的对象,并操作输出的文件。
           先把导出的文件对象的接口定义出来,示例代码如下: 

    /**

     * 导出的文件对象的接口

     */

    public interface ExportFileApi {

        /**

         * 导出内容成为文件

         * @param data 示意:需要保存的数据

         * @return 是否导出成功

         */

        public boolean export(String data);

    }

            对于实现导出数据的业务功能对象,它应该根据需要来创建相应的ExportFileApi的实现对象,因为特定的ExportFileApi的实现是与具体的业务相关的。但是对于实现导出数据的业务功能对象而言,它并不知道应该创建哪一个ExportFileApi的实现对象,也不知道如何创建。
            也就是说:对于实现导出数据的业务功能对象,它需要创建ExportFileApi的具体实例对象,但是它只知道ExportFileApi接口,而不知道其具体的实现。那该怎么办呢?

     

  • 相关阅读:
    SQLMAP注入教程-11种常见SQLMAP使用方法详解
    VS2012/2013/2015/Visual Studio 2017 关闭单击文件进行预览的功能
    解决 IIS 反向代理ARR URLREWRITE 设置后,不能跨域跳转 return Redirect 问题
    Spring Data JPA one to one 共享主键关联
    JHipster 问题集中
    Spring Data JPA 定义超类
    Spring Data JPA查询关联数据
    maven命名
    maven仓库
    Jackson读取列表
  • 原文地址:https://www.cnblogs.com/Leo_wl/p/1759912.html
Copyright © 2011-2022 走看看