设计模式

设计模式（精选12篇）

设计模式 篇1

摘要：本文针对当前《软件设计模式》课程教学中存在的问题, 提出一种教学设计方法, 并给出了一个教学案例, 最后对提出的教学设计方法进行了分析。

关键词：《软件设计模式》,教学设计,教学案例

《软件设计模式》是一套多数人知晓的、经过分类编目的、被反复使用的代码设计经验的总结。学生感觉这门课程学习起来比较困难。市场上也有一部分教材以生活中的例子或典故为主导, 授课时容易只注重细节, 而很难上升到一定高度, 最终学生只会简单应用, 不会分析, 更不会进行合理的选择。本文主要针对我校学生特点及当前教学中存在的问题, 总结出一个相对合理的教学方法来提高教学效果。

一、教学过程设计

本课程在讲授时采用教材为《Head First设计模式》, 参考教材为《实用软件设计模式教程》、《Java与模式》、《大话设计模式》等。《软件设计模式》课程只有30 (22+8) 学时, 要对本课程中各个具体的设计模式都一一介绍是不现实, 也是不可能的。在制定教学大纲时, 充分考虑到了学时、办学定位、学生特点等方面, 选取了其中12个设计模式作为课堂教学的内容。选取标准主要为: (1) 在以后工作中常用的模式。 (2) 在模式分类中具有典型代表的模式。结合传统的教学方法, 在讲授本课程时使用了以下教学过程设计。

1. 给出场景。即提出一个与本次课程要讲授的设计模式相关的设计问题。这一步选取场景时要注意, 此场景必须是学生们比较感兴趣的、熟悉的, 且学生能够依据此场景给出一个合理的设计方案。

2. 场景分析。引导学生思考, 给出此场景的设计方案, 针对其中存在的问题, 依据设计原则进行一步一步的“优化”, 最后得出良好的设计方案。

3. 讲授该设计模式中体现的设计原则。由于每个设计模式中体现的设计原则不同, 并且同一个设计原则会在不同的设计模式中体现, 所以此处的讲解关键在于设计原则的内涵及其使用。

4. 引出欲讲授的设计模式的定义、意图、结构图、适用场景、优缺点、效果分析等, 并用代码演示第一步提出的场景。

5. 课堂练习。针对刚才的讲解, 再给出1~3个不同的场景, 让学生当堂给出其设计方案。

6. 布置作业。此作业为课外作业, 要求学生给出完整的设计及代码。

二、教学案例

观察者模式 (又称发布/订阅模式) 是软件设计模式的一种。观察者模式定义了对象间的一对多的依赖关系, 当一方的对象改变状态时, 所有的依赖者都会被通知并自动被更新。此种模式通常被用来实现事件处理系统。下面以该设计模式的教学为例, 阐述前面的教学过程设计。

1. 提出场景——报纸订阅系统。

报社出版报纸, 客户可随时向报社订阅或取消订阅报纸, 即只要报社在运营, 就会一直有人 (或单位) 向它们订阅或取消订阅报纸。当报社有新报纸时, 就会给处于订阅状态的客户送去。如果你取消了订阅, 则将收不到新的报纸。

2. 场景分析。

引导学生一起分析得出, 该场景中主要涉及到的“角色”有:报社、报纸、客户 (包括人或单位) 。行为方式有: (报社) 出版 (报纸) 、 (客户) 订阅 (报纸) 、 (客户) 取消订阅 (报纸) 。根据课堂提问及学生上课反馈情况给出其初始设计方案, 如图1所示:

在初始设计方案的基础上, 引导学生进一步分析, 当报社有新的报纸出现时, 会送到客户手中, 说明客户是受到报社的影响的;并且客户向报社订阅或取消订阅报纸, 其数据应放在报社方, 即报社方要清楚当有报纸出版时, 应发送给谁。为使此设计方案更有弹性, 即当出现新的客户向报社订阅报纸或客户欲向新的报社申请订阅时, 我们不影响到对方且不用修改代码, 这就是说要“针对抽象编程”, 如何完善已有的设计方案?也就是说我们要给报社及客户提供一个“抽象”概念。具体见图2:

3. 总结模式要点。

观察者定义了对象之间一对多的关系, 主题用一个共同的接口来更新观察者, 观察者和被观察者之间用松耦合方式结合, 可观察者不知道观察者的细节, 只知道观察者实现了观察者接口。使用此模式, 可以从可观察者推或者拉数据, 有多个观察者时, 不可以依赖特定的通知次序。

4. 体现的设计原则。

观察者设计模式中出现体现的设计原则中“针对抽象编程”、“多用组合, 少用继承”、“里氏替换原则”、“为交互对象之间的松耦合而努力”等。在课堂上对前面未讲过的设计原则再进行详述。

5. 课堂练习。

气象站 (教材上的例子) :关键是抽象出主题和观察者;图形显示系统。

6. 作业布置——班会通知。

设计模式:班长临时通知大家一件事, 辅导员有事, 班会取消。当大家听到这个消息的时候, 不再去教室开会, 而是各忙各的事。

三、教学分析

从学生提交的作业、课下学生反馈及期末考核等多方面来看, 本课程的教学设计基本上能达到预期的目标。但存在问题有:学生水平参差不齐, 有一部分学生并没有完全理解设计模式的精髓, 只会简单地去“套用”。如观察者模式中, 个别学生并没有完全明白主题和观察者之间的关系, 即观察者的状态是随着主题状态的改变而改变的。所以作业中有的同学只让“班长”充当观察者, 而有的同学仅让“班长”充当主题, 这都是不正确的。作业中的“班长”具有双重身份, 充当“辅导员”的观察者, 而又是班内其他同学的“主题”。

参考文献

[1]徐宏喆，侯迪.实用软件设计模式教程[M].北京:清华大学出版社, 2009.

[2]黄洪.PBL的改进及在“软件设计模式”课程教学中的应用研究[J].计算机教育, 2008, (8) .

设计模式 篇2

Builder模式定义: 将一个复杂对象的构建与它的表示分离,使得同样的构建过程可以创建不同的表示.Builder模式是一步一步创建一个复杂的对象,它允许用户可以只通过指定复杂对象的类型和内容就可以构建它们.用户不知道内部的具体构建细节.Builder模式是非常类似抽象工厂模式,细微的区别大概只有在反复使用中才能体会到.为何使用?

是为了将构建复杂对象的过程和它的部件解耦.注意: 是解耦过程和部件.因为一个复杂的对象,不但有很多大量组成部分,如汽车,有很多部件:车轮 方向盘 发动机还有各种小零件等等,部件很多,但远不止这些,如何将这些部件装配成一辆汽车,这个装配过程也很复杂(需要很好的组装技术),Builder模式就是为了将部件和组装过程分开.如何使用?

首先假设一个复杂对象是由多个部件组成的,Builder模式是把复杂对象的创建和部件的创建分别开来,分别用Builder类和Director类来表示.首先,需要一个接口,它定义如何创建复杂对象的各个部件: public interface Builder {

//创建部件A 比如创建汽车车轮

void buildPartA();

//创建部件B 比如创建汽车方向盘

void buildPartB();

//创建部件C 比如创建汽车发动机

void buildPartC();

//返回最后组装成品结果(返回最后装配好的汽车)

//成品的组装过程不在这里进行,而是转移到下面的Director类中进行.//从而实现了解耦过程和部件

Product getResult();} 用Director构建最后的复杂对象,而在上面Builder接口中封装的是如何创建一个个部件(复杂对象是由这些部件组成的),也就是说Director的内容是如何将部件最后组装成成品: public class Director {

private Builder builder;

public Director(Builder builder){

this.builder = builder;} // 将部件partA partB partC最后组成复杂对象 //这里是将车轮 方向盘和发动机组装成汽车的过程 public void construct(){

builder.buildPartA();

builder.buildPartB();

builder.buildPartC();

} } Builder的具体实现ConcreteBuilder: 通过具体完成接口Builder来构建或装配产品的部件;定义并明确它所要创建的是什么具体东西;提供一个可以重新获取产品的接口: public class ConcreteBuilder implements Builder {

Part partA, partB, partC;public void buildPartA(){

//这里是具体如何构建partA的代码

};public void buildPartB(){

//这里是具体如何构建partB的代码 };public void buildPartC(){

//这里是具体如何构建partB的代码 };public Product getResult(){

//返回最后组装成品结果 };} 复杂对象:产品Product: public interface Product { } 复杂对象的部件: public interface Part { }

我们看看如何调用Builder模式: ConcreteBuilder builder = new ConcreteBuilder();Director director = new Director(builder);

director.construct();Product product = builder.getResult();Builder模式的应用

在Java实际使用中,我们经常用到“池”(Pool)的概念,当资源提供者无法提供足够的资源,并且这些资源需要被很多用户反复共享时,就需要使用池.“池”实际是一段内存,当池中有一些复杂的资源的“断肢”(比如数据库的连接池,也许有时一个连接会中断),如果循环再利用这些“断肢”,将提高内存使用效率,提高池的性能.修改Builder模式中Director类使之能诊断“断肢”断在哪个部件上,再修复这个部件.设计模式之Factory

定义:提供创建对象的接口.为何使用?

工厂模式是我们最常用的模式了,著名的Jive论坛 ,就大量使用了工厂模式，工厂模式在Java程序系统可以说是随处可见。

为什么工厂模式是如此常用？因为工厂模式就相当于创建实例对象的new，我们经常要根据类Class生成实例对象，如A a=new A()工厂模式也是用来创建实例对象的，所以以后new时就要多个心眼，是否可以考虑实用工厂模式，虽然这样做，可能多做一些工作，但会给你系统带来更大的可扩展性和尽量少的修改量。我们以类Sample为例，如果我们要创建Sample的实例对象: Sample sample=new Sample();可是，实际情况是，通常我们都要在创建sample实例时做点初始化的工作,比如赋值 查询数据库等。

首先，我们想到的是，可以使用Sample的构造函数，这样生成实例就写成: Sample sample=new Sample(参数);但是，如果创建sample实例时所做的初始化工作不是象赋值这样简单的事，可能是很长一段代码，如果也写入构造函数中，那你的代码很难看了（就需要Refactor重整）。为什么说代码很难看，初学者可能没有这种感觉，我们分析如下，初始化工作如果是很长一段代码，说明要做的工作很多，将很多工作装入一个方法中，相当于将很多鸡蛋放在一个篮子里，是很危险的，这也是有背于Java面向对象的原则，面向对象的封装(Encapsulation)和分派(Delegation)告诉我们，尽量将长的代码分派“切割”成每段，将每段再“封装”起来(减少段和段之间偶合联系性)，这样，就会将风险分散，以后如果需要修改，只要更改每段，不会再发生牵一动百的事情。

在本例中，首先，我们需要将创建实例的工作与使用实例的工作分开, 也就是说，让创建实例所需要的大量初始化工作从Sample的构造函数中分离出去。

这时我们就需要Factory工厂模式来生成对象了，不能再用上面简单new Sample(参数)。还有,如果Sample有个继承如MySample, 按照面向接口编程,我们需要将Sample抽象成一个接口.现在Sample是接口,有两个子类MySample 和HisSample.我们要实例化他们时,如下: Sample mysample=new MySample();Sample hissample=new HisSample();随着项目的深入,Sample可能还会“生出很多儿子出来”, 那么我们要对这些儿子一个个实例化,更糟糕的是,可能还要对以前的代码进行修改:加入后来生出儿子的实例.这在传统程序中是无法避免的.但如果你一开始就有意识使用了工厂模式,这些麻烦就没有了.工厂方法

你会建立一个专门生产Sample实例的工厂: public class Factory{

public static Sample creator(int which){

//getClass 产生Sample 一般可使用动态类装载装入类。if(which==1)

return new SampleA();else if(which==2)

return new SampleB();

} } 那么在你的程序中,如果要实例化Sample时.就使用 Sample sampleA=Factory.creator(1);这样,在整个就不涉及到Sample的具体子类,达到封装效果,也就减少错误修改的机会,这个原理可以用很通俗的话来比喻:就是具体事情做得越多,越容易范错误.这每个做过具体工作的人都深有体会,相反,官做得越高,说出的话越抽象越笼统,范错误可能性就越少.好象我们从编程序中也能悟出人生道理?呵呵.使用工厂方法 要注意几个角色，首先你要定义产品接口，如上面的Sample,产品接口下有Sample接口的实现类,如SampleA,其次要有一个factory类，用来生成产品Sample，如下图，最右边是生产的对象Sample：

进一步稍微复杂一点，就是在工厂类上进行拓展，工厂类也有继承它的实现类concreteFactory了。抽象工厂

工厂模式中有: 工厂方法(Factory Method)抽象工厂(Abstract Factory).这两个模式区别在于需要创建对象的复杂程度上。如果我们创建对象的方法变得复杂了,如上面工厂方法中是创建一个对象Sample,如果我们还有新的产品接口Sample2.这里假设：Sample有两个concrete类SampleA和SamleB，而Sample2也有两个concrete类Sample2A和SampleB2 那么，我们就将上例中Factory变成抽象类,将共同部分封装在抽象类中,不同部分使用子类实现，下面就是将上例中的Factory拓展成抽象工厂: public abstract class Factory{

public abstract Sample creator();

public abstract Sample2 creator(String name);} public class SimpleFactory extends Factory{

public Sample creator(){

.........return new SampleA } public Sample2 creator(String name){

.........return new Sample2A } } public class BombFactory extends Factory{

public Sample creator(){

......return new SampleB } public Sample2 creator(String name){

......return new Sample2B } }

从上面看到两个工厂各自生产出一套Sample和Sample2,也许你会疑问，为什么我不可以使用两个工厂方法来分别生产Sample和Sample2? 抽象工厂还有另外一个关键要点，是因为 SimpleFactory内，生产Sample和生产Sample2的方法之间有一定联系，所以才要将这两个方法捆绑在一个类中，这个工厂类有其本身特征，也许制造过程是统一的，比如：制造工艺比较简单，所以名称叫SimpleFactory。在实际应用中，工厂方法用得比较多一些，而且是和动态类装入器组合在一起应用，举例

我们以Jive的ForumFactory为例，这个例子在前面的Singleton模式中我们讨论过，现在再讨论其工厂模式: public abstract class ForumFactory {

private static Object initLock = new Object();

private static String className = “com.jivesoftware.forum.database.DbForumFactory”;

private static ForumFactory factory = null;

public static ForumFactory getInstance(Authorization authorization){

//If no valid authorization passed in, return null.if(authorization == null){

return null;

}

//以下使用了Singleton 单态模式

if(factory == null){

synchronized(initLock){

if(factory == null){

......}

}

} try {

//动态转载类

Class c = Class.forName(className);

factory =(ForumFactory)c.newInstance();} catch(Exception e){

return null;}

//Now, 返回 proxy.用来限制授权对forum的访问

return new ForumFactoryProxy(authorization, factory，factory.getPermissions(authorization));

}

//真正创建forum的方法由继承forumfactory的子类去完成.public abstract Forum createForum(String name, String description)

throws UnauthorizedException, ForumAlreadyExistsException;

....}

因为现在的Jive是通过数据库系统存放论坛帖子等内容数据,如果希望更改为通过文件系统实现,这个工厂方法ForumFactory就提供了提供动态接口: private static String className = “com.jivesoftware.forum.database.DbForumFactory”;你可以使用自己开发的创建forum的方法代替com.jivesoftware.forum.database.DbForumFactory就可以.在上面的一段代码中一共用了三种模式,除了工厂模式外,还有Singleton单态模式,以及proxy模式,proxy模式主要用来授权用户对forum的访问,因为访问forum有两种人:一个是注册用户 一个是游客guest,那么那么相应的权限就不一样,而且这个权限是贯穿整个系统的,因此建立一个proxy,类似网关的概念,可以很好的达到这个效果.看看Java宠物店中的CatalogDAOFactory: public class CatalogDAOFactory {

/**

* 本方法制定一个特别的子类来实现DAO模式。

* 具体子类定义是在J2EE的部署描述器中。

*/

public static CatalogDAO getDAO()throws CatalogDAOSysException {

CatalogDAO catDao = null;

try {

InitialContext ic = new InitialContext();//动态装入CATALOG_DAO_CLASS //可以定义自己的CATALOG_DAO_CLASS，从而在无需变更太多代码 //的前提下，完成系统的巨大变更。

String className =(String)ic.lookup(JNDINames.CATALOG_DAO_CLASS);

catDao =(CatalogDAO)Class.forName(className).newInstance();

} catch(NamingException ne){

throw new CatalogDAOSysException(“

CatalogDAOFactory.getDAO: NamingException while

getting DAO type : n” + ne.getMessage());

} catch(Exception se){

throw new CatalogDAOSysException(“

CatalogDAOFactory.getDAO: Exception while getting

DAO type : n” + se.getMessage());

}

return catDao;

} } CatalogDAOFactory是典型的工厂方法，catDao是通过动态类装入器className获得CatalogDAOFactory具体实现子类，这个实现子类在Java宠物店是用来操作catalog数据库，用户可以根据数据库的类型不同，定制自己的具体实现子类，将自己的子类名给与CATALOG_DAO_CLASS变量就可以。

由此可见，工厂方法确实为系统结构提供了非常灵活强大的动态扩展机制，只要我们更换一下具体的工厂方法，系统其他地方无需一点变换，就有可能将系统功能进行改头换面的变化。

设计模式之Prototype(原型)

定义: 用原型实例指定创建对象的种类,并且通过拷贝这些原型创建新的对象.Prototype模式允许一个对象再创建另外一个可定制的对象，根本无需知道任何如何创建的细节,工作原理是:通过将一个原型对象传给那个要发动创建的对象，这个要发动创建的对象通过请求原型对象拷贝它们自己来实施创建。如何使用? 因为Java中的提供clone()方法来实现对象的克隆(具体了解clone()按这里),所以Prototype模式实现一下子变得很简单.以勺子为例：

public abstract class AbstractSpoon implements Cloneable {

String spoonName;

public void setSpoonName(String spoonName){this.spoonName = spoonName;}

public String getSpoonName(){return this.spoonName;}

public Object clone()

{

Object object = null;

try {

object = super.clone();

} catch(CloneNotSupportedException exception){

System.err.println(“AbstractSpoon is not Cloneable”);

}

return object;

} } 有两个具体实现(ConcretePrototype): public class SoupSpoon extends AbstractSpoon {

public SoupSpoon()

{

setSpoonName(“Soup Spoon”);

} } public class SaladSpoon extends AbstractSpoon {

public SaladSpoon()

{

setSpoonName(“Salad Spoon”);

} } 调用Prototype模式很简单: AbstractSpoon spoon = new SoupSpoon();AbstractSpoon spoon = new SaladSpoon();当然也可以结合工厂模式来创建AbstractSpoon实例。

在Java中Prototype模式变成clone()方法的使用，由于Java的纯洁的面向对象特性，使得在Java中使用设计模式变得很自然，两者已经几乎是浑然一体了。这反映在很多模式上，如Interator遍历模式。

设计模式之Singleton(单态)

定义: Singleton模式主要作用是保证在Java应用程序中，一个类Class只有一个实例存在。在很多操作中，比如建立目录 数据库连接都需要这样的单线程操作。

还有, singleton能够被状态化;这样，多个单态类在一起就可以作为一个状态仓库一样向外提供服务，比如，你要论坛中的帖子计数器，每次浏览一次需要计数，单态类能否保持住这个计数，并且能synchronize的安全自动加1，如果你要把这个数字永久保存到数据库，你可以在不修改单态接口的情况下方便的做到。

另外方面，Singleton也能够被无状态化。提供工具性质的功能，Singleton模式就为我们提供了这样实现的可能。使用Singleton的好处还在于可以节省内存，因为它限制了实例的个数，有利于Java垃圾回收（garbage collection）。

我们常常看到工厂模式中类装入器(class loader)中也用Singleton模式实现的,因为被装入的类实际也属于资源。如何使用?

一般Singleton模式通常有几种形式: public class Singleton {

private Singleton(){}

//在自己内部定义自己一个实例，是不是很奇怪？

//注意这是private 只供内部调用

private static Singleton instance = new Singleton();

}

第二种形式: public class Singleton {

private static Singleton instance = null;public static synchronized Singleton getInstance(){

//这个方法比上面有所改进，不用每次都进行生成对象，只是第一次

//使用时生成实例，提高了效率！if(instance==null)

instance＝new Singleton();return instance;} //这里提供了一个供外部访问本class的静态方法，可以直接访问

public static Singleton getInstance(){

return instance;

} }

使用Singleton.getInstance()可以访问单态类。

上面第二中形式是lazy initialization，也就是说第一次调用时初始Singleton，以后就不用再生成了。

注意到lazy initialization形式中的synchronized，这个synchronized很重要，如果没有synchronized，那么使用getInstance()是有可能得到多个Singleton实例。关于lazy initialization的Singleton有很多涉及double-checked locking(DCL)的讨论，有兴趣者进一步研究。

一般认为第一种形式要更加安全些。使用Singleton注意事项：

有时在某些情况下，使用Singleton并不能达到Singleton的目的，如有多个Singleton对象同时被不同的类装入器装载；在EJB这样的分布式系统中使用也要注意这种情况，因为EJB是跨服务器，跨JVM的。

我们以SUN公司的宠物店源码(Pet Store 1.3.1)的ServiceLocator为例稍微分析一下：

在Pet Store中ServiceLocator有两种，一个是EJB目录下；一个是WEB目录下，我们检查这两个ServiceLocator会发现内容差不多，都是提供EJB的查询定位服务，可是为什么要分开呢？仔细研究对这两种ServiceLocator才发现区别：在WEB中的ServiceLocator的采取Singleton模式，ServiceLocator属于资源定位，理所当然应该使用Singleton模式。但是在EJB中，Singleton模式已经失去作用，所以ServiceLocator才分成两种，一种面向WEB服务的，一种是面向EJB服务的。

Singleton模式看起来简单，使用方法也很方便，但是真正用好，是非常不容易，需要对Java的类 线程 内存等概念有相当的了解。进一步深入可参考：

动态薪酬激励设计模式 篇3

薪酬激励设计是企业人力资源管理的重要工作，“薪情”会影响“心情”，它的好坏直接影响员工的效率，而直接创造有形价值的销售人员的薪酬激励设计在企业薪酬激励设计工作中更是居重要地位，它将在很大程度上直接影响企业的业绩与未来发展。在现实企业中，销售人员的薪酬设计除具有薪酬激励设计所共有的误区，如内部不公平、外部不公平、脱离企业实际等，相对其他岗位而言，销售人员的薪酬设计更是企业绩效管理中的难点。销售人员薪酬激励设计的误区还具有其独特性的一面。

销售人员薪酬设计中常见的问题

销售人员的薪酬激励设计没有与企业的发展阶段、规模、产品生命周期及企业的经济承受能力相结合：这种薪酬激励设计误区在现实企业中最常见。由于买方市场的形成，销售几乎成为所有面向市场的企业的首要工作。企业为了迅速打开市场，提升销量，往往不顾自身实际情况，以提供具有竞争力的薪酬激励来吸引销售精英。但是，企业往往没有对薪酬总量进行测算，以保证在提供有竞争力的薪酬激励条件的同时，能有充足的资金支撑企业的经营发展。结果使企业背负沉重的人力成本，销售费用所占比例居高不下，失去整个薪酬调整的坚实基础。

销售人员的薪酬激励不具有成本效益性：在任何竞争型企业里，一切与薪酬激励有关的东西首先都是投入，也即成本，既然是投入就要有产出与之匹配，否则就不符合成本效益性原则，对企业来讲是不经济的。销售人员的薪酬激励同样如此，企业在以高价引进销售精英后，因企业或销售人员自己的原因不能换来销售业绩或企业的长远利益，这些薪酬激励投入就是无效投入，不具有成本效益性。

没有将与销售人员相关的隐性报酬与销售人员的整体薪酬激励设计结合起来：销售人员本身的薪酬激励报酬是很容易测算的，但是与之相关的一些隐性报酬多数企业在设计销售人员薪酬激励时却没有详细测算，这些隐性报酬包括除销售人员薪资激励之外的保险、福利、加班费、补助（贴）、津贴等，如果企业不将其纳入薪酬激励设计中综合考虑就可能使企业整体人力成本失控。

在销售人员的薪酬激励构成上，有的企业表现为销售人员薪酬模式的单一与僵化：多数企业经营多年仍是成立时的薪酬模式，不管是高层还是中基层仍是采用月薪制，除此之外，其它与绩效、年资等相关的支出却没有体现出来，固定化与缺乏弹性是企业的通病。

销售人员的薪酬水平与同行、市场价位脱节，失去外部公平性：有的企业对销售人员没有一个科学、合理的调薪政策，为避免调薪所带来的风险（经营业绩不确定风险、调薪负面作用风险等）干脆不调整薪酬，造成工作多年的销售人员仍是入职时的工资，调薪无望。在当前销售精英供不应求的需求形势下，多数销售人员可能就会用跳槽的方式谋求更高的薪水。

奖金固定化，变相成为销售人员薪酬的一部分：这是目前多数企业存在的现状。管理者为激励销售人员，往往会有年终双薪或按等级规定相应的奖金额，由于一直以来都有年终奖，销售人员已将年终奖作为收入的一部分，认为是理所应当。但是，企业经营又存在不确定性，当经营状况不佳时，就陷入了两难境地。发吧，没赚到钱，发奖金就等于额外增加企业负担；不发吧，又担心员工流失。最后的结果往往是将奖金“打折”，“忍痛”拿出企业的营运资金发奖金来稳定军心。这样，一方面因发奖金影响了企业的资金流的正常运转，为企业经营带来潜在风险，另一方面，销售人员又因为拿得比过去少而心理不平衡。结果企业花的钱往往打了水漂，响也不响一声。

根据企业产品的生命周期（企业的发展阶段）设计薪酬是一种有效的模式，虽然不能完全避免上述误区，但只要企业结合所处的行业、规模、产品边际贡献等因素，就可以设计出适应企业实际情况的动态调节的薪酬激励模式。

动态调节的薪酬激励模式

对销售人员的考核应用方式中最直接也是较容易见效的就是与收入分配挂钩，如与薪资、奖金、提成及佣金、股票收益等。对它们采用不同的组合，可起到不同的作用，企业应根据自身所处的行业、企业的发展阶段、规模，企业产品的生命周期、产品边际贡献等设计适应企业实际的薪酬激励模式，以期达到理想效果。具体实施可以分为以下三个阶段：

1．产品刚刚上市，产品没有什么知名度，最好采取固定薪酬模式，或者采取“高固定，低奖金/提成”的模式。因为这个时候，产品销售风险性是很高的，销售人员的努力很可能得不到足够的市场回报，因此，这个时候就不能让销售人员来承担风险，要突出风险共担、利益共享的经营理念，激励销售人员与企业共同成长与发展。

甲企业是一家成立不久的生产、销售汽车清洗用品的民营企业。企业规模较小，整个销售队伍主要以企业销售员为主体，尚无设立驻外分支机构，品牌与销售渠道都尚处于建设状态。企业的任务是尽快让消费者了解自己的产品，为渠道建设提供良好的市场条件。因此，该企业为迅速打开市场，采用了人员促销的方式，快速发展各类代销客户，并与代销客户配合广泛开展促销活动。在对销售人员的薪酬考核方面采用“高基薪低奖金”的方法(见表1)。

2．经过一段时期的努力，产品得到了客户的认可，逐渐在市场上打开了销路，销售的风险程度逐渐降低，销售额处于增加时期，这时，企业就可以适当降低销售人员薪酬中的固定部分，即基本薪酬部分，提高浮动部分，即奖金或提成部分，以鼓励销售人员更为积极地扩大销售份额，以增加企业的销售额。

乙企业是一家成立已有十年的民营高新技术企业，主要设计、研发、生产、销售智能及娱乐玩具，其产品在市场上有一定的品牌优势，销售模式采用代理制。总部成立销售部，统揽国内的销售业务，并基本以各行政区为单位设立销售大区，大区下面又在全国主要城市都设有分企业、办事处，办事处分管若干省份的业务，并直接向销售大区报告。每个办事处配备若干名业务代表，这些业务代表的主要工作是拜访客户，配合客户开展推广活动，传递企业的销售政策与市场信息，沟通信息，增进了解。由此可见，该企业的销售人员主要是推广人员，因此，在薪酬结构上采用“高奖金/提成，低基薪”的薪酬模式，目的是以此稳定营销人员队伍，使企业经营快速平稳发展。以下分别是销售部经理、销售大区经理、办事处主任、业务主办、业务代表的薪资结构（见表2、3）。

3．待产品达到成熟期，产品品牌或企业品牌对于消费者的购买行为产生的作用比销售人员的说服作用更为重要时，就可以将销售人员的薪酬方案仍改为“高固定+低浮动”的薪酬模式。但是这种薪酬方式绝不仅仅是产品刚刚上市时“高固定，低奖金/提成”的简单复制，因为随着企业利润的增加，员工的“胃口”也会越来越大，单一的奖金或是提成显然已经不能让员工“吃饱”。因此，产品成熟期的时候，“高估定，低浮动”的薪酬模式应当具有更多的福利内容：比如效益分红，高级人员可以享受“股票收益”等，以保持对员工持续的激励作用。

丙企业是一家生产家用电器的上市集团企业，家电产品基本都在国内市场名列前茅，企业的商标被国家工商总局认定为“中国驰名商标”，品牌价值经权威机构评估高达百亿元，2002年入选中国十大公众喜爱商标，拥有遍布全国的市场营销网络，并在美国、欧洲、日本、香港、韩国等地设有分支机构。在销售人员的激励方面，高层实行“基本薪资+年终收益”，其中，年终收益包括提留的一定比例的工资、效益分红、超额经营成果贡献、股票收益，基层销售人员实行“基本薪资+年终奖”的薪资模式。中基层销售人员采用“月薪+年终绩效奖+超额奖金”的薪酬模式。下表是该公司销售人员的薪资结构表（见表4）。

设计模式 篇4

由于市场变得越来越活跃,工业机柜产品的寿命周期变得越来越短,其产品的外观造型、材料及其加工的选择越来越复杂和多样化,工业机柜的设计也将承受着前所未有的挑战和冲击。虽然产品设计占产品总成本的比重不到5%,但它却影响产品整体成本的70%以上。如果按照传统的单人单机串行设计,处理任何问题都保持按部就班的方式,那么无论从经济、规模和时间上都制约了设计的发展[1],难以满足社会发展和激烈的市场竞争的需求。

本研究主要介绍工业机柜的设计链协同设计模式研究。

1 传统设计模式的分析

1.1 工业机柜产品的特点

工业机柜主要用于通信系统、电力监控、工业自动化控制等不同领域设备的安装;当然,工业机柜产品还可包括操作台、多媒体讲台、办公设备和一些电子产品的钣金外壳。

相比于其他机械产品,工业机柜产品具有如下特点:

(1) 适应性非常广泛;

(2) 产品的功能结构方面逐渐趋于标准化、系列化;而在产品外观造型方面则不断追求细节创新,越来越强调个性及品牌形象;

(3) 随着板材冲压技术的进步及模具水平、质量的提高,产品越来越精细,造型能力更为丰富;

(4) 由于其加工的特殊性,能在一定程度上灵活适应某些产品的个性化需求;

(5) 由于不是终端用户的独立产品,必然受到客户配套定制的限制,服务配套要求较高;

(6) 工业机柜产品功能结构的设计相对简单。也正因为如此,工业机柜加工企业一般属于中小型企业,产品从设计至产品成型的各职能环节往往由多个中小企业分别承担,所以产品的设计成型过程会涉及到多家企业之间的合作。

1.2 传统工业机柜产品设计模式的优缺点

目前几乎所有产品的设计都源于订单,上游客户的标准和客户的确认从始至终贯穿影响着整个新产品的设计过程。传统的产品设计流程,如图1所示。

传统的产品设计流程属于串行的开发模式,其优点有:

(1) 设计流程层次分明,简单、有序;

(2) 管理方便。

但面对市场竞争日益激烈的现实,传统的串行流程的产品开发模式也表现出了诸多局限性,如:

(1) 客户与企业的地位不平等,企业过分依赖客户的判定和确认;

(2) 由于非钣金件加工企业不参与产品的结构设计,不能很好地实现多专业和优势资源的充分利用;

(3) 钣金企业内部职能分割,在客观上造成新产品开发随意性过大,加大了开发的风险;

(4) 没有统一的工作环境,资料查询和沟通困难;

(5) 缺乏跨平台的产品数据管理工具,对大量的工程图档和产品数据的管理与维护耗费了产品开发人员的大量精力,而且经常由于前后版本不一致而造成无法估量的损失;

(6) 缺少产品开发项目进度控制和工作监控。

这种传统的串行产品设计模式使产品的可制造性、可控制性较差[2],从而导致设计改动量大、产品开发周期长、产品成本高的结果。

2 设计链协同设计模式

随着加工模式由批量生产走向小批量定制,批量与成本之间的矛盾势必加深;同时随着客户个性化需求的提高、产品周期的缩短,新品开发的应变能力要求将越来越高。

基于市场的需求,本研究就工业机柜的设计提出了一种全新的设计模式——设计链协同设计模式。

2.1 设计链协同设计模式

依据产品核心设计流程,一般可分五大流程区块:产品策划、概念设计、结构详细设计、设计审查、产品试制及项目管理。设计链上的每个成员角色及其功能范围都应该有明确的定义,由于设计能力的不同、分工不同,相对不同的设计链位置,分担着不同目标任务的流程区块的工作。

工业机柜设计中除了钣金企业外,还涉及到外部合作伙伴(即外设计链成员):上游客户、设计公司、供应商、模具加工企业、外协加工企业(包括:机加工企业、塑料件加工企业、铝合金加工企业、橡胶企业、电镀/喷塑企业等)。

在产品设计的各阶段,各设计链参与成员既有分工,又有合作。每个个体不仅应完成各自分工的任务流程区块,而且还应在整个设计流程的其他不同位置发挥着积极的作用,充分利用集体的智慧和资源进行协同决策设计。

工业机柜产品设计链协同设计模式,如图2所示。

该设计链形态一般具备如下特征:

(1) 共同目标。共同的目标是促使员工、部门、企业间不同层次的角色合作的基础,结盟在一起的角色相互协作、相互配合、技能互补,不仅从中分享着利益也共同担负起责任。

(2) 角色的多专家性。组成设计链的角色来自不同层次、不同专业,担负着不同的设计任务。角色的多专家性代表着设计链是一种知识整合系统,即能力系统。

(3) 角色的自组织性。角色作为独立的组织实体,能够自我调整、自我规划、自我评价和自我管理而且角色之间借助通讯和网络系统,能实现信息共享,合作完成过程的目标,形成一个有机的整体。

另一方面,一般情况下,当外界的需求环境发生变化时,就需拆散角色、资源等要素,并按照整体最优的方向重新组合成新的角色集及其合作关系,这是角色的自组织过程。

(4) 动态性。为适应环境的压力,角色能根据外界变化而变化,如通过学习实现角色能力的提升。角色的动态变化说明设计链也具备动态性,随着角色能力的提升,设计链的综合设计能力也在提升。

由上可知,设计链模式整合了优势的设计资源,使每一个角色或成员都朝着同一个目标前进,其合力作用于一个目标。设计链模式将使设计借助外来资源,从而大大提高设计能力及对市场的应变能力。

2.2 设计链协同设计的过程控制

协同设计将采用基于工作流管理的过程控制[3,4],通过与人和各种应用系统的交互来完成业务流程的执行和监控。其体系原型主要包括4个主要功能模块:设计过程建模工具、工作流引擎、管理监控工具、应用工具和客户应用。具体的系统技术构建,如图3所示。

2.3 设计链协同设计平台的构成

协同平台可以实现信息获取与共享的一体化,达到内部协同与外部协同的统一[5,6,7]。钣金企业的产品设计的协同主要在于企业间的跨组织的协同,但目前由于存在企业间的本体论差异、商业技术保密等问题,跨组织工作流的实现经常存在工作流集成困难等问题,企业之间信息传递和交换时信息结构的语义经常丢失,为了解决这个问题,在协同设计体系建设中将引入门户技术。

工业机柜协同设计平台是采用面向多用户的开放式结构,各个用户都可以通过Internet/Intranet浏览器进行协同工作。具体的体系结构,如图4所示。

对图4所示体系结构分析如下:

第1层是由动态协同成员和协同控制过程组成的用户层。设计链上的每一个协同成员都有一个完全的个性化门户,通过它可获得所需的信息和服务。这是成员参与协同活动的基础。

第2层是企业门户层。门户技术的基本原理是将企业的所有数据源、应用和服务集成到一个信息平台上,并基于协同成员的存取控制规则为不同的参与者设置权限。通过网络和安全机制,使客户、供货商及合作伙伴都可以通过这个平台访问企业的信息和应用,获得个性化信息服务,达到信息共享的目的。

第3层是数据库服务层。将产品数据资源数据库、共享知识数据库、项目管理数据库等集中在数据库服务器端。通过ODBC等技术向数据库服务器发送请求,并接收相应数据,Web服务器应用程序运行后,将结果返回用户。

本协同设计平台的实现方法是:各成员企业将最新的专业技术信息、设计资料、产品实例展示、制造资料、模具信息等存放在数据库服务器,而Web服务器运行协同设计系统应用程序。用户使用现成的浏览器向Web服务器发出请求后, Web服务器接收并处理请求、查询数据库、执行应用程序、生成最新的产品模型,并将结果信息以ASP页面的形式返回各成员企业。

在本系统中,浏览器可采用IE,Web服务器可采用Microsoft IIS,而数据库服务器可选SQL Server,数据库开发选用VB或Delphi。

3 应用评价

新设计模式的试用为企业带来的效益是有目共睹的,主要体现在以下几方面:

(1) 提高了设计的效率。原来一个新的标准机柜从设计至试样成功的周期至少为2个月,甚至更长。试用新的设计模式,新机柜的设计周期缩短到30天以内。

(2) 提高了设计质量。设计出错率降低,设计人员有时间和精力致力于更多的创造性的设计工作。

(3) 降低了产品的成本。

(4) 提高了竞争实力。

(5) 人与人之间的关系更为融洽。

不过,新的设计模式在试用过程中也发现一些问题,比如:①目前设计方案评估的专家权威度主要是受人为控制的,偏重于个人感性色彩。计算机筛查比对特征数据库有待不断完善;②设计链成员的素质参差不齐,或参与性不高,或言不由衷等等;③企业间的不信任、信息化程度的不平衡以及数据异构等因素影响优势资源的共享;④由于网络带宽限制等问题,距真正实现远程多用户实时协同设计尚有一段时日。

4 结束语

本研究立足于工业机柜产品的特点及其发展的现状,提出了一种全新的产品设计模式—设计链协同设计模式。该模式强调钣金企业与上游客户、协作企业、供应商、设计公司等形成设计链,实现优势资源互补、共享利益、共担责任以提高产品设计的效率和对市场的应变能力。

虽然在现阶段的实施过程中还存在企业间的不信任、信息化程度的不平衡以及数据异构等诸多问题,但该模式的研究将对类似于钣金产品的设计产生深远的影响。

参考文献

[1]芮延年,刘文杰,郭旭红.协同设计[M].北京:机械工业出版社,2003.

[2]朱世和,高东.并行工程与并行机械设计[J].机械与电子,1995(5):25-28.

[3]史美林,向勇,杨光信,等.计算机支持的协同工作理论与应用[M].北京:电子工业出版社,2000.

[4]KATHY S.Computer Support for Cooperative Work:CSCWIntroduction,ppxxiiixxiv[M].John Wiley&Sons Ltd,1994.

[5]ELAINE M R,JULIAN N.WETICE 2002 Evaluating Col-laborative Enterprises Workshop Report[C].Proceeding ofthe Eleventh IEEE International Workshops on Enabling tech-nologies:Infrastructure for Collaborative Enterprises,2002.

[6]许骏,柳泉波,史美林.协作社群形成与演化机制:理论与算法[M].北京:科学出版社,2005.

五分钟一个设计模式之组合模式 篇5

我们今天来介绍一个专门为树形结构而生的设计模式，组合模式。

一棵树包括分支节点和叶子节点，我们让他们实现同样的接口

public interface IComponent{ string GetInfo;}

定义分支节点

public class Composite : IComponent{ private string name; public Composite(string _name) { this.name = _name; } private Listchildren = new List(); public string GetInfo() { return string.Format(“我是{0}，我有{1}个子节点”, name, children.Count); } ////// 添加子节点 ///

///

public void AddChild(IComponent child) { children.Add(child); } ////// 移除子节点 ///

///

public void RemoveChild(IComponent child) { children.Remove(child); } public ListGetChildren() { return children; }}

下面是叶子节点

public class Leaf:IComponent{ private string name; public Leaf(string _name) { this.name = _name; } public string GetInfo() { return “我是” + name; }}

组合模式到底是如何实现遍历一棵树的呢?下面来看场景类

class Program{ static void Main(string[] args) { //先来组织一棵树，根节点包含manage1和manage2，manager1包括员工1和员工2， //manager2包括员工3和员工4 Composite root = new Composite(“Boss”); Composite manager1 = new Composite(“Manager1”); Composite manager2 = new Composite(“Manager2”); IComponent empl1 = new Leaf(“员工1”); IComponent empl2 = new Leaf(“员工2”); IComponent empl3 = new Leaf(“员工3”); IComponent empl4 = new Leaf(“员工4”); manager1.AddChild(empl1); manager1.AddChild(empl2); manager2.AddChild(empl3); manager2.AddChild(empl4); root.AddChild(manager1); root.AddChild(manager2); Console.WriteLine( root.GetInfo()); DisplayTreeInfo(root); Console.ReadKey(); } //遍历函数，递归调用 static void DisplayTreeInfo(Composite composite) { foreach (IComponent item in composite.GetChildren()) {if (item is Composite){ Composite c = item as Composite; Console.WriteLine(c.GetInfo()); DisplayTreeInfo(c);}else{ Console.WriteLine(item.GetInfo());} } }}

运行结果：

我是Boss，我有2个子节点

我是Manager1，我有2个子节点

我是员工1

我是员工2

我是Manager2，我有2个子节点

我是员工3

软件设计模式之我见 篇6

关键字：软件设计;设计模式;建模语言

中图分类号：TB472 文献标识码：A

软件设计模式（Design pattern）是一套被反复使用、多数人知晓的、经过分类编目的、代码设计经验的总结。使用设计模式是为了可重用代码、让代码更容易被他人理解、保证代码可靠性。软件设计模式主要分为创建型模式、结构型模式、行为型模式三种，其中创建型模式用来处理对象的创建过程，结构型模式用来处理类或对象的组合，行为型模式用来对类或对象怎样交互和怎样分配职责进行描述。

1、设备软件系统的特点

为增加新的处理新工艺变化而需要的功能，我们会修改设备软件的主程序或部分组件源代码，这样不仅修改代码量比较大，延误了软件更新的及时性要求，而且降低了原软件系统的可靠性，为设备的使用留下隐患;对于为修改工艺方法发生的软件系统的改动，则对应的设备软件的主程序修要修改的部分大大增加，甚至更改程序的主框架，使程序不易扩展，造成程序的可移植性大大的降低，不利于系统的升级，增加维护成本，因此，我们引入了设计模式的概念。

2、设计模式的分类

2.1创建型模式

创建型模式用来处理对象的创建过程，主要包含以下5种设计模式：抽象工厂模式（Abstract Factory）、生成器模式 （Builder）、工厂方法模式（Factory Methord） 、原型模式 （Prototype） 、单例模式（Singleton）。Abstract Factory是应对一系列对象的创建的问题，正如前面文章中举的例子，对于创建一个汽车对象来说，Abstract Factory模式更关注一系列的对象的创建，或者说是汽车类型中的各个部分，如：Wheel、Engine、Body等等类型的创建。换句话说关注点在这一系列对象上。Builder是应对一个复杂对象创建的问题，或者说是针对这个复杂对象中的子对象的创建的问题。以汽车的例子来说，我觉得比起Abstract Factory模式，Builder模式相对注重汽车类型（上面所说的“复杂对象”）本身以及其各个部分（Wheel、Engine、Body等等）类型的创建。Builder模式要求这个复杂的类型（汽车）中的各个子类型的结合部分相对稳定，用例子说明就是对于汽车来说，无论用什么配件组装，个个配件的组装方式都一样，有相对稳定的接口。对于这辆车你用什么牌子的Wheel、什么牌子的Engine可能变化会很大很频繁。

2.2行为型设计模式

行为型模式用来对类或对象怎样交互和怎样分配职责进行描述，主要包含11种设计模式。允许多个类处理同一个请求，而不必了解彼此的功能。他在类之间提供一个松散的耦合。类之间唯一的联系就是相互之间的传递请求。请求在类之间传递，直到其中一个类处理它为止。当一个对象向多个对象发送相同的信息时，就需要一种策略来确定由哪个对象对所发送的信息进行处理，而这样的处理对象也只能有一个。使用case语句或if语句的方法会给程序的维护带来很大难度，这就需要职责链模式来完成。职责链模式将发送对象和接收对象进行了解耦，以更好的应对变化。职责链模式将接收对象形成一个链，发送对象将信息发送给接收对象链中的一个对象，这时，信息就沿着对象链向下传送，直到有一个对象对信息进行处理。

2.3结构型模式

结构型设计模式是从程序的结构上解决模块之间的耦合问题。包括以下七种模式：Adapte适配器模式：Adapter模式通过类的继承或者对象的组合侧重于转换已有的接口，类适配器采用“多继承”的实现方式，带来了不良的高耦合，所以一般不推荐使用。对象适配器采用“对象组合”的方式，更符合松耦合精神。Bridge桥接模式：将抽象部分与实现部分分离，使它们都可以独立的变化。减少因变化带来的代码的修改量。Composite组合模式：将对象组合成树形结构以表示“部分-整体”的层次结构。Composite模式使得客户对单个对象和组合对象的使用具有一致性。从而解决了解决客户程序与复杂对象容器的解耦，即：通过继承统一的接口，我们可以将容器对象及其子对象看成同一类对象使用，以减少对象使用中的复杂度。Decorator装饰模式：动态地给一个对象添加一些额外的职责。就增加功能来说，Decorator模式相比生成子类更为灵活。Decorator模式采用对象组合而非继承的手法，实现了在运行时动态的扩展对象功能的能力，而且可以根据需要扩展多个功能，避免了单独使用继承带来的“灵活性差”和“多子类衍生问题”。同时它很好地符合面向对象设计原则中“优先使用对象组合而非继承”和“开放-封闭”原则。Facade外观模式：为子系统中的一组接口提供一个一致的界面，简化接口。Flyweight享元模式：运用共享技术有效地支持大量细粒度的对象。面向对象的思想很好地解决了抽象性的问题，一般也不会出现性能上的问题。但是在某些情况下，对象的数量可能会太多，从而导致了运行时的代价。那么我们如何去避免大量细粒度的对象，同时又不影响客户程序使用面向对象的方式进行操作。Proxy代理模式：为其他对象提供一种代理以控制这个对象的访问。解决直接访问某些对象是出现的问题。从代码的角度看Adapter适配器模式和Proxy代理模式有些类似，前者是解决现有对象在新的环境中所遇到的问题，后者是解决直接访问对象时出现的问题，这两种模式从使用角度看都是解决直接访问对象时出现的问题，只是含义不十分相同。

3、结束语

通过对设计模式的研究，我们的软件研发人员不仅能设计出满足客户需求并且灵活、易扩展、复用性强的软件系统，同时还能使我们的设计者深入了解面向对象的编程思想，提高本身的视野及实际研发水平。

参考文献：

[1]张海攀.信息系统软件体系结构设计研究[N].电脑报，2014

MVC设计模式 篇7

所谓设计模式,本文的理解是:程序由前人积累下来的一些可行解决方法,而程序的设计模式决定了程序各方面最终的性能。本文将FLASH特有的属性和ASPX相结合,创建了双MVC的设计模式。无论在安全性,还是在程序易用性、可维护性、可拓展性上都有了很大提高。

MVC英文即Model-Vi ew-Cont r ol l er,即把一个应用的输入、处理、输出流程按照Model、Vi ew、Cont r ol l er的方式进行分离,这样一个应用被分成三个层——模型层、视图层、控制层。

模型(Model):就是业务流程/状态的处理以及业务规则的制定。业务流程的处理过程对其它层来说是黑箱操作,模型接受视图请求的数据,并返回最终的处理结果。业务模型的设计可以说是MVC最主要的核心。业务模型还有一个很重要的模型那就是数据模型。数据模型主要指实体对象的数据保存(持续化)。

视图(Vi ew)代表用户交互界面,对于Web应用来说,可以概括为HTML界面,但有可能为XHTML、XML和Appl et。

控制(Cont r ol l er)可以理解为从用户接收请求,将模型与视图匹配在一起,共同完成用户的请求。划分控制层的作用也很明显,它清楚地告诉你,它就是一个分发器,选择什么样的模型,选择什么样的视图,可以完成什么样的用户请求。控制层并不做任何的数据处理,它只把用户的信息传递给模型,告诉模型做什么,选择符合要求的视图返回给用户。因此,一个模型可能对应多个视图,一个视图可能对应多个模型。

MVC是一种目前广泛流行的软件设计模式,也逐渐在PHP和Col d Fus i on开发者中得到运用,并有增长趋势。随着网络应用的快速增加,实践已经证明MVC模式对于Web应用的开发无疑是一种非常先进的设计思想,无论选择哪种语言,无论应用多复杂,它都能为理解分析应用模型提供最基本的分析方法,为构造产品提供清晰的设计框架,为软件工程提供规范的依据。

1 MVC设计模式的优点

MVC要求对应用分层,这虽然要花费额外的工作,但使得产品的结构清晰,产品的应用通过模型也可以得到更好地体现。其优点可以表述如下:

(1)MVC具有多个视图对应一个模型的能力。在目前用户的需求快速变化下,可能有多种方式访问应用的要求。按MVC设计模式,一个订单模型以及多个视图即可解决问题。这样就减少了代码的复制,也减少了代码的维护量,即一旦模型发生改变,也易于维护。

(2)由于模型返回的数据不带任何显示格式,因而这些模型也可直接应用于接口的使用。

(3)由于一个应用被分离为三层,因此有时改变其中的一层就能实现应用的改变。一个应用的业务流程或者业务规则的改变只需改动MVC的模型层。

(4)控制层的概念也很有效,由于它把不同的模型和不同的视图组合在一起完成不同的请求,因此,控制层可以说是包含了用户请求权限的概念。

(5)有利于软件工程化管理。由于不同的层各司其职,每一层不同的应用具有某些相同的特征,有利于通过工程化、工具化产生管理程序代码。

2 利用FLASH特性搭建双MVC设计模式

传统B/S架构下的应用程序,客户端、WEB服务器、数据库服务器是一种经典的MVC模式。如图二所示:

FLASH应用程序本身则可以看成是另外一个完整的MVC模式,在界面上的MOVI E CLI P和组件是视图;ACTI ONSCRI PT中的程序逻辑对键盘和鼠标的反应是控制器,连接外部数据的对象(如XML对象或Load Var s对象)或主件(如XMLConnect or或Web Ser vi ce Connect or)是模型。

值得注意的是:FLASH应用程序要决定哪些部分属于视图和模型时比较明显,控制器的定位则比较模糊。有时,应用程序甚至不需要控制器;在JAVA或FLASH的大部分情况中,视图和控制器往往会合并为一个对象,视图类以组合关系包含控制器类。如何将应用程序分为模型、控制器和视图这三个部分,每个人的做法都是不同的,没有绝对答案。

参考文献

[1]张亚飞,何锋镝.精通Flash MX结构化设计和开发[M].北京:科学出版社,2003.

[2]刘海疆,毛潮钢.Flash MX制作完整实例[M].北京:海洋出版社,2003.

设计模式及其在软件设计中的实践 篇8

1 设计模式的概述

设计模式来源于建筑学, 是由erich gamma等人在1990年提出的, 主要是为了提炼和记录软件开发人员的想法、共性问题和多次验证后的成功解, 能够明确表达特定上下文的关系, 特性问题和解决方案。就目前而言, 软件设计模式指的是设计模式和面向对象设计方式之间的关系、优劣和其适用范围。

2 设计模式的分类

设计模式分为行为型、创建型和结构型。

2.1 行为型模式

行为型模式在设计模式中占有很大的比例, 客观来讲, 行为型模式能够满足大多数用户的要求, 并且其工作有积极影响。根据实际要求及其应用, 行为型模式包括备忘录模式和迭代器模式。备忘录模式指的是在不破坏对象的情况下, 获得对象的内部状态, 然后进行保存。该模式适合工作人员, 因为他们的日常工作很多, 选用备忘录模式能够避免遗漏;迭代器模式指的是提供顺序访问聚合对象的元素, 且不透露内部情况, 适用于文档的查找。相对而言, 该模式能够满足特殊工作人员的要求, 在对待复杂工作的时候能够有较好的工作态度, 会趋于理想性工作成绩。

2.2 创建型模式

创建型模式要考虑到现阶段的发展社会。目前经济和科技发展迅速, 很多情况能够根据实际选择设计模式, 固有模式已经无法满足用户需求, 所以出现创建型模式, 创建型模式包括原型模式和单例模式。原型模式指的是采用原型实例对对象进行制定, 在拷贝基础上创建新对象, 采用原型模式能够节省工作时间, 同时能够结合原对象优势来工作和设计;单例模式指的是类型对应实例, 能够访问全局问点, 主观来讲, 单例模式有很强的针对性, 并且具有较为高端的水准, 能够完全满足客户要求。

2.3 结构型模式

结构型模式包括享元模式、组合模式、桥模式、外观模式、装饰模式。

享元模式能够实现共享细粒度符号对象, 能够解决系统因为存在大量共性对象而影响到系统性能的问题。能够削减应用程序中的对象, 还能降低内存占有率, 增强性能;组合模式指的将对象组合成树形结构, 表示部门整体关系, 组合模式具有一致性;客户端能够一致使用组合结构或者对象, 有利于简化客户端的调用, 还能够加入新对象且不用更改代码, 树形结构比如论坛系统、产品结构或者配置管理系统;桥模式是将抽离和现实部分分离, 有独立变化;外观模式指的是为子系统提供高层接口, 供其使用;装饰模式能够动态的给对象增加职责, 更具灵活性。

3 设计模式在软件设计中的应用

3.1 设计模式的步骤

设计模式在软件设计中应用要确定步骤, 这样能够保证在工作中有积极效果。首先要对问题进行抽象, 适当的划分类型。这个步骤是设计模式在软件设计中应用的基础性步骤, 如果没有进行适当的抽象化, 就算选对了类型也无法达到预期的工作效果。其次, 根据相关问题类型来选择合适的设计模式, 通过深化和研究, 设计模式的类别有很多, 不同的工作有不同的设计模式, 选择针对性模式才能处理好问题。然后要进行规划问题和匹配模式, 这个是具体性的应用环节, 软件设计在每个方面都需要较高水准, 否则在日后很难发挥软件性能。然后将选取的模式变体, 最后设计和细化软件体系结构, 以上就是软件设计中应用设计模式的具体步骤, 要严格执行。

3.2 设计模式的应用

选定软件设计模式之后, 其具体应用方式要有规范性的准则, 所以必须根据相关的程序进行。一是要对设计模式有大概的浏览, 了解具体功能和作用;二是研究协作和结构部分等重要分支;三是观察代码的示例部分;四是选择模式参与者的姓名, 在定义类后, 要设计专用的操作名称;这四个步骤能够更好的帮助设计模式在软件设计中的应用, 且能够达到预期效果。

4 设计模式的选取

目前, 软件设计一般应用于两个层面。首先, 初步完成系统体系结构设计后, 要对系统中另外要求的组件和模块能够灵活的加入相应的设计模板。在软件设计的初步阶段, 要使用设计模式对软件的体系结构来进行相关设计。设计模式有一定的复杂性, 所以很难将软件设计模式应用到具体软件设计中, 一是因为没有有效方式进行指导, 而是没有真正把握住软件设计模式。更好的选择软件设计模式要考虑很多方面的因素, 第一要考虑到在设计中有哪些因素是变化的, 第二是要考虑到设计模式要如何解决问题的, 第三要知道检查重新的原因, 第四是要了解浏览模式的意图, 第五是需要了解相似研究的模式, 最后就是要对他们进行相互关联和一定的研究。

5 结语

本文对设计模式及其在软件设计中的应用有一定的研究, 就目前而言, 设计模式的应用有很好的效果, 在其他方面有一定的积极性, 其结果也有广泛的应用。近年来, 面向对象领域的最大成就就是设计模式的提出及其发展, 设计模式具有很好的适应性, 并得到了广泛的重视。随着面向对象领域的发展, 软件设计模式也会有更加完善的发展前景。在往后的工作中, 要进一步深化设计模式, 有利于建立针对性方案来进一步提高软件设计, 有利于满足用户的相关需求, 能够促进社会的进步, 在日后的工作中, 设计模式会有更好的积极作用。

摘要：随着信息技术的迅速发展, 因特网能够提供全球范围的信息, 设计模式随着信息技术的快速发展开始逐渐的形成。设计模式属于一种经验总结形式, 它应用广泛、有分类编码和代码。采用设计模式是重复使用代码, 能够让人们更加理解代码, 保障其可靠性。本文简单的阐述了设计模式及其在软件设计中的应用实践。

关键词：设计模式,软件设计,信息技术,应用实践

参考文献

[1]翟峰.软件设计模式初探[J].信息与电脑 (理论版) , 2009 (12) .

[2]钟金琴, 辜丽川, 孟浩.一种软件设计模式的自动选择方法[J].计算机技术与发展, 2007 (09) .

[3]熊爱娟, 刘忠义, 余凡, 付小丽.浅谈软件设计模式与体系结构和重用技术[J].中国水运 (学术版) , 2007 (09) .

[4]赵德新, 刘瑾.设计模式思想及其应用[J].天津理工大学学报, 2007 (05) .

软件设计模式应用研究 篇9

1 软件设计模式相关技术

1.1 设计模式与软件体系结构

在软件模式中, 体系结构是一种高级抽象, 能够为软件系统提供必要的行为与数形。在实际操作中可发现, 体系结构主要体现了元素描述、系统元素之间作用等功能, 不但指出了系统的组织拓扑结构, 也显示了软件需求及其构成之间的对应关系。

软件设计人员在软件开发中, 首先要了解系统的结构, 再从问题定义、结构需求分析、软件实现等方面进行测试。总体而言, 体系结构的具体构建处在系统设计之前, 设计人员在开始设计之前, 就要从整体系统结构的角度观察各个设计要素, 通过分析系统的功能, 在确定系统组件的约束行为。

1.2 设计模式与软件框架

框架的实质就是一个应用程序, 但这种应用程序是可服用的, 设计人员通过定制框架, 设计出一套能满足用户需求的程序。从用户的一般需求来看, 这种由用户需求而生成的框架满足了其操作的基本需求, 虽然设计流程较为简单的, 用户在整个操作过程中始终处于隐藏状态。从软件的基本特点来看, 框架阐释了在特定领域的设计概念, 能够更加有效的满足此领域内的用户要求。

目前, 经常有设计人员将设计模式与软件框架相混淆的现象, 但实际上, 框架是设计模式的特殊化, 其所服务的内容具有针对性。而设计模式代表设计人员在设计过程中, 需要在特定的场景下去解决重复发生的问题。两者的重点虽然均为问题解决, 但一个是广义的、一个是狭义的。

2 人才培养模式的软件设计应用分析

人才培养一直是企业管理的重点, 在现代化的人力资源管理中, 人才培养的作用越来越明显。在上文分析中可发现, 软件设计模式具有明显的分散性, 能够针对不同功能需求确定基本设计内容。本文将简单分析人才培养模式下的软件设计应用。

2.1 人才培养系统设计

2.1.1 系统网络体系

本文所分析的人才培养系统主要两部分组成, 其中, 培养技术制定与管理, 主要采取基于Web服务的Windows桌面应用程序;在数据查询中, 主要采用基于Web的应用程序。本系统的总体框架结构如图1所示。

2.1.2 系统数据库

人才培养系统的数据库被命名为“人才培养数据库tpdb”, 其主要包括课程体系、专业划分、人才班级分批额、选择组、课程数据库、文档说明等内容。以专业划分为例, 在人才培养专业划分中, 系统能自动划分字段名称, 再根据数据的相关类型, 最终解释不同培养专业的基本信息, 其基本表现形式如表1所示。表1:人才培养专业划分 (Specialitities) 结构

2.2 访问者模式分析

访问者模式主要作用在结构对象的具体操作元素中, 能够在各类专业的前提下, 完成对这些元素的新操作。一般情况下, 这种模式下的对象处理都是以同类对象聚集为前提。

一般情况下, 访问者对经历自身所访问的所有节点。以Concrete Element A和节点Concrete Element B为例。访问者首先会访问Concrete Element A, 这个访问行为主要由以下几方面步骤组成:

(1) 调用Concrete Element A对象的基本信息, 并传入访问者的资料 (主要指账号信息) 。

(2) Concrete Element A对象调查访问者的访问方法, 调查合格之后再传入Concrete Element A对象。

(3) 访问者会调用Concrete Element A的对象方法。当Concrete Element A访问结束之后, 访问者会以同样的方法开始Concrete Element B访问。

在访问者模式处理中, 设计人员要注意以下问题:

(1) 在确定节点之后, 再增加新的节点会变得十分困难, 每增加一个节点都代表的抽象访问对象会增加一个新的抽象操作。

(2) 访问者的所有子类应对所有元素的接口函数进行访问, 即使访问子类不许要对特定的元素进行操作。

3 结束语

本文简单分析了软件设计模式的应用情况, 并以人才培养的软件为例, 对如何应用软件设计模式进行讨论。对设计人员而言, 在设计过程中要注意系统的实效性分析, 以进一步提高系统性能。总体而言, 软件设计模式在现阶段的系统设计中发挥着重要的作用, 在后期的工作中, 需要进一步深化系统员, 确保软件的科学性、有效性。

摘要：随着企业不断发展, 复杂的管理系统成为企业管理的重要媒介, 再加之企业应用系统本身具有面向产品化的发展趋势, 这就导致软件设计人员在解决软件设计过程中的肺功能性问题是, 需要通过先进的技术与方法实现系统的研发。目前, 软件设计模式是软件复用方法的关键, 通过解决软件开发中的复用问题, 推动应用软件的产品化。本文将由软件设计模式的相关技术入手, 对其在实际系统中的应用进行讨论。

关键词：软件设计模式,应用

参考文献

[1]李潇.设计模式及其在软件设计中的应用研究[J].无线互联科技 (技术应用) , 2014 (12) :230-231.

[2]姚蓓窈, 向东游, 张华栋.高速串口的软件设计模式研究[J].计算机测量与控制 (软件工程技术) , 2014, 22 (07) :2318-2320.

[3]郭荣.浅谈软件设计模式中的设计原则[J].信息安全与技术 (应用成果) , 2014 (11) :93-94.

MVC设计模式研究 篇10

1 MVC的结构

MVC设计模式将一个应用程序分为三个部分:模型(Model),视图(View),控制器(Controller)。

模型(Model)用来表示数据和业务逻辑,对应的组件是JavaBean。在MVC设计模式的三个组成部分中,模型主要用于数据处理。模型返回的数据与数据格式无关,也就是说与数据展示没有关系。模型提供的数据能被多个视图所使用,这样就提高了数据处理部分代码的重用性。

视图(View)是用户看到并与之交互的界面,对应的组件是JSP或HTML文件。视图提供可交互的客户界面,向客户显示模型数据。在视图中没有真正的数据处理发生,视图只是将模型里返回的数据作为一种输出数据进行展示并允许用户操作。

控制器(Controller)用来接受用户的请求,调用对应的模型去处理数据,根据模型处理的结果选择不同视图去展示数据并完成与用户的交互。在JSP中,对应的组件通常使用Servlet。

2 MVC工作原理

MVC设计模式的工作原理是客户端的所有请求都发送给控制器Servlet,Servlet接受请求,调用对应的模型处理数据,根据模型处理结果调用不同视图响应;同时Servlet还根据JSP的需求生成相应的Java Bean对象并传送给JSP,JSP通过直接调用方法或者use Bean的自定义标签,得到Java Bean中的数据。Servlet扮演了一个控制器的角色,负责生成JSP页面所要用到的Java Bean对象,并且控制流程的处理,根据不同的请求来决定转发到哪个JSP页面。

3 MVC实现思路

MVC设计模式具体实现是Java Bean作为模型层,Servlet作为控制层,JSP作为视图层。JSP专门用于表现数据而无须进行其他操作,使得JSP页面没有或只含有很少的Java代码。使得页面清晰,提高了可读性,便于维护。

每层作用如下:

Java Bean作为Model层,负责存储与应用程序相关的数据,实现各个具体应用的业务逻辑功能。

JSP作为View层,用于用户界面的显示。它主要通过信息共享,从Java Bean中取出数据,插入的HTML页面中。

Servlet作为Controller层,接收并处理客户端请求,通过Java Bean访问数据库或其他资源,提供View层中要用到的数据,根据处理结果决定转向哪个JSP视图进行交互。

这种设计模式通过JSP页面、Servlet、Java Bean的合作来实现交互处理,很好地实现了表示层、逻辑层和数据层的分离。

4 MVC框架的简单实现

5 MVC设计模式优缺点

MVC设计模式的思想是把应用系统中的各个部件分离,减少部件间的耦合度,这样软件的开发分工就很明确,可以把数据库开发,程序业务逻辑开发,页面开发分开,每一层都具有相同的特征,方便以后的代码维护。但是,分层也提高了对开发人员的要求,产生较多的文件,增加文件管理的难度。

摘要：MVC设计模式的思想是把软件系统中的各个模块进行分离,减少各层次之间的联系,使得层次之间更加清晰,提高了可读性,便于维护。

关键词：MVC,设计模式,控制器,模型,视图

参考文献

[1]李晓东.项目驱动教学法在计算机程序设计语言课中的探索[J].软件,2015(4):107-109.

[2]李晓东.ORM对象持久化技术研究[J].软件导刊,2015(5):52-53.

[3]高昂.JDBC数据库访问技术探究[J].信息与电脑:理论版,2015(13):93-94.

[4]李晓东.DAO设计模式研究[J].软件导刊,2014(7):-37.

[5]李立.浅析Java异常处理机制[J].电脑知识与技术,2012(27):6483-6484.

[6]魏惠茹.Hibernate对象持久化技术的研究[J].电脑知识与技术,2011(19):4733-4734.

[7]魏惠茹.泛型程序设计的研究[J].电脑知识与技术,2009(23):6435-6436.

[8]李霞.MVC设计模式的原理与实现[D].长春:吉林大学,2004.

[9]刘亮.基于MVC的通用型模式的设计与实现[J].中国科学技术大学学报,2010(6):635-639.

铁岭模式·新加坡模式·北欧模式 篇11

题中的北欧模式则是比高级阶段更高级的一种发展状态。除了有(1)效率、(2)公平之外，还有(3)素质与(4)可持续。摆在这里，是作为比较用的。

言归主题。过去30年中国的改革开放，先后出现过几种著名的模式：(1)温州模式——个体户闯天下；(2)苏南模式——乡镇企业闯新路；(3)珠三长三模式——外资企业闯世界。但无论哪一种模式，着重点多置于解决效率问题而少顾及公平(此处公平是一个广义概念，包括了财富分配、区域发展平衡、环境生态、弱势者的照顾等)问题。20世纪90年代中，苏州(新加坡工业园区)模式是第一次尝试同时追求效率与公平两个目标，可惜由于某些原因，合作双方出现了一些矛盾，效果打了折扣。

最近一个偶然的机会，我获邀到辽宁铁岭演讲，所见所闻，印象深刻。这个在5年前还是一个东北以农业为主、发展相当落后的经济社会。目前新城区、老城区、产业发展、都市面貌、社会秩序，都出现了改头换面甚至脱胎换骨式的变化。这个变化过程是有一套学问的，这个让铁岭在短期间初步获致生产力、活力与经济效率，而又兼顾了一定程度的社会公平的做法，堪称为铁岭经验或“铁岭模式”。

就我的初步观察与分析，“铁岭模式”主要有以下要领：

(一)铁岭面积1.3万平方公里，人口300多万，农、矿资源丰富，工业落后，城市老旧，生活水平不高。当地市委书记本身是农业专业出身，知道农业的重要，但更知道靠农业无法致富，要致富必须走两条路，一工业化，二城市化，两条路相辅相成。

(二)工业化与城市化所以能致富，是因为能(1)创造就业，(2)创造产出(即GDP)，(3)创造税收。问题的关键在如何工业化?也就是如何能让国内外企业愿意到铁岭来投资生产?答案其实很简单，就是要搞好硬件与软件。具体地说，就是要把基础建设、投资环境、行政效率、社会环境搞好，而要搞好这些，除了解放思想、大刀阔斧进行行政改革之外，更重要的是要有财源，但此一财源之大，绝非一般地方政府财政所能应付。怎么办?

(三)唯一的办法，就是要设法让当地土地增值。

(四)土地就是土地，如何使其“点石成金”?这就要给潜在的土地购买者、投资者一种土地必然会大幅增值的期待或判断，而后者，则系于铁岭政府当局对铁岭未来产业、经济、社会发展的整体规划，同时，作为第一阶段，先以BOT(兴建、运作、转移)方式引入民间资本启动建设。

(五)建设的第一步是征地，为了不重蹈过去许多地方征地的不合理做法，铁岭一方面给农民兴建居屋，另一方面辅导原来务农的农民转业为工人。

“铁岭模式”迄今运作5年，初步成效是令人印象深刻的。当然，这个模式的核心与原动力，是该地一把手的思维与综合领导力。

设计模式 篇12

虽然软件复用的定义很模糊,但是至少包含了两种含义,一是软件模块的复用,二是软件的可修改性,它们也可以概括为软件的复用。软件模块的复用可以使得编写的逻辑模块在实现一次的情况下,到处可用,逐渐发展为组件化编程;软件可修改性使得原有的程序和代码可以不因用户需求的改变而重写。

从面向对象方法的思想和作用的角度,再加之参考语言角度分类,层层递进,面向对象的方法可以分为3类。抽象和封装,它包含抽象和接口、接口与实现的分离两层意思,两层意思都是基于封装的。前者描述和表达了概念,后者实现了描述现实逻辑和描述概念逻辑的分离。继承和功能的覆盖机制,它是继承和多态最基本的描述。另外还有消息驱动的作用,外部消息来驱动面向对象中的对象,因为这是个被动的概念。

2 设计模式

在软件开发中,一般有3个类型的模式:代码模式、设计模式和系统模式。代码模式指的是编程过程中各种编程技巧;设计模式协助完成系统的模式,主要实现系统功能;系统模式是设计整个系统结构。

设计模式是在特定背景下,描述解决一个设计问题的多个类及类与类之间的通信的对象的描述。一个设计结构的主要方面是由模式抽象和命名来确定的,这些设计结构是可复用的,可能在面向对象设计中得以应用。Alexander给出过模式的经典定义,每个模式都是对一个在某种环境下不断出现的问题和解决这个问题的方案核心的描述。有了这些模式,就可以省略许多重复的工作,高效利用现有方案。

设计模式的目的是对归类整理获得的知识和技能,利用以往多年软件工程实践为基础,成为了软件工程界发展较快的领域之一。

设计模式有很多优点,首先它展示的是一些解决重复出现的问题的经典方案,这些方案是在实践中检测过的。因为每一个设计模式都被系统命名,精确解释和客观评价,解决的也是实际中出现较多的问题,所以设计模式就可以被简单方便地拿来复用。

设计模式最大的作用发挥在分析模型转化为一个实现模型的时候。面向对象的分析向设计转化并不是非常容易的。一个好的可复用的设计会包含一些分析中不存在的对象,再加之使用的编程语言和不同的类库也会产生影响。这样,设计的复用就没有那么简单可以实现,多需要重新设计分析的模型。一个经典的好的设计方法除了包含设计模式外,还可以有用户界面设计模式、分析模式等其他类型的模式,然而,设计模式依旧是设计中最主要、最不可忽略的一个部分。

设计模式可以实现重构的目标。如果不使用设计模式,开发可复用软件时,就要重构软件系统。设计模式的作用在于不仅可以重新组织一个设计,还能减少以后重构工作。很多重构产生的设计结构都有设计模式记录,可以防止以后不必要的重构。在系统建成后,设计模式依然可以发挥作用,它可以修改已建成的系统,为以后的重构起到了目标和榜样的作用。

3 应用

在面向对象系统中应用设计模式时,是对面向对象的设计思想进行了扩展。

(1)封装的变化。对于新的需求在原有需求上发生变化的预见性是对大限度复用的关键,这样可以使得在需求发生变化时可以方便改进系统设计。重新设计的代价是非常大的,而一个不考虑系统需求变化的设计就有可能面对重新设计。为了把系统的影响尽可能降低,把那些可能变化的部分封装,当需求真的变化时,只需修改封装的部分即可。

(2)不对实现编程而是对接口编程。让变量遵守抽象类所定义的接口,而不是将它声明为某类的具体实例对象。客户不用知道所使用对象的特定类型,操纵对象时只是根据抽象类中定义的接口,只要对象有客户需要的接口即可。客户只要知道是哪个抽象类定义了接口,不用关心对象是用什么来具体实现的。这样,就可以大大地减少了各个子系统之间的相互依赖的关系。

(3)优先使用的不是类继承,而是对象组合。类继承无法在运行时改变父类继承来的实现,因为它是在编译时定义的。另外,它破坏了封装性,因为继承后子类就可以知道父类的实现细节。父类实现中的任何变化肯定会导致子类产生变化,因为子类的实现与父类有着非常紧密的关系,子类依赖父类,父类一般会定义部分子类的具体的表示。这样,当子类被复用时,如果由父类继承的东西不能够解决新产生的问题,那么只有将父类更换为另外一个合适的类,或者重写父类。因此,使得复用性被这种依赖关系限制,而且同时还限制了灵活性。相反,对象组合就不同了,它是在运行时候通过获得对其他对象的引用而动态定义的,这样的设计很灵活,也使得封装性良好,因为对象之间是通过接口来访问的。下面以单例模式来说明设计模式在面向对象软件设计中的应用。

单例模式是负责向整个系统提供对实例的访问,并在此之前自行实例化,以确保这个类在系统中只有一个实例存在。

单例模式的实现是通过覆盖InstanceNew和InstanceFree得到的。为了保证只是增加了对实例的引用而不是创建了新的实例,代码中还用到了对象接口的引用计数的机制来管理单例对象的实例。如果用户使用create创建一个新的实例,则InstanceNew就会扫描count_ref的值,若此值大于0,则表示实例已经被创建,只需要增加计数值即可,不需要创建实例。如果用户释放对象时,同样检查计数器的值,若该值不等于0,则说明还有对这个实例的引用,不能将其释放。

单例模式解决了资源竞争的矛盾,把资源变为串行访问代替并行访问。如果实现中资源容易产生冲突或者资源比较紧张,则单例模式是非常适合使用的。实际上,对于数据库管理系统来说,可以提供的链接数都比较有限,多个链接访问数据库,不仅会引起资源的竞争冲突,而且会使得系统负荷增加,有限资源利用率下降。再加之团队设计软件时,数据库访问量的增大,因此,在类似系统的设计过程中,单例模式是个非常好的选择。

有了单例模式,管理数据库链接就高效多了。可以在程序中建立一个链接对象,由它来提供数据库链接,并将其定义为单例类。因为链接类是单例类,只有一个实例可以用来被访问利用,这样就可以保证只有一个数据库链接被创建和占用,而其他模块是通过单例模式对象共享这个数据库链接。

4 结语

在面向对象系统中引入设计模式以后,系统各个模块间的相互依赖性大大降低了。这就意味着,可以修改或者替换任何一个对象,不必担心影响其他。这样改善了以往系统中高度耦合带来的修改不便,只要模块间的协作方式和组合关系不变,整个系统的运行就不会被影响。不必担心扩展会破坏系统原有完整性,就可以将系统方便地进行扩展,只要接口一致,就可以将已有模块方便地复用到下一个系统中,即便进行修改也是少量修改即可。在面向对象系统中引入设计模式,使得面向对象程序设计有了新的进展,也大大减轻了开发和维护人员的工作负担。

参考文献

[1]Erich Gamma,Richard Helm,John V1issides,等.设计模式—可复用面向对象软件的基础.机械工业出版社,2000.

[2]Bruce Eckel.JAVA编程思想.机械工业出版社,1999.

[3]James W.Cooper.JAVA设计模式.中国电力出版社,2003.

[4]王晓庆,曾文英.设计模式中的面向对象原则及其子模式[J].计算机工程,2003,29(9):192-193.

[5]孟祥文,邵维忠.设计模式特化和模式库组织[J].计算机工程,2002,28(5):36-37.

[6]刘艺.Delphi模式编程,北京:机械工业出版社,2004.

[7]张友生.软件体系结构.北京:清华大学出版社,2004.