还有就是细心体味了一下OO的设计原则，这些原则是凌驾于模式之上的，也就是更宏观的原则。

其中，最高指导的一个就是“开－闭”原则。别的原则，里氏代换原则、依赖倒置原则、组合/聚合复用原则和迪米特法则都是为了达到“开－闭”原则而出现的规则。

这些原则告诉我很多东西，聚焦于一点就是要“面向抽象”来做一切事情。

分析对象的时候，要多分析设计“抽象”的概念，对象之间的联系要多基于抽象的概念而不是具体，这样具体才能能够变化，这样才是开闭。用我自己的话就是要“游走于 抽象”。

这里有一个我必须记住的就是，在封装变化时候，多用聚合/组合，少用继承。在封装原子变化并且是同类型对象时才用继承，别的都尽量用聚合/组合。而且尽量不要用多级继承，多级继承一般意味着有两种变化脉络，可能的话，让两种变化脉络独立演化。很明显，一独立演化，又要聚合/组合了。

还有一个必须记住的是：运用抽象以后，客户端的使用发生了巨大的变化。不再是指那儿用那儿。而是要做更多的准备工作，因为运用抽象，本身就把具体“组合”的职责推迟到使用的阶段。那谁使用，肯定是客户端。所以，客户端的使用要革新。要习惯用工厂，习惯把一系列的抽象定具体了，并按照一定方式“组合”起来用。而且，最终要善于用接口来调用方法。

用小飞推荐的一个工具画了个图，如下：


                       MARCO ZHANG 2006年2月27日7:18:57

共享的idea是生活中最基本的idea，不必有意的使用，到处已经存在了。在生活中，大部分事物都是被多人多次使用的，这都是共享的实际应用。

之于OO的共享

OO中的共享，无非就是说让“对象”也能被“多人多次”（这里的“人”也无非就是进程、线程而已）使用，更详细的说，就是要让对象的生存空间更大一些，生存周期更长一些。

自己闷个儿脑子，提炼出了几个需要使用共享的环境（context），也可以说是原因吧：

1.         为了保持“对象”的一致，我们需要共享。例如，“国家主席”就一个，不能多了，如果多了，难免决策混乱。

2.         为了控制“对象”的存储空间，我们需要共享。毕竟，目前来说，系统的memory还是编程时最珍贵的资源。

3.         为了优化“对象”的创建消耗，我们需要共享。如果，一个对象的创建过程消耗太大，系统不能支持频繁的创建，共享的使用它也是一个好主意。

4.         等等。

而在实际的应用中，往往我并没有细想“我为什么使用共享？”，已经不自觉的就用了；如果真的认真分析起来，基于的环境也是多样，并不会只是上面的其中一种。

常用的“共享”方法或模式（我曾经用过的，知道的不多，望谅解）：

1.         “Singleton模式”：一个class就一个对象实例，大家都用它，满足context1。

2.         “pool技术”：只提供一定数目的对象，大家都用他们，实现context2、context3。

3.         “flyweight模式”：一个class的一个状态就一个对象实例，实现一个状态对象的共享，实现context2、context3。

使用时要注意的地方：

1.         确定共享的scope。例如，在Java Web Application中就是选择是page，session还是application，当然也可以是jvm级别的static。

2.         确认thread safe。当共享的对象可能被多个线程共享时，这是不可以回避的问题。

3.         应对对象状态的变化。一旦共享的对象发生了变化，我们怎么处理？改变之，舍弃之？也是我们需要确定的。

项目中的应用：

项目需求：

为学校的同学提供Web查询，查询的内容有很多。其中，“查课表”、“查考表”是最为关键的需求，以后可能还要提供“查询空闲自习教室”的功能。

在这些查询中，有一个共同点，就是都涉及“教室”这一对象。“查课表”时要告诉同学在哪个教室上课，“查考表”时要告诉同学在哪个教室考试，等等。

数据库设计：

对于“查课表”用例，有关的数据库设计如下：
 

对象层的设计：

学生每查询一门课程的课表，系统就会sql查询“视图V_LESSONSCHEDULE”，进而生成一个LessonSchedule对象，然后返回给用户显示。当然，在生成这个LessonSchedule对象的过程中，属于它的Classroom对象，以及更深一步的Building、Area对象都会生成。下面就是这个过程的顺序图：

因此，每生成一个“课表”对象（LessonSchedule）或“考表”对象（ExamSchedule）时，都要：

1.         查数据库中的教室、教学楼、校区的信息；

2.         创建相应的“教室对象”（包括了属于它的“教学楼”对象和“校区”对象）。

考虑共享“教室”对象

“教室”对象一旦可以生成以后，完全可以给后续共享使用，不必要每个查询都要去生成。

详细说是基于下面的考虑：

1.         这类查询用例（查课表，查考表）发生的频繁很高很高，也就是说，一旦让用户查起来，系统中会产生大量的“教室”对象这类对象，应该说会占很大的内存空间。

2.         共享“教室”对象后，可以减少对数据库的查询次数，并降低了查询粒度（以前是基于二级视图查询，现在可以基于基本表查询），提高了一点数据库查询性能。

当然，同时我脑袋中也有反对的声音：

1.         虽说，这类查询会产生很多相同的“教室”对象，但是JVM本生提供的垃圾回收功能完全可以处理它。除非，“同时”有很多很多这类对象都在被使用，根本回收不了，才会造成内存短缺。

2.         如果，我以某种共享机制让这些“教室”对象，在系统中存在下来（延长了生命周期）了。而它们本身的数目就很多（如，我们学校就有××），可能还没有等你用上，系统已经挂了。另外，如果不是同时有很多查询需要，我留这么多“教室”对象在系统里，反而是占了内存，而不是优化了内存的使用。

1.         所有模式的通病――“增加了复杂度”。

 

结论：

经过我们分析，系统对于“教室”对象的重复使用，频繁程度非常高。一般，有10个人同时使用，就有5个人左右涉及的用例要使用“教室”对象。把它共享起来，还是有一定必要的。

 

进一步考虑：

而实际上，我们可以进一步共享下去：

除了让客户端共享“教室对象（Classroom）”外，还可以让“教室对象”共享“教学楼对象（Building）”，和让“教学楼对象”共享“校区对象（Area）”。

因此，最终的共享是在三级上都实现。

 

Flyweight模式：

 

特点：

书上说：“享元模式可以使系统中的大量小粒度对象被共享使用”。第一，对象出现的量要大，想必这比较好理解，很少使用的也就没有必要共享了；第二，要小粒度，我比较纳闷？难道对于大粒度对象就不行吗？可能书上认为，大粒度对象的共享已经占了比较大的空间，没有小对象那么有效吧。

 

另外，书上还说，要使用“享元模式”，被共享的对象的状态（类别）要比较固定，这样就可以为每一个状态仅仅创建一个对象。当然，如果每次使用对象时，对象的状态都是不一样的，那就根本不存在共享这些对象的必要了。

 

联系项目思考：

基于上面对项目的分析，“教室”、“教学楼”、“校区”对象都是在系统中会被大量使用的对象，而且粒度的确比较小；并且它们有固定的类别，而且不易改变。如校区对象，暂时就有4个。教学楼可能40－50个左右。很适合“享元模式”的使用环境。

 

确定共享方式：

1.         确定共享对象的scope。在本web程序中，这些共享对象的scope理应是application，而更简单的一个作法就是把这些对象设为static，我选择后者。

2.         确认thread safe。这些对象是可能被多个servlet访问的，也就是有可能存在多线程访问。但是，由于这些对象的可变性很差，一旦创建就不大可能变化。因此，我决定把这写共享对象设计成不变模式的，一旦创建就只会被读取，而不会改写，这样就不存在多线程控制的问题了。

3.         应对对象状态的变化，如某个教室的类型变了。这里采取的是舍弃的方法，为每个工厂添加了一个清空方法――clear()，用于清空已经生成的共享对象。

 

设计类图：

 

当然，也可以把这些工厂都设计成“Singleton模式”的，使它们只会有一个实例。

 

客户端使用：

由于共享的对象都被包含在了“课表”和“考表”对象里，不会被客户端直接访问，因而不会对客户端的使用有任何影响：

 

实例代码

 

 1//取得编号为32号课程的“课表对象”
 2
 3LessonSchedule oneLesson = LessonSchedule.findByLessonNum(32);
 4
 5 
 6
 7//获得教室对象
 8
 9Classroom oneClassroom = oneLesson.getLnkClassroom();
10
11 
12
13//获得教学楼对象
14
15Building oneBuilding = oneClassroom.getLnkBuilding();
16
17 
18
19//获得校区对象
20
21Area oneArea = oneBuilding. getLnkArea();
22
23 
24
25//再次重新生成一个编号为32号的“课表对象”
26
27LessonSchedule twoLesson = LessonSchedule.findByLessonNum(32);
28
29 
30
31//获得教室对象
32
33Classroom twoClassroom = twoLesson.getLnkClassroom();
34
35 
36
37//获得教学楼对象
38
39Building twoBuilding = twoClassroom.getLnkBuilding();
40
41 
42
43//获得校区对象
44
45Area twoArea = twoBuilding. getLnkArea();
46

oneClassroom与twoClassroom；oneBuilding与twoBuilding；oneArea与twoArea由于都是32号课程的东西，根据我们的设计意图，应该实现共享。

而实际上，它们每对的确是同一个对象的引用。因此，实现了预期的设想。

 

Review：

在本项目中，当第一次设计出来的时候，我们发现了某些对象恰好有共享的需要。

 

而更多的实际情况是，这些需要共享的“信息或状态”在设计中并不是那么恰好的表现为“一个对象”的粒度，而是要不就包含在一个对象内部，要不就跨几个对象。在这样的情况下，共享的设计更多是发生在代码重构阶段而不是第一的设计阶段。当然，为了共享对象而做出的代码重构，最重要的一步就是把需要共享的“信息或状态”设计成为新的对象。

 

对于，“享元模式”来说，就是要把需要共享的“信息或状态”设计成“享元对象”。别的在此就不说了，因为我也不懂了，呵呵。

                                          MARCO ZHANG 2006年2月23日13:48:49

marco 2006-02-23 14:14 发表评论

]]>

预料中的日志3暂时生产不出来，话说难产就好，别夭折就行，有点掉价哦，呵呵。

因为有些东西还没有想清楚。那就先搞个四吧，这个东西还是清楚那么一点的。

一版描述：

而项目中用户所谓的访问权限是基于他拥有的角色。也就是说，servlet对用户访问权限的检查，就是对他所拥有角色的检查。暂时，每个用户只能拥有一个角色。

项目的角色很多，但是在web端暂时只有如下的三种：

既然这样，servlet的加锁方式就有：

 注：上面的“游客”就是“游客角色有权访问”的意思，依此类推。

这里只有关系“或”（||），如果一个servlet的加锁方式是“学生或教师”，也就是说拥有学生或教师角色的用户都可以访问它。关系“与”（&&）在这里不太可能存在，因为没有需求说：某个servlet一定只能由“既是学生又是教师的用户”才能访问，而且前面也说了，暂时一个用户“有且只有”一个角色。

运用OO的最基本方式，就是封装对象。既然有为servlet“看门”的责任，那就把这个责任封装成一个对象，用个俗名：validator。

接着，运用共性和个性的分析方法，既然有那么多种不同的看门方式（加锁方式），那就搞一个接口，然后让各种“不同”都实现这个接口，形成子类。那就有下面的图：

可以看到，由于有7个加锁方式，那就要有7个子类。每个子类根据自己逻辑override接口的validate方法。

这样，对于一个servlet，想让它上什么样的锁，只要让它拿到对应的子类的引用即可，如下图中的ClientServlet，我们规定只能有“学生或教师”才能访问它。它的部分代码便是：

1//new对应的Validator接口的子类。
2//这里是学生或教师可访问，因此要new Student_Or_Teacher_Validator
3Validator validator = new Student_Validator();
4//然后调用验证方法就可以了
5boolean ok = validator.validate();

至此，第一个解决方案就出来了。

思考：

不足	validator接口的子类数目随“角色数”成“指数级”增长，数量太多；而且子类中重复逻辑的代码很多，如“Student_Or_Teacher_Validator”就重复了“Student_Validator”和“Teacher_Validator”的逻辑，万一“Student_Validator”的逻辑要改，只要涉及Student的子类都要跟着改，维护上不方便。

进一步改进的可能

“Student_Or_Teacher_Validator类”的validate方法很大程度上就是“Student_Validator类”的validate方法和“Teacher_Validator类”的validate方法“或操作”出来的结果。   因此，能不能考虑由“Student_Validator类的validate方法”和“Teacher_Validator的validate方法”动态的构造一个功能如“Student_Or_Teacher_Validator类的validate方法”。   这样，“Student_Or_Teacher_Validator”就可以省略了，只剩下一些原子的“角色类”。要实现Student_Or_Teacher_Validator的验证功能，拿Student_Validator和Teacher_Validator装配一下就可以了。

结论，需要根据实际情况，动态的改变（装配）“Validator接口对象”的validate方法。

第一个火花就是“装饰模式”。它可以让客户端动态的组装对象的方法。真神奇！

第二版来啦

注：上图中出现了AndRelation和And的一系列角色类，可以暂时省略不看，因为前面说了，现在还没有“与”关系这个需求。只看Or的就可以。

我喜欢叫这个模式为洋葱模式，一层包一层，最外层对象某方法的逻辑是由内部一层一层对象的同一方法组合出来的。

使用了这个模式，便不用如一版那样实现那么多子类，只要实现几个“角色类”即可，这里有3个（学生角色：Or_Student、教师角色：Or_Teacher、游客角色：Or_Guest）。所有一版中别的子类都可以由这3个组装出来。

如要生成一版中的Student_Or_Teacher_Validator对象，可以用Or_Student和Or_Teacher两个对象“Or”出来：

1Validator validator = new Or_Student(new Or_Teacher(OrRelation(req)));

如要生成一版中的Guest_Or_Student_Or_Teacher_Validator对象，可以用Or_Student、Or_Teacher和Or _Guest三个对象“Or”出来：

1Validator validator = new Or_Student(new Or_Teacher(new Or_Guest(OrRelation(req))));

这种一层包一层的new方式，是不是很像洋葱？第一次看是很不习惯，看多了就觉得习惯了。

对客户端的影响：

一版中，客户端要什么样的验证类，就直接使用具体类。

二版中，客户端要什么样的验证类，它的工作多了那么一丁点，它需要先组装一下，正如上面的例子。这种组装的方法很易于理解和使用，不会给客户端带来任何的不便。如果实在觉得客户端组装不出来（傻B客户端），也可以搞个工厂给它supply！

优点：

相对一版最明显的优点就是类的数目少了很多。

一版不是说“指数级”吗？这里只是线性的了。假设某一天系统拓展到有10个角色，一版就有2的10次方那么多个，也就是1024个验证类。

而二版还是10个角色类，别的都可以在客户端使用的时候，动态的组装

更重要的是代码结构好了，重复逻辑少了。每个逻辑都以最atomic的大小放到最应该的地方。

进而，维护的代价少多了。如某天“教师角色”的验证逻辑发生了变化，只要改动Or_Teacher一个地方即可。

                 MARCO ZHANG 2006年2月18日23:49:56

       研究生院项目中“明显”使用了“工厂方法模式”。其实在遇到具体问题的时候，即使我们不知道有这个模式存在，我们也肯定会造一个类似的东西出来。但是，肯定没有书上论述的那么好，那么全面。我想这就是看书的好处吧。

工厂方法出现的必然（我的理解，一个很狭隘并幼稚理的人的理解）

       刚开始使用这个东西的时候，只是感觉是单纯的一种模式，用于创建需要的对象。

       但是随着使用和思考的深入，越发发现它给我的启示不只在于单纯的对象创建，而是告诉我应该怎么理解“产品”，怎么得到“产品”，怎么消费“产品”，以至于以后怎么设计“产品”。

       下面这个线索是我对它出现必然性的理解：

1.         “针对接口编程”

  这是OO世界中经典的规范，不管你主动还是被动，你天天都在用这个东西。

    接口是共性的表示，在对象的世界中，共性和个性的辩证关系是最重要的关系。在万千的对象中，通过它们之间的共性和个性，可以形成最基本对象层级架构。

假设我们的讨论域中有以下一些对象：“学生”、“大学生”、“小学生”、“中学生”；我们不用细想，学过一天OO的人都可以为这些耳熟能详的对象们，通过个性和共性的关系得出下面的结构图。

       把这些对象之间的关系定义成这样是顺理成章的。

       下一步肯定是让客户端“使用”这个接口啦。也就是如下图：

2.         接口和具体类的矛盾

勿庸置疑，我们只希望Client跟接口Student打交道，让它根本就不知道Student有哪些子类，绝对不希望直接跟它们打交道。

但这里出现的困难是，接口都是“假”的，都是由具体类upcast的。

如果Client要使用接口Student，Client中必须会出现下面的代码：

Student marco = new Small_Student();

       只要一出现这个代码，就说明Client不只跟Student打交道了，它知道了Small_Student类，这违反了我们预先的想法。

3.         找“人”帮我去创建“接口对象”

    从上图体现出来的结构看，Client只想跟Student打交道的目的是实现不了的了。

       最简单的方法就是找另外的“帮手”去帮我生成这个“接口对象”。这个帮手它知道“接口对象”的具体类型，但是它为客户端提供的却一定是“接口类型”。这就符合我们的要求了。如图：

    这样，Client就可以既用到了“Student接口对象”，又不用因为“只有具体类才能创建对象”的规则，而必须对其子类结构有完全的了解。它成功的解决了2中的矛盾。

       而“负责创建具体类对象的任务”全部都落在了这个“帮手”身上，这个“帮手”（Student_Factory）就是工厂模式中的工厂类，更具体的说，它就是“简单工厂模式”中的“简单工厂类”。

       我觉得，即使一点都不知道工厂模式，一旦我遇到了2里说的矛盾，我也会用这样的方法处理。

4.         这个“帮手”不符合“开－闭原则”

这个帮手的确不错了，而且一跃成为系统中最重要的对象了，所有“创建具体类的逻辑”都放进去了，也就是因为重要，万一挂了不就惨了。

再者，它不符合“开－闭”原则，我不能在不修改这个帮手的情况下添加任何一个产品。在这个例子中就是，如果那天我有病非要加一个“幼儿园学生”进来，那您就必须修改这个“帮手”的代码了，这个“帮手”现在就变成Version2（如下图）了，这个二版的帮手，可以在“代码”层实现对一版（还没有添加幼儿园学生之前)的通用，但这种保证在“开－闭”原则看来，还是不够的，不保险的，它要的是在类的结构上的保证。声明一下，这是我很感性的理解，不正确的可能性很高。

5.         让“帮手”也多态

这里可以尝试让“帮手”也多态一下，这样“每种学生类创建的任务”都被分派到了多态出来的类中去了。这时，再有新的学生类型加进来，添加一个对应的帮手就可以了。这样虽然类多了一些，但是符合“开－闭”原则，书上称之为“工厂方法模式”。如图：

    假如Client现在要使用一个小学生，代码如下：

1        //创建一个小学生工厂类这个帮手
2        Student_Factory factory = new Small_Student_Factory();
3        //求助这个帮手，帮我创建一个
4        Student primaryStudent = factory.produce();
5        //这时就可以使用这个小学生了，让它玩玩游戏吧
6        primaryStudent.playGames();
7

    在这里还是要强调两点：

n         虽然实际上Client的确使用了一个小学生对象（Small_Student），但这里Client也认为它就是Student对象，这里一定要用Student接口来隐藏它的具体类。

n         另外，却不需要用Student_Factory这个接口来隐藏它的具体类，因为，Client实际就是通过“选择它的具体类”这招儿来“选择创建的学生类型”。这里的Student_Factory更多的功能不是“隐藏”具体类，而是“规范”具体类。

项目实践

       扯淡到此，该联系我们的项目啦。

       由于是做研究生院的项目，其中巨大的需求就是要让同学能在网上提交各种申请单，申请退学的，申请转专业的，申请复学的，申请保留学籍的，除了申请女朋友的外，应有尽有。       对于这些单子，用最最基本OO思维，根据共性个性分析方式，抽象出一个申请单接口，和若干的具体类。

       当然，除了概念上感性上吻合以外，在项目中它们也要“真”的有巨大的共性才行，如都要提交，修改，删除，审核，打印等功能。

       靠，既然都这样了，肯定就用一接口规定它了。

       想到这里，加上有了上面的思考，不用说了，就用工厂方法模式啦。

    图中Ent_Shift就是申请单接口。等于前面分析的Student接口。还可以看到有很多具体类，前面例子中是代表各种学生，这里就是代表各种申请单。

       当然，这里还有很多工厂，也就是前面一直叫的“帮手”。

       Bean_Shift就是工厂接口，相当于前面的Student_Factory接口。还有很多的具体类就是生产各种申请单的工厂类。

       下面就是使用“申请单工厂方法模式”的一段客户端代码：

 1        //声明申请单接口
 2        Ent_Shift es = null;
 3        //声明申请单工厂接口
 4        Bean_Shift bs = null;
 5        //根据传入的申请单类型数字身成对应的申请单工厂
 6        switch (shiftTypeID) {
 7            case Bean_Shift.SHIFT_CHANGETEAAP :
 8                bs = new Bean_Shift_CHANGETEAAP();
 9                break;
10            case Bean_Shift.SHIFT_RESERVEAP :
11                bs = new Bean_Shift_RESERVEAP();
12                break;
13            case Bean_Shift.SHIFT_RENEWAP :
14                bs = new Bean_Shift_RENEWAP();
15                break;
16             //省略了别的申请单……………………
17            default :
18                this.forwardErr(req, resp, "所选择的异动类别不存在");
19        }
20
21        try {
22            //调用工厂接口的生产方法
23            es = bs.getBlankShift(stuID);
24            
25        } catch (Exception e) {
26            this.forwardErr(req, resp, DB_ERROR);
27        }
28        //调用单子的提交方法
29        es.submit(req);
30        
31        //发给页面去显示
32        es.fowrardWithSessionObject(
33                req,
34                resp,
35                Ent_Shift.nameInSessionAndRequest);
36

升华

       个人比较同意《Design Pattern Explained》中作者讲的，要用好很多的模式，其中都有一个思路，就是用接口或抽象类来隐藏子类的不同。

       我每当看到这时，老是会被一种思路困扰――“new只能new具体类啊，这咋能隐藏呢，这隐藏还有什么用呢？”。

       作者仿佛也曾经有过我的这个傻B苦恼，它的解决方法就是：根本在使用对象的时候，特别是设计阶段，尽量不去想对象是在那里被new的。他认为：反正有了工厂模式后，你总有办法把他们new出来的。

       所以，我用了工厂模式后更发的启发是：以后设计的时候不要想一个Client怎么创建一个对象，尽管放心大胆的先继续想，直接使用就好了。反正最后我还有工厂模式呢。

       因此俺的副标题才是“Ignore how they were created”，呵呵。
                                    MARCO ZHANG 2006年2月16日3:52:10