Java开发网 - Design Patterns偶得

Java开发网

您没有登录

» Java开发网 » Design Pattern & UML

打印话题 寄给朋友 订阅主题

作者

Design Patterns偶得

cosmoschen

发贴: 1
积分: 0

于 2004-02-04 15:29

劣者从知道Design Patterns也好一阵子了，买了几本书，翻了一遍，也跟着做了几个整理，不过总觉得摸不着核心，便停下来学习别的，最近发下志愿重头再看一遍，忽然有些新的体会，在这里分享给大家，重点在于「学习」的过程，而不是学习的内容，内容就在几本经典的书上，包括：

GoF Design Patterns
Design Patterns Explained
Design Patterns Java Workbook
当然，还有阎博士的书

过程很简单，我先是看了GoF的Design Patterns，把23个Patterns的「名称、理念、应用时机」大致了解，对我而言，这本书的价值在于参考，书中把实作的时机、变型、延伸、关联解释的十分清楚，是实作时拿来参考的主要依据。

接着进入Design Patterns Explained，主要在简化Patterns理念、由来及介绍一些最基本的应用概念，书中用Java为主要范例，所以读起来在架构上很简明，他并没有把所有的Patterns都做介绍，不过很重要的是他带出了Design Patterns的应用之一在「解决因不良设计导致的问题」，这点启发了我：当现有程序在历经改变及新需求时，在这个时候才试着导入Design Patterns来让工作变的更好？初学Design Patterns，老想着在设计新程序时便急着应用，这就像你拿了把铁锤，就把所有东西都想成是钉子，急着想敲敲看，结果很可能是不幸的发现，自己并没有办法掌握的很好，所以就产生极大的挫折。

在这里举个例子：我设计了一个Data Access Object Interface用来封装一些基础的DB操作，同时在里面实作Connection Pool的机制，这个接口有Oracle和MS SQL的实作，后来也陆续加入了许多不同DB的实作版本，最近开发的程序需要转换DB，在设计上我换DAO的实作即可，程序正常，不过却遇到一个问题：不同DB里面的资料无法很容易的Migrate。

这时我便想到Design Patterns了，利用Factory Method做一个产生DAO的Factory，接着包装一个Mediator做为资料型别的中介转换Utility，大致上的做法如下：
DAOInterface DB1 = DAOFactory(DAOInterface dao);
DAOInterface DB2 = DAOFactory(DAOInterface dao);
Utility.migrate(DB1, DB2);
这个Migrate方法会自动在DAO中寻各自对应的型别，然后进行适当的DB Table创建及型别转换工作，最后，再利用两个DAOInterface把资料写入即可。

或许这不是个好例子，但对我的意义而言，原本要手动整理资料型别对应，逐步下SQL指令做Migrate的动作，现在可以适当的「封装」成为一个可以再用的Mediator类别，这也是书上说的另一个重点：「什么时候应该适当的使用封装，什么时候又要使用抽象让工作简化」。

一直到这个时候，都还感觉不到Design Patterns的威力，最近看了Design Patterns Java Workbook，才有忽然间「通透」的启发，这本书运用了很不同的分类方式，把Design Patterns依「相似性」做了分类，程序出身的我，在这里看到了更多的可能性：「模式的分类也是一种抽象」，这句话可能跟GoF的Bridge Pattern一样难懂，在这里解释一下：Design Patterns Java Workbook里第一篇把Adapter、Facade、Composite、Bridge等Pattern结合为接口模式，接口大家都了解，把你想要的使用方式预先做适当的规范，接着便可以依照不同的场合，选择不同的实作版本来应付变化。所以当你想要结合「两种」不同的操作接口，你可以试试Adapter或Facade，更进一步来说，当你要结合像讨论群组与讨论标题这两种不同的接口，便可以试试Composite或Bridge，不同的是，Composite在于提取出相同的操作接口，而Bridge在于让两种接口可以各自发展出特有的行为模式，但又保持适切的关系。

所以从程序的角度来看，对象间彼此的「关联」与「责任」才是Design Patterns讨论的重点，一样是A Class呼叫B Class，我们可以利用Adapter把呼叫B Class的动作变成呼叫C或D Class；运用Facade把呼叫B Class变成是整体操作的一环……到此，我开始从范例程序代码的牢宠中解脱，真真正正的去看多个对象间，彼此互动的关系可能有哪些变化，以Observer Pattern来说，我可以把变动的责任下放到个别的Class之中；也可以应用Mediator Pattern把相关的变动封装成为一个专属的Class里面，重点在于：哪一个选择比较适合现在的状况。

到了这里，再看阎博士的书就变的十分有趣了，他把中国古代经典里面的许多精神与范例拿来解说，运用我们已知的知识，除了可以更清楚的掌握每个Pattern的要义，同时也能更进一步的发想出更多创意，至于那些范例，更是一个练习的好地方，因为实务上没有人会叫你去设计红楼梦里的行酒令，但如果你认真的去思考，这些就是Design Patterns的真正目的：可再用的设计理念。

后记：这是野人献曝，提供的也仅仅只是个人的观点，从一开始由类别图「强记」各种Patterns的型式，到后续的分析彼此变化关联，到现在从更哲学的观点看Design Patterns，才明白原来写程序也可以这么人性，这么深沉，笔者来自台湾，用字上的不同之处，请多包涵，有任何意见也欢迎与我一同讨论。

话题树型展开

人气	标题	作者	字数	发贴时间
12914	Design Patterns偶得	cosmoschen	2430	2004-02-04 15:29
10991	Re:Design Patterns偶得	jigsaw	9	2004-02-06 11:14
10654	Re:Design Patterns偶得	mochow	7	2004-03-17 11:35
10777	Re:Design Patterns偶得	heaven	9	2004-03-17 12:02
10626	Re:Design Patterns偶得	Geminist	38	2004-06-03 21:12
10554	Re:Design Patterns偶得	Rainwolf	291	2004-06-15 17:11
10678	Re:Design Patterns偶得	littledeer1974	106	2004-09-10 09:49
10399	Re:Design Patterns偶得	zyzhang	327	2004-09-10 17:51
12715	Re:Design Patterns偶得	主管	18	2004-11-05 16:51

已读帖子

新的帖子

被删除的帖子