[专题讨论]设计模式及应用

lodge

关于设计模式, 一直没有透彻理解, 在偶看来所谓设计模式应该叫实装模式, 更加合理.
一直不太明白各设计模式应该如何和系统功能设计(或者叫外部设计)联系起来.

yining

最初由 husthxd 发布
[B]java与模式
j2ee核心模式
ejb设计模式 [/B]

core j2ee patterns很多都是GoF模式的变种。与其花力气去钻研这个，不如仔细体会GoF23个模式。

yining

最初由 lodge 发布
[B]关于设计模式, 一直没有透彻理解, 在偶看来所谓设计模式应该叫实装模式, 更加合理.
一直不太明白各设计模式应该如何和系统功能设计(或者叫外部设计)联系起来. [/B]

我认为设计模式有三个层次，最高的层次是框架模式，比如MVC，Layered，pipeline等等，框架模式决定了整个程序的总体结构；然后是细节的设计模式，经典的代表就是四人帮的23个模式，这些模式的应用在具体的细节设计，给程序员提供了更灵活更有弹性的程序结构，方便了以后的更改；最后是编码的模式，比如double-checked locking等等，这些模式往往和具体的编程语言相关，解决的是实际编程中的一个具体的技术问题，而不是结构问题。

菲猫的“系统功能设计”是啥意思？

lodge

最初由 yining 发布
[B]

我认为设计模式有三个层次，最高的层次是框架模式，比如MVC，Layered，pipeline等等，框架模式决定了整个程序的总体结构；然后是细节的设计模式，经典的代表就是四人帮的23个模式，这些模式的应用在具体的细节设计，给程序员提供了更灵活更有弹性的程序结构，方便了以后的更改；最后是编码的模式，比如double-checked locking等等，这些模式往往和具体的编程语言相关，解决的是实际编程中的一个具体的技术问题，而不是结构问题。

菲猫的“系统功能设计”是啥意思？ [/B]

恩, 偶是这样考虑的, 举个例子说, 如果要开发一个想ITPUB这样的BBS系统, 首先, 要提出关于这个系统功能的一个外部设计, 也就是说, 根据需求提出一个系统的概念性的设计, 比如, 使用INTERNET, 有不同管理角色, 不同的角色可以拥有不同的处理权限, BBS的内容要分版块, 版块之间的处理相互独立等等, 这就是偶说的偶说的系统功能设计

然后, 在这个基础上做概要设计, 决定大的系统功能模块, 和共通的处理框架, 比如说, 出于负荷分担的目的, 要使用多个DB, 每个DB完成一个版块的功能, 还要有一个系统管理DB, 负责协调各个DB的功能, 更具体地说, ITPUB的首页信息保存在系统管理DB中, 而进入到某一版块后有该版块所在DB进行处理, 这样一来, 对DB ACCESS方法, 和事物管理等等就有了特殊要求, 这些要求应写入概要设计, 并作为系统框架的设计依据
比如偶们决定把系统框架分为BOUNDARY层处理(画面输入和输出的处理), 和BUSINESS层处理(系统逻辑), 这样在BOUNDARY层和BUSINESS层之间就需要有API来保证两部分机能的连接, 于是偶们可以设计一套INTERFACE, 由于偶们对数据库连接方法有特殊要求, 因此考虑设计一套抽象类(把共通处理固化在里面), 以保证连接要求的实装, 这样看很容易决定哪些功能应该通过INTERFACE实现, 哪些功能应该通过ABSTRACT实现, 在比如, 对于象LOG管理这样系统级别的处理, 应该使用STATIC方法等等等等

可是, 联系到设计模式, 就很难想象, 各个模式的实际意义(不是说他们在实装上的效果)比如, 使用FACTORY模式是否能满足偶们对事物处理的要求等等

另外, 偶认为单纯从实装的角度上应用设计模式, 虽然, 能够简化代码编写的工作量,但为测试和系统运用带来了不少困难(比如单体测试的测试用例如何确定才能发现FRAMEWORK中的问题), 盲目使用设计模式应该是弊多利少

yining

我觉得你说的功能设计，就是需求分析了，可能其中包含了将具体的需求分析转化成用例的过程。但是仍然是需求分析的部分。在这个阶段，设计模式是起不到作用的，因为这个还是OOA的初始阶段。在这个阶段之后，也不能马上进行概要设计，因为还没有建立domain model。而正是Domain model的结构以及用例决定了整个程序的结构。所以下一个阶段，是进行domain model的分析。然后是通过domain model以及用例做出交互分析。如果直接进入数据建模，容易过度偏向关系型数据，而不是OO的数据模型。

当然，需求是不断变化的，所以没有什么设计可以在项目一开始的时候就完全兼顾所有可能的需求变化。所以我觉得开始的设计没有必要太复杂，只需要经过domain model建立大致的框架，然后就可以进行编程了。具体的细节设计可以在编程的过程中通过refactoring达到相同的目的。

lodge

偶觉得是采用数据分析的方法以数据结构为核心建立系统模型, 还是使用OO的方法已用例为中心建立系统模型是要具体情况具体分析的, 比如财务系统中数据是最为重要的因素, 所以数据结构的设计应当优于用例分析, 而在游戏程序中, 角色和情节的设计往往是制品的卖点所在, 因此需要强调用例分析.
回到本贴的话题上,偶现在还是不能理解所谓JAVA设计模式, 和OO的数据模型有什么直接联系, 虽然其中, 有几个模式还是能够让偶联想到数据模型的, 比如ITERATOR, COMPOSITE, TEMPLATE,BRIGE,
ITERATOR不用说, 就是循环了, COMPOSITE就是递归, TEMPLATE比较基本, 是共通处理, BRIGE(还有ADAPTER)也很有趣, 是INTERFACE的用法,
最让偶困惑的是FACTORY偶实在想不明白它们究竟能和什么样的实际功能相对应, 在偶看来, FACTORY只是复合的TEMPLATE而已, 要准确定位那些功能要放到ABSTRACT FACTORY, 哪些功能要放到ABSTRACT PRODUCT里面还真不太容易, 如果这一点搞不清楚, 有怎么能确定各个模块的单体测试用例等等一系列问题呢?
另外, 偶也不太认同每种模式必先做ABSTACT类或INTERFACE的说明方法, 过于喧宾夺主了, 就拿ITERATOR来说, 先做AGRRAGET抽象类, 再做循环子抽象类, 然后再分别用两具体的实装类来继承, 这和FACTORY模式的做法如出一辙, (实际上这已经是FACTORY模式的具体应用了)反而淡化了, 在任何循环结构中都需要有循环子和集合体两个要素这样重要的概念.

yining

四人帮的设计模式主要是为了编写程序时候解决具体问题用的，这些问题未必与数据模型有多大关联。当然，其中的几个，比如bridge，vistor，等等还是会影响到数据模型的。至于工厂，这个未必和数据模型有联系。我在实际应用中有过这样的经历：一个分析的东西，有可能要用JAXB，有可能用Castor，在我做的时候还没有定论，所以我采用了abstract factory的模式，这样在以后切换生成方式的时候，至少接口是保持不变的。不过，虽然这个决定在当时是合理的，但是从事后看来，以后也未必会再更改了，所以基本是浪费。罗罗嗦嗦的乱说了一通，其实只有一个意思：设计模式往往只是一个折中，一个在两难情况下的比较平衡的选择。至于这个选择是否合理，要看需求。当需求变化了之后，这个平衡就未必成立，设计也就需要作相应的调整。

icemen

观注中……

zdr

学习中！

icemen

coding才是软件的终结者！