软件设计最大的敌人,就是应付需求不断的变化。变化有时候是无穷尽的,于是项目开发就在反复的修改和更新中无限期地延迟交付的日期。变化如悬在头顶的达摩克斯之剑,令许多软件工程专家一筹莫展。正如无法找到解决软件开发的“银弹”,要彻底将变化扼杀在摇篮之中,看来也是不可能完成的任务。那么,积极地面对“变化”,方才是可取的态度。于是,极限编程(XP)的倡导者与布道者Kent Beck提出要“拥抱变化”,从软件工程方法的角度,提出了应对“变化”的解决方案。而本文则试图从软件设计方法的角度,来探讨如何在软件设计过程中,解决未来可能的变化,其方法就是——封装变化。    设计模式是“封装变化”方法的最佳阐释。无论是创建型模式、结构型模式还是行为型模式,归根结底都是寻找软件中可能存在的“变化”,然后利用抽象的方式对这些变化进行封装。由于抽象没有具体的实现,就代表了一种无限的可能性,使得其扩展成为了可能。所以,我们在设计之初,除了要实现需求所设定的用例之外,还需要标定可能或已经存在的“变化”之处。封装变化,最重要的一点就是发现变化,或者说是寻找变化。     GOF对设计模式的分类,已经彰显了“封装变化”的内涵与精髓。创建型模式的目的就是封装对象创建的变化。例如Factory Method模式和Abstract Factory模式,建立了专门的抽象的工厂类,以此来封装未来对象的创建所引起的可能变化。而Builder模式则是对对象内部的创建进行封装,由于细节对抽象的可替换性,使得将来面对对象内部创建方式的变化,可以灵活的进行扩展或替换。    至于结构型模式,它关注的是对象之间组合的方式。本质上说,如果对象结构可能存在变化,主要在于其依赖关系的改变。当然对于结构型模式来说,处理变化的方式不仅仅是封装与抽象那么简单,还要合理地利用继承与聚合的方法,灵活地表达对象之间的依赖关系。例如Decorator模式,描述的就是对象间可能存在的多种组合方式,这种组合方式是一种装饰者与被装饰者之间的关系,因此封装这种组合方式,抽象出专门的装饰对象显然正是“封装变化”的体现。同样地,Bridge模式封装的则是对象实现的依赖关系,而Composite模式所要解决的则是对象间存在的递归关系。    行为型模式关注的是对象的行为。行为型模式需要做的是对变化的行为进行抽象,通过封装以达到整个架构的可扩展性。例如策略模式,就是将可能存在变化的策略或算法抽象为一个独立的接口或抽象类,以实现策略扩展的目的。Command模式、State模式、Vistor模式、Iterator模式概莫如是。或者封装一个请求(Command模式),或者封装一种状态(State模式),或者封装“访问”的方式(Visitor模式),或者封装“遍历”算法(Iterator模式)。而这些所要封装的行为,恰恰是软件架构中最不稳定的部分,其扩展的可能性也最大。将这些行为封装起来,利用抽象的特性,就提供了扩展的可能。   利用设计模式,通过封装变化的方法,可以最大限度的保证软件的可扩展性。面对纷繁复杂的需求变化,虽然不可能完全解决因为变化带来的可怕梦魇,然而,如能在设计之初预见某些变化,仍有可能在一定程度上避免未来存在的变化为软件架构带来的灾难性伤害。从此点看,虽然没有“银弹”,但从软件设计方法的角度来看,设计模式也是一枚不错的“铜弹”了。

解决方案 »

  1.   

    不是为了节省内存。是要求,完全可以用Static来替代单例,但是Static是不安全的
      

  2.   

    现在,可复用面向对象软件系统现在一般划分为三大类:应用程序工具箱和框架(Framework),我们平时开发的具体软件都是应用程序;Java的API属于工具箱;而框架是构成一类特定软件可复用设计的一组相互协作的类。EJB(EnterpriseJavaBeans)是Java应用于企业计算的框架.      框架通常定义了应用体系的整体结构类和对象的关系等等设计参数,以便于具体应用实现者能集中精力于应用本身的特定细节。框架主要记录软件应用中共同的设计决策,框架强调设计复用,因此框架设计中必然要使用设计模式.      另外,设计模式有助于对框架结构的理解,成熟的框架通常使用了多种设计模式,如果你熟悉这些设计模式,毫无疑问,你将迅速掌握框架的结构,我们一般开发者如果突然接触EJBJ2EE等框架,会觉得特别难学,难掌握,那么转而先掌握设计模式
      

  3.   


    singleton跟静态类没有直接关系吧?怎么从你的语气你静态类=singleton
      

  4.   

    不要懂很多,  单例模式, 工厂模式, 观察者模式这几个常用的知道就行了.附单例模式:
    /*
     * 
     * 通常我们可以让一个全局变量使得一个对象被访问, 但它不能防止你实例化多个对象. 一个最好的办法就是:让类自身负责保存它的
     * 唯一实例. 这个类可以保证没有其他实例可以被创建, 并且它可以提供一个访问该实例的方法.
     * 
     * 单例模式因为Singleton类封闭它的唯一实例, 这样它可以以严格地控制客户怎样访问它以及何时访问它. 简单地说就是对唯一实例
     * 的受控访问.
     * 
     */using System;
    using System.Collections.Generic;class SingletonModel
    {
        public static void Main()
        {
            Singleton s1 = Singleton.GetInstance();
            Singleton s2 = Singleton.GetInstance();        if (s1 == s2)
            {
                Console.WriteLine("两个对象是相同的实例.");
            }
            
            Console.ReadKey();
        }
    }class Singleton
    {
        private static Singleton instance;
        private Singleton()
        {
        }    public static Singleton GetInstance()       //此方法是获得本类实例的唯一全局访问点
        {
            if (instance == null)                   //若实例不存在, 则New一个新实例, 否则返回已有的实例
            {
                instance = new Singleton();
            }
            return instance;
        }
    }
    以上代码摘自 大话设计模式, 如果你想有更多的了解, 下载一本电子书看看就行了.
      

  5.   

    最简单的singleton模式,李建中的“C#面向对象设计模式纵横谈”视频教程里提到的class Singleton
    {
        public static readonly Singleton Instance = new Singleton();    private Singleton
        {}
    }
      

  6.   

    我用过三层框架的工厂模式,看来,我也接触了点.BLL,DAL,IBLL,IDAL,BLLFactory,DALFactory
    学习
      

  7.   

    由于“NIO socket”的实现主体上一般为一个线性的处理过程。 所以只适合做 “请求 —— 响应 ”式的网络连接。 也就是说客户端必须向服务器发送一个请求, 服务器才能响应给客户端数据。这种场景比较典型就是web服务器。