2003-12-30设计问题讨论

lodge · 发表于 2004-1-2 14:08

最初由 xzh2000 发布
[B]

我暈倒。 [/B]

呵, 不好意思, 看看思路就OK勒, 偶是来学用PD滴

ITjane · 发表于 2004-1-2 18:32

老实说我对PD只是工作需要才使用。对它的广泛深入运用是一知半解的。谢谢这些好资料！

ccwlm741212 · 发表于 2004-1-3 23:01

最初由 xzh2000 发布
[B]

我暈倒。 [/B]

咱也喜欢用那个东西

ccwlm741212 · 发表于 2004-1-3 23:05

最初由 lodge 发布
[B]可以看到, BBS已经被分解了, 分解的方法主要是对已知的功能进行的分类.
根据上面的分类, 偶把功能分成了管理模块和用户模块, DB将保存全部数据并负责提供应用逻辑处理. 接下来, 要做的是对各用例进行深入分析, 以确定, 数据结构和主要处理逻辑
做法是, 先为各种功能做用例子图, 并确定各个实体之间的界面, 然后, 根据界面的情况做ER图 [/B]

感觉你这样的设计方法和设计模式的分析问题的方式好象有些不同

lodge · 发表于 2004-1-3 23:41

最初由 ccwlm741212 发布
[B]

感觉你这样的设计方法和设计模式的分析问题的方式好象有些不同 [/B]

恩是有些不同, 偶这里做的是最初的设计方案, 接下来就要使用设计模式, 逐步得到各个CLASS的详细式样了
这一步, 被称为基本设计, 其重点是确定系统基本需求, 而不是系统内部构造, 这一部分的内容是整个系统开发的基础哦

ccwlm741212 · 发表于 2004-1-3 23:44

最初由 lodge 发布
[B]

恩是有些不同, 偶这里做的是最初的设计方案, 接下来就要使用设计模式, 逐步得到各个CLASS的详细式样了
这一步, 被称为基本设计, 其重点是确定系统基本需求, 而不是系统内部构造, 这一部分的内容是整个系统开发的基础哦
[/B]

好啊，最好能深入讨论一下

lodge · 发表于 2004-1-4 00:15

最初由 ccwlm741212 发布
[B]

好啊，最好能深入讨论一下 [/B]

恩, 偶注意到这样一个问题, 就是很多朋友在没有确定系统功能的情况下, 就急于开始系统内部的结构设计. 比如, 上述讨论中, 谈到的TRANSACTION管理呀, JDO呀, 类的关系类型呀之类的问题, 这些问题在现阶段是无法回答的, 因为还根本没有明确系统要实现哪些功能,

CCW的问题中提到了如何确定用例的边界, 这是一个很好的问题, 偶们之所以觉得这个问题很难回答, 就是因为偶们没有通过上述的工作来确定系统的边界.

在实际的开发设计中, 这是要最先弄清楚的问题, 作为结果除了上述的系统结构图, 功能图, 还要有硬件构成图和网络配置图.

现在, 偶可以回答CCW的第一问了, 需要的用例已经在前面的功能图上注明了.

接下来, 偶们可以为各个机能画USE CASES DIAGRAM了

ccwlm741212 · 发表于 2004-1-4 12:52

走下神坛的设计模式--设计模式入门
下面只是一点对设计模式的简单理解，只希望能够使初学者比较快的了解一下设计模式的基本内容，如果要深入理解，还是请看大师们的经典

之作。

首先，为什么要有设计模式，主要的目的就是软件重用了。辛辛苦苦写的代码，没怎么用就扔掉，不是太可惜了么。但是代码质量太差，用了

会出错也不行。所以我们要尽量写出可以重用的代码。

我们的目标就是代码重用和维护方便，说白了，就是
1.少写重复代码
2.尽量不修改已经完成的代码
3.如果要增加功能，最好是通过添加新的类，而不是修改现有代码。
4.一定要修改的话，也要容易修改，并且不会或尽量少影响到其他。
5....

设计模式就是教我们如何在前辈们的经验上，写出可以满足上面条件的代码。
现在都是面向对象了，所以主要考虑的都是基于对象的重用。使用一个对象分为3步：
1.创建/取得一个对象
2.操作这个对象的方法以改变对象状态
3.销毁这个对象。
所以如何创建一个对象就是第一个要考虑的问题，也就有了创建模式。
操作对象呢就是行为模式了。
销毁一个对象比较容易，但是会经常忘，小心点就是了，其模式大概不多。java基本上不用太多考虑这个问题，所以也就管杀不管埋了。
对象之间还有一些复杂关系，来描述一些复杂的事务，当然就是结构模式了。

既然创建对象是第一步，那就从创建模式说起。如果创建一个对象呢，最简单也是最标准的当然是new了
MyClass obj=new MyClass();

有什么问题么？如果就这么简单当然没问题，但是如果创建一个对象不这么简单呢？比如你要建一个数据库连接，那可不是一个new就能完成的

。
如下:
String drv = "com.microsoft.jdbc.sqlserver.SQLServerDriver";
String url = "jdbc:microsoft:sqlserver://127.0.0.1:1433";
String uid = "sa";
String pwd = "123456";

Connection cn=null;
try
{
Class.forName(drv).newInstance();
cn=DriverManager.getConnection(url,uid,pwd);
}
catch (Exception e)
{
e.printStackTrace();
}

这么麻烦，你不会每次生成一个数据库连接的时候，都写这么多代码吧？怎么办，粘贴拷贝是个办法，不过一般都是写个方法了。方法不会独

立存在，需要一个class

public DBManager
{
public static Connection getCn()
{
String drv = "com.microsoft.jdbc.sqlserver.SQLServerDriver";
String url = "jdbc:microsoft:sqlserver://127.0.0.1:1433";
String uid = "sa";
String pwd = "123456";

Connection cn=null;
try
{
Class.forName(drv).newInstance();
cn=DriverManager.getConnection(url,uid,pwd);
}
catch (Exception e)
{
e.printStackTrace();
}
return cn;
}
}

这样每次不用ctrl+c,ctrl+v了。你的代码里都是方法调用，看起来也简洁一些。这就是一个工厂方法，而且是静态工厂，为什么用静态工厂，

因为没什么状态需要工厂保存，所以用静态方法比较好，还不用创建一个工厂实例。为啥叫工厂，这是个比喻了，工厂生产产品，在这里就专

门生产对象了。比喻比较恰当，也好记一点。最好我们把例子改一下名字。
public DBFactory
{
public static Connection getCn()
{
String drv = "com.microsoft.jdbc.sqlserver.SQLServerDriver";
String url = "jdbc:microsoft:sqlserver://127.0.0.1:1433";
String uid = "sa";
String pwd = "123456";

Connection cn=null;
try
{
Class.forName(drv).newInstance();
cn=DriverManager.getConnection(url,uid,pwd);
}
catch (Exception e)
{
e.printStackTrace();
}
return cn;
}
}

推而广之，凡是不是调用者用new生成，而用其他的对象间接生成的对象，都可以看作是广义工厂方法。凡是不能简单的用一个new生成的对象

都可以考虑用工厂方法。好处就是，嘿嘿，少写几行代码了。另外，创建对象的方法有改变时，只改工厂，调用者不用改。别忘了我们的目标

是代码重用。

如果一个工厂只生产一个产品，那不成作坊了，所以让这个工厂多干点事吧，上面的工厂要是能生成不同数据库的连接该多好啊。可以啊，代

码修改一下：
public DBFactory
{
public static Connection getCn(drv,url,uid,pwd)
{

Connection cn=null;
try
{
Class.forName(drv).newInstance();
cn=DriverManager.getConnection(url,uid,pwd);
}
catch (Exception e)
{
e.printStackTrace();
}
return cn;
}
}
于是这个工厂就可以生产各种数据库连接了。凑巧的是，jdbc可以用java的反射机制，实现一段代码，生成不同的jdbc，如果不是jdbc，很有

可能要通过if else写好多代码了。不过总好过每个地方都粘贴代码吧。另外还可以通过配置文件生成jdbc的参数，这些就是更细的实现方式了

，不必详谈了。

这就是简单工厂方法（静态工厂）的来历。

ccwlm741212 · 发表于 2004-1-4 12:52

创建型模式
Ø  FACTORY—人才市场：以往是要哪个人才，就找哪个人才，效率低，现在有了人才市场，我们只需直接去人才市场挑一个好了；
Ø  BUILDER—生产流水线：以前是手工业作坊式的人工单个单个的生产零件然后一步一步组装做，好比有了工业革命，现在都由生产流水线代替了。如要造丰田汽车，先制定汽车的构造如由车胎、方向盘、发动机组成。再以此构造标准生产丰田汽车的车胎、方向盘、发动机。然后进行组装。最后得到丰田汽车；
Ø  PROTOTYPE—印刷术的发明：以前只能临贴才能保持和别人的字迹基本相同，直从印刷技术发明，从而保证了复制得和原物一模一样；
Ø  SINGLETON—唯一：以前是商标满天飞，相同的商标难免造成侵权，直从有商标保护法后，就保证了不会再产生第家企业使用相同的商标；
结构型模式
Ø  ADAPTER—集众人之私，成一己之公：武当派张三丰会太极拳，少林派智空大师会金刚般若掌，如果他们两个都成为我的师傅，我就既会太极拳，又会金刚般若掌了；
Ø  DECORATOR—青出于蓝而胜于蓝：武当派张三丰会太极拳，是我师傅，他教会了我太极拳，但我自己还会点蒙古式摔交，张三丰却不会。于是我就成了DECORATOR模式的实现；
Ø  BRIDGE—白马非马：马之颜色有黑白，马之性别有公母。我们说”这是马”太抽象，说”这是黑色的公马”又太死板，只有将颜色与性别和马动态组合，”这是（黑色的或白色的）（公或母）马”才显得灵活而飘逸，如此bridge模式精髓得矣。
Ø  COMPOSITE—大家族：子又生孙，孙又生子，子子孙孙，无穷尽也，将众多纷杂的人口组织成一个按辈分排列的大家族即是此模式的实现；
Ø  FACADE—求同存异：高中毕业需读初中和高中，博士也需读初中和高中，因此国家将初中和高中普及成九年制义务教育；
Ø  FLYWEIGHT—一劳永逸：认识三千汉字，可以应付日常读书与写字，可见头脑中存在这个汉字库的重要；
Ø  PROXY—垂帘听政：犹如清朝康熙年间的四大府臣，很多权利不在皇帝手里，必须通过辅佐大臣去办；
行为模式
Ø  CHAIN OF RESPONSIBLEITY—租房：以前为了找房到处打听，效率低且找不到好的房源。现在有了房屋中介，于是向房屋中介提出租房请求，中介提供一个合适的房源，满意则不再请求，不满意继续看房，直到满意为止；
Ø  COMMAND—借刀杀人：以前是想杀谁就杀，但一段时间后领悟到，长此以往必将结仇太多，于是假手他人，挑拨他人之间的关系从而达到自己的目的；
Ø  INTERPRETER—文言文注释：一段文言文，将它翻译成白话文；
Ø  ITERATOR—赶尽杀绝：一个一个的搜索，绝不放掉一个；
Ø  MEDIATOR—三角债：本来千头万绪的债务关系，忽出来一中介，包揽其一切，于是三角关系变成了独立的三方找第四方中介的关系；
Ø  MEMENTO—有福同享：我有多少，你就有多少；
Ø  OBSERVER—看守者：一旦被看守者有什么异常情况，定会及时做出反应；
Ø  STATE—进出自由：如一扇门，能进能出，如果有很多人随时进进出出必定显得杂乱而安全，如今设一保安限制其进出，如此各人进出才显得规范；
Ø  STRATEGY—久病成良医：如人生病可以有各种症状，但经过长期摸索，就可以总结出感冒、肺病、肝炎等几种；
Ø  TEMPLATE METHOD——理论不一定要实践：教练的学生会游泳就行了，至于教练会不会则无关紧要；
Ø  VISITOR—依法治罪：因张三杀人要被处死，李四偷窃要被罚款。由此势必制定处罚制度，故制定法律写明杀人、放火、偷窃等罪要受什么处罚，经通过后须变动要小。今后有人犯罪不管是谁，按共条例处罚即是，这就是访问者模式诞生的全过程；

ccwlm741212 · 发表于 2004-1-4 12:55

面向模式构建系统架构
邓辉、孙鸣

架构是一个软件系统中的核心元素，是系统中最难改变的部分，也是构建软件系统中其他部分所依赖的基础，因此系统架构的好坏会从根本上决定基于这个架构所构建的软件系统的质量。系统架构的构建一直是软件开发过程中的一项重要工作，同时也是一项很困难的工作，即便对于很有经验的系统架构师也是如此。但是，模式以及模式语言的提出给出了一条构建系统架构的有效途径，本文将对此进行深入的论述，并以一个著名的单元测试工具JUnit为例进行说明。

概念分析

首先，对架构（architecture）和模式(pattern)这两个概念进行简单的介绍。前面已经讲过，架构是一个系统中的核心元素，是该系统中最本质的部分。系统的各个组成部分正是通过架构所描绘的方式协同工作共同完成系统的功能，从而表现出一个完整的系统。由于系统的本质是不容易变化的，所以如果一个架构构建的正确，也就是说能够真实的反映出系统的本质，那么就可以使基于该架构构建的系统具有比较长的生命力，否则该系统的质量就会逐渐的降级，直至崩溃。如果以建筑领域来作类比可能会比较好理解一些，试想如果一个建筑物构建在一个在结构上有问题的混凝土骨架上，那么该建筑的寿命可想而知是不会长久的。

什么是模式呢？模式是在某种特定的场景(context)下某个不断重复出现的问题的解决方案。模式本身并没有任何的创新性，它仅仅是对于一些已经被证明为优秀的解决方法的归类、总结，目的是为了重用该解决方案而又不用做重复的劳动。其中，"特定场景"和"重复"两个限定词非常关键，"特定场景"给出了什么时候以及为什么使用一个模式，"重复"说明了模式的可重复性从而可以被重用。参考文献〔4〕中总结了23个经典模式，非常值得读者朋友细心研读。

架构搭建的难点

既然架构是一个系统中最核心、最本质的部分，要想构建一个正确的架构当然不会容易，为什么呢？下面将从几个方面进行分析。

首先，由于架构是一个系统中的本质的反映，因此架构一般是由系统中不容易改变的部分组成，这些不容易改变的部分往往是系统中的一些抽象的概念。但是，我们在构建系统的架构前仅仅有一些用户的需求以及对于用户业务流程的用例(use case)，如果缺乏有效的指导原则，很难从这些信息中提取出反映问题领域本质的概念来。关于这一点，参考文献〔3〕中给出了一个很有效的方法：Commonality/Variability（公共性/可变性）分析。它的核心思想是针对问题领域中的概念进行分类，把那些看上去不同但本质上属于一类的概念用一个抽象的概念来表示，然后基于这些抽象的概念构建架构。Commonality/Variability分析方法在发现系统中的抽象概念方面确实很有效，但是前面已经说过，系统架构不仅仅是一些系统中的抽象概念，而且还描绘了这些抽象概念间的关系，仅仅使用Commonality/Variability分析方法不能十分有效的发现抽象概念间的关系。

其次，即使确定了抽象概念间的关系，构建起了一个系统架构，在这个架构的指引下，我们还是很有可能陷入困境。为什么呢？因为该架构可能会缺乏对于我们进一步工作的指引，缺乏后续发现对象的有效手段。也就是说，架构可能过于空泛，缺乏延伸性。

最后，一个经验丰富的系统架构师可能成功的构建了一个系统的架构，成功的基于该架构完成了系统，但是他的经验、心得体会可能会很难为其他的系统架构师所理解，从而在解决同类问题时可以有效的被重用。因为，这些心得体会如果表现的过于抽象，可能会显的空泛从而指导意义不大；如果表现的过于具体，有可能陷入细节从而失去通用性。

正是由于上述原因使得系统架构的构建非常的困难，往往必须由资深的系统架构师来完成。但是随着模式的提出以及对模式研究的深入，这种局面正在逐步的改变。下面让我们先来对模式进行一番深入的认识。

深入认识模式

读者对于模式的认识大都是从《设计模式》（由参考文献[4]翻译而来的）一书的出版开始的。该书中描绘了23个经典的模式，每一个模式都给出了一个精制优雅的解决方案，为每一个程序员所沉迷、拍案叫绝。但是由于经验的不足往往会造成对于模式的误解。《设计模式》一书的作者John Vlissides为此专门写了一片文章进行阐述，详见：http://www.research.ibm.com/desi ... 旅嬉灰唤兴得鳌�

第一层境界：认为模式就是一种解决方案，一般刚刚接触模式的人都处于这个认识层面。确实是这样，刚刚见到模式时很容易被它所提供的精制的解决方案所吸引，由于缺少经验反而容易忽略模式的其它的重要方面。这样做非常容易造成对于模式的误解、误用。比如：为了使用模式而使用模式以及过分的使用模式等。这种境界仅仅认识到模式怎样（How）去解决一个问题。

第二层境界：除了解模式提供的解决方案以外，还能够认识到模式背后的一些指导原则。《设计模式》一书的第一章对于模式背后的一些指导原则进行了详细的论述，比如：针对接口编程；优先使用组合而不是继承；发现变化、封装变化等。不过缺乏经验的人可能对此理解不会深刻，甚至忽略了这些原则，需要不断的实践、体会方能理解。不过体会到这些原则之后就会对面向对象的思想的理解提升一个层次，提高自己的面向对象分析、设计能力。参考文献[2]中对于这些原则有深入细致的讲解，相信会对读者有非常大的帮助。

第三层境界：认识到模式其实是一些关系，用来舒缓系统内部的"冲突力"。这一点仅仅从模式提供的解决方案实例中就可以看出。其实，不管你如何去做，最终的解决方案肯定是一些模块通过彼此的交互、建立一种关系来完成所需的功能。为什么模式提出的方法就是好的呢？就是因为模式给出的关系舒缓了系统内部的"冲突力"，使人感受上去舒服一些。另外，模式并不是简单的给出了一些概念间的关系，它进一步为我们提供了一个场景，提供了进一步工作的指导。是不是太抽象了，我们来举一个例子来说明一下：面向对象设计中有一个著名的原则：SRP（Single Responsibility Principle），即一个类仅仅需要一个职责。如果一个类有多于一个的职责有问题吗？实现起来当然没有问题，但是经验丰富者马上就会感觉到职责间关系的这种"冲突力"，从而感觉到不舒服。反映到实现层面上就是本来毫无关系的模块间依赖过于强，导致代码僵化，牵一发而动全身。"高内聚，松耦合"堪称软件领域处理模块间关系的首要指导原则，但是它没有告诉我们对于一个问题具体该如何去做，模式的出现填充了这个空白，如果我们知道一个模式可以解决我们手头的问题，那么我们就可以非常感性的认识到如何达到"高内聚，松耦合"，因为模式已经给出了这些关系。这一层境界非常抽象，很难达到，有兴趣的读者可以阅读参考文献[1]，相信会有更进一步的认识，更加深入的理解。

下面我们就来谈谈模式为什么能够为系统架构的构建带来有效的帮助。

面向模式构建系统架构

前面介绍了构建系统架构时的难点，本小节将讲述一下模式如何能够有效的解决这些难题，使得系统架构的构建变得有章可循。

前面曾经提到过，Commonality/Variability分析方法可以有效的发现反映问题领域本质的概念，但是不能十分有效的发现抽象概念间的关系。如果Commonality/Variability分析方法和模式结合起来，就能够有效的解决这个问题。上一小节也说过，模式其实就是一些关系。如果我们有一些需求，并且我们知道有针对该需求的模式，那么我们就可以通过Commonality/Variability分析方法发现反映问题领域本质的概念，然后根据可用的模式去建立这些概念之间的关系来实现我们的需求。这样我们就可以通过模式有效的克服不能有效确定概念间关系的难点。

模式本身并不仅仅简单是一些关系，它还具有深刻的内涵。它具有自身的意图、动机、适用性以及核心解决方案等众多的内容。一旦我们确定使用了一个模式，那么这个模式就为我们搭建了一个内容丰富的场景，这个场景可以非常有效的指导我们进一步的工作，启发我们发现新的对象。这样，基于模式构建的系统架构就变得抽象（模式本身就是一些抽象的关系）而不空泛并且具有很好的延伸性。

模式也提供了一套公认非常有效的记录方法，可以把自己经过反复验证的解决方案记录下来传授给其他人重用，即模式具有可传授性。这样，有经验的系统架构师就可以把自己的一些心得体会通过模式的方法记录下来，就可以克服经验无法有效传授的问题。

其实很多模式本身就是针对系统架构提出的，比如：MVC（Model-View-Controller），它是专门针对交互系统提出的，所以如果我们要构建一个交互系统，那么我们就可以直接应用MVC模式，然后在该模式所搭建的场景的启发下去发现Model、View以及Controller，在这个大的场景的指导下根据其它的需求（模式）构建一些小的场景对系统进行有效的分化。细心的读者会发现，模式和系统架构有很大的相似性，都是处理一些抽象概念间的关系，但是二者还是有很大的不同的，模式是领域无关的，它是解决一些抽象问题的，但是系统架构是针对我们要解决的实际问题的，是领域相关的。我们可以通过对问题领域的分析、分解，找到和我们要解决的问题匹配的模式，对该模式进行定制应用到我们的系统中来。把模式结合在一起构建起整个系统架构来。

面向模式构建的系统架构在需求发生变化时还会使我们处于一个非常有利的位置。为什么呢？因为模式是针对一个反复出现的问题的优秀的解决方案，它的方法就是发现变化、封装变化。它本身已经充分考虑了变化的情况。模式采用了一种不同的对待变化的方法，它不是预先考虑会如何变化，而是考虑哪里可能会变化，然后隔离，所以当变化发生时我们就处于一个有利的位置上。

最后让我们来看看模式论坛研究、探讨的一个焦点论题：模式的生成性。模式的生成能力是指模式创建最终行为的能力。有人认为，模式系统可以形成一种语言，即模式语言。模式既是模式语言的要素，同时又是模式语言的规则。象数学证明一样，可以通过模式的推导、演绎生成系统架构。当然，目前的模式语言远远还不完备，还不具有如此强大的生成能力。不过，至少为我们的软件开发的永恒解决方法提出了一个美好的希望，让我们大家共同来为此努力。有兴趣的读者可以到hillside.net获得更多有关模式语言的信息。

JUnit架构一览

前面讲了这么多，本小节我们将结合一个实例进行说明。我所选择的是JUnit，一个很著名的单元测试工具，选择它作为例子主要有两个原因：其一是JUnit相对比较简单，这样我可以集中于要论述的主题；其二是JUnit中大量使用了模式，这样大家可以对于上面的论述有一个感性的认识。下面对于JUnit的说明会比较粗略，读者可以到www.junit.org去了解有关JUnit的更加详细的信息。

JUnit是一个单元测试工具，所以它就要满足使用者对于单元测试工具的需求。让我们一一来进行说明，首先测试用例的书写必须要容易，只有这样大家才可能会使用该测试工具。要迎合这一点，我们可以通过把测试用例表示为对象的方式来完成，对象的概念和人思维中的概念最为贴近，表示起来也最为自然。Command非常符合我们的要求，看看它的意图：将一个请求封装成一个对象，从而对请求进行排队或者记录日志…。另外，测试工具要为使用者做它能够做的最多的事情，尽量减少使用者的工作量，我们必须对测试的一般流程进行分析，归纳出一个模板流程，这样就可以使使用者仅仅关注自己所需要的具体步骤而不用考虑如何去组织这些步骤（一般的测试都分为测试准备即setUp，运行测试即runTest以及结束清除即tearDown阶段），Template Method模式正好能够帮上忙。另外，测试工具应该能够统一处理单独的用例以及多个用例的组合，这样也可以大大减少使用者的工作量，是不是马上就想到了Composite模式，不错，就是它。

下面根据上面的论述，在我们所得出的模式场景的指导下，给出JUnit系统架构的UML图表示：

Junit本身提供了源代码，有兴趣的读者朋友可以参阅。不过如果了解了系统的架构后在去看源代码的话，相信会有不同的感受。

结论

本文从宏观上探讨了系统架构、模式以及模式在构建系统架构方面的的有效性。限于篇幅，其中有很多重要的内容没有做十分深入的论述，关于这些内容准备在后续的文章中作为独立的主题来讲解。希望本文能为读者朋友带来一些启发。最后我就以模式的提出者Christopher Alexander的一段具有深刻内涵的话作为结束："以一种松散的方式把一些模式串接起来建造建筑是可能的。这样的建筑仅仅是一些模式的堆砌，而不紧凑，这不够深刻。然而另有一种组合模式的方式，许多模式重叠在一个物理空间里，这样的建筑非常紧凑，在一小块空间里集成了许多的内涵，由于这种紧凑，它变得深刻。"

参考文献

The Timeless Way of Building, Christopher Alexander
Design Patterns Explained: A New Perspective on Object-Oriented Design, Alan Shalloway and James R. Trott
Multi-Paradigm Design for C++, James O. Coplien
Design Patterns, Gamma, et. al.,

[精华] 2003-12-30设计问题讨论

浏览过的版块