设计

Rational Rose使用点滴积累

遇君阁 — Wed, 16 Apr 2008 08:41:00 GMT

Ø 如何定义namespace

1．创建一个Package，，命名为Namespaces。

2．在刚才建立的Package下建立一个GClass类，定义一个int i和getvalue成员函数。如图：

3．双击Namespaces package，并在“ANSI C++”标签里将IsNamspace属性置为true，如图：

4．生成代码

Ø 正向工程与逆向工程

正向工程：

1).检查并创建模型中的类，比如创建类名为GClass的一个类；

2).在Component View里创建构件(component)；如：创建名字为NewPackageBody的component名称

3).双击刚才建立的构件（NewPackageBody），在弹出的Component Sepcification窗口中的Realizes标签页里右击你要分配的类，选择”assign”将类映射到构件，同时你需要在General标签页里将language选项设置成ANSI C++ ，如下图：

4).可以在Tools->ANSI C++->Open ANSI C++ Specification设置代码生成属性，如图：

5).选择类图和（或)构件图中要进行代码生成的类和构件；

6).选择Tools> ANSI C++>Code Generation或者右单击类和构件图标，选择ANSI C++>Generate Code…。

逆向工程：

1）在构件视图（Component View）中创建并命名新的构件(Component)，如：NewPackageBody；

2).双击新的构件（NewPackageBody）打开Component Specification窗口，将构件的实现语言改为ANSI C++，如图：

3).右单击新构件（NewPackageBody），选择快捷菜单中的ANSI； C++>Open ANSI C++ Specification…，打开构件ANSI C++ Specification窗口，如图：

4).在构件规范窗口的Files标签中添加源文件；

5).单击构件NewPackageBody，选择Tools>ANSI C++>Reverse engineer…，打开“选择要添加到模型中的类 ”的窗口；

6).选择要添加到模型中的类，单击Ok按钮，开始逆向工程。

Ø 定义模板类

1）检查并在模型中创建一个类，比如创建TAllocator；

2）双击在第一步中创建的类（TAllocator），出现Class Specification窗口，在General标签页中将Type设置为：ParameterizedClass，如图；

3）同时在Class Specification窗口的Detail标签页中的Formal Arguments中增加一个类型名T，类型为class，如图：

Ø 定义组合

1）检查并建立模型中的两个类，比如建立类A和类B；

2）使用聚合关系连接A和B；

3）双击那根聚合的连接线，在窗口Aggregation Specification中的Role B Detail中，将Containment of B设置成By Value的方式，如图：

GoF《设计模式》23个模式的源代码（已经编译通过）

游游的家 — Wed, 05 Dec 2007 11:17:00 GMT

目的：
帮助正在学习设计模式的同学学习，不用自己寻找和编译模式代码，可以方便查找类型
说明：
1. 所有的源代码来源自：http://www.hillside.net/patterns/DPBook/Source.html
2. 所有代码已经经过修改并在VC 8.0里编译通过，注意：链接不通过，但应该不影响大家的学习
3. 下载文件中包括工程文件。直接编译即可，但注意工程文件没有进行链接操作。
下载地址：
http://blog.vckbase.com/Files/eyesonyhm/Design Pattern Code.zip

[转帖] 软件设计--应遵循的原则

游游的家 — Thu, 27 Sep 2007 05:50:00 GMT

版本一：
引自：http://www.cnblogs.com/lizhiwen/archive/2007/07/25/831111.html
要把软件做得非常灵活又要便于维护是一个很困难的事情。灵活的软件他的结构就复杂，维护起来就困难。有得必有失，关键就在于如何处理这两者，使得大于失。软件的设计开发应遵循以下六大原则：

1. OCP

全称：“Open-Closed Principle” 开放－封闭原则

说明：对扩展开放，对修改关闭。

优点：按照OCP原则设计出来的系统，降低了程序各部分之间的耦合性，其适应性、灵活性、稳定性都比较好。当已有软件系统需要增加新的功能时，不需要对作为系统基础的抽象层进行修改，只需要在原有基础上附加新的模块就能实现所需要添加的功能。增加的新模块对原有的模块完全没有影响或影响很小，这样就无须为原有模块进行重新测试。

如何实现“开-闭”原则

在面向对象设计中，不允许更改的是系统的抽象层，而允许扩展的是系统的实现层。换言之，定义一个一劳永逸的抽象设计层，允许尽可能多的行为在实现层被实现。

解决问题关键在于抽象化，抽象化是面向对象设计的第一个核心本质。

对一个事物抽象化，实质上是在概括归纳总结它的本质。抽象让我们抓住最最重要的东西，从更高一层去思考。这降低了思考的复杂度，我们不用同时考虑那么多的东西。换言之，我们封装了事物的本质，看不到任何细节。

在面向对象编程中，通过抽象类及接口，规定了具体类的特征作为抽象层，相对稳定，不需更改，从而满足“对修改关闭”；而从抽象类导出的具体类可以改变系统的行为，从而满足“对扩展开放”。

对实体进行扩展时，不必改动软件的源代码或者二进制代码。关键在于抽象。

2. LSP

全称：“Liskov Substitution Principle” 里氏代换原则

说明：子类型必须能够替换它们的基类型。一个软件实体如果使用的是一个基类，那么当把这个基类替换成继承该基类的子类，程序的行为不会发生任何变化。软件实体察觉不出基类对象和子类对象的区别。

优点：可以很容易的实现同一父类下各个子类的互换，而客户端可以毫不察觉。

3. DIP

全称：“Dependence Inversion Principle”依赖倒置原则

说明：要依赖于抽象，不要依赖于具体。客户端依赖于抽象耦合。

抽象不应当依赖于细节；细节应当依赖于抽象；

要针对接口编程，不针对实现编程。

优点：使用传统过程化程序设计所创建的依赖关系，策略依赖于细节，这是糟糕的，因为策略受到细节改变的影响。依赖倒置原则使细节和策略都依赖于抽象，抽象的稳定性决定了系统的稳定性。

怎样做到依赖倒置？

以抽象方式耦合是依赖倒转原则的关键。抽象耦合关系总要涉及具体类从抽象类继承，并且需要保证在任何引用到基类的地方都可以改换成其子类，因此，里氏代换原则是依赖倒转原则的基础。

在抽象层次上的耦合虽然有灵活性，但也带来了额外的复杂性，如果一个具体类发生变化的可能性非常小，那么抽象耦合能发挥的好处便十分有限，这时可以用具体耦合反而会更好。

层次化：所有结构良好的面向对象构架都具有清晰的层次定义，每个层次通过一个定义良好的、受控的接口向外提供一组内聚的服务。

依赖于抽象：建议不依赖于具体类，即程序中所有的依赖关系都应该终止于抽象类或者接口。尽量做到：

1、任何变量都不应该持有一个指向具体类的指针或者引用。

2、任何类都不应该从具体类派生。

3、任何方法都不应该覆写它的任何基类中的已经实现的方法。

4. ISP

全称：“Interface Segregation Principle” 接口隔离原则

说明：使用多个专一功能的接口比使用一个的总接口总要好。从一个客户类的角度来讲：一个类对另外一个类的依赖性应当是建立在最小接口上的。过于臃肿的接口是对接口的污染，不应该强迫客户依赖于它们不用的方法。

优点：会使一个软件系统功能扩展时，修改的压力不会传到别的对象那里。

如何实现接口隔离原则

不应该强迫用户依赖于他们不用的方法。

1、利用委托分离接口。

2、利用多继承分离接口。

5. CARP or CRP

全称：“Composite/Aggregate Reuse Principle” 合成/聚合复用原则 or “Composite Reuse Principle” 合成复用原则

说明：如果新对象的某些功能在别的已经创建好的对象里面已经实现，那么尽量使用别的对象提供的功能，使之成为新对象的一部分，而不要自己再重新创建。新对象通过向这些对象的委派达到复用已有功能的。

简而言之，要尽量使用合成/聚合，尽量不要使用继承。

优点：

1) 新对象存取成分对象的唯一方法是通过成分对象的接口。

2) 这种复用是黑箱复用，因为成分对象的内部细节是新对象所看不见的。

3) 这种复用支持包装。

4) 这种复用所需的依赖较少。

5) 每一个新的类可以将焦点集中在一个任务上。

6) 这种复用可以在运行时间内动态进行，新对象可以动态的引用与成分对象类型相同的对象。

7) 作为复用手段可以应用到几乎任何环境中去。

缺点:

就是系统中会有较多的对象需要管理。

6. LOD or LKP

全称：“Law of Demeter” 迪米特原则 or “Least Knowledge Principle” 最少知识原则

说明：对象与对象之间应该使用尽可能少的方法来关联，避免千丝万缕的关系。

如何实现迪米特法则

迪米特法则的主要用意是控制信息的过载，在将其运用到系统设计中应注意以下几点：

1) 在类的划分上，应当创建有弱耦合的类。类之间的耦合越弱，就越有利于复用。

2) 在类的结构设计上，每一个类都应当尽量降低成员的访问权限。一个类不应当public自己的属性，而应当提供取值和赋值的方法让外界间接访问自己的属性。

3) 在类的设计上，只要有可能，一个类应当设计成不变类。

4) 在对其它对象的引用上，一个类对其它对象的引用应该降到最低。

还有个单一职责原则：

SRP简介（SRP--Single-Responsibility Principle）：

就一个类而言，应该只专注于做一件事和仅有一个引起它变化的原因。

所谓职责，我们可以理解他为功能，就是设计的这个类功能应该只有一个，而不是两个或更多。也可以理解为引用变化的原因，当你发现有两个变化会要求我们修改这个类，那么你就要考虑撤分这个类了。因为职责是变化的一个轴线，当需求变化时，该变化会反映类的职责的变化。

SRP优点：

消除耦合，减小因需求变化引起代码僵化性臭味

使用SRP注意点：

1、一个合理的类，应该仅有一个引起它变化的原因，即单一职责；
2、在没有变化征兆的情况下应用SRP或其他原则是不明智的；
3、在需求实际发生变化时就应该应用SRP等原则来重构代码；
4、使用测试驱动开发会迫使我们在设计出现臭味之前分离不合理代码；
5、如果测试不能迫使职责分离，僵化性和脆弱性的臭味会变得很强烈，那就应该用Facade或Proxy模式对代码重构；

版本二：

设计模式遵循的一般原则：

1.开-闭原则(Open-Closed Principle, OCP):一个软件实体应当对扩展开发,对修改关闭.说的是,再设计一个模块的时候,应当使这个模块可以在不被修改的前提下被扩展.换言之,应当可以在不必修改源代码的情况下改变这个模块的行为，在保持系统一定稳定性的基础上，对系统进行扩展。这是面向对象设计（OOD）的基石，也是最重要的原则。

2.里氏代换原则(Liskov Substitution Principle,常缩写为.LSP)
(1).由Barbar Liskov(芭芭拉.里氏)提出，是继承复用的基石。
(2).严格表达:如果每一个类型为T1的对象o1,都有类型为T2的对象o2,使得以T1定义的所有程序P在所有的对象o1都代换称o2时,程序P的行为没有变化,那么类型T2是类型T1的子类型.
换言之,一个软件实体如果使用的是一个基类的话,那么一定适用于其子类,而且它根本不能察觉出基类对象和子类对象的区别.只有衍生类可以替换基类，软件单位的功能才能不受影响，基类才能真正被复用，而衍生类也能够在基类的基础上增加新功能。
(3).反过来的代换不成立
(4).<墨子.小取>中说:"白马,马也; 乘白马,乘马也.骊马(黑马),马也;乘骊马,乘马也."
(5).该类西方著名的例程为:正方形是否是长方形的子类(答案是"否")。类似的还有椭圆和圆的关系。
(6).应当尽量从抽象类继承,而不从具体类继承,一般而言,如果有两个具体类A,B有继承关系,那么一个最简单的修改方案是建立一个抽象类C,然后让类A和B成为抽象类C的子类.即如果有一个由继承关系形成的登记结构的话,那么在等级结构的树形图上面所有的树叶节点都应当是具体类;而所有的树枝节点都应当是抽象类或者接口.
(7)."基于契约设计(Design By Constract),简称DBC"这项技术对LISKOV代换原则提供了支持.该项技术Bertrand Meyer伯特兰做过详细的介绍:
使用DBC,类的编写者显式地规定针对该类的契约.客户代码的编写者可以通过该契约获悉可以依赖的行为方式.契约是通过每个方法声明的前置条件(preconditions)和后置条件(postconditions)来指定的.要使一个方法得以执行,前置条件必须为真.执行完毕后,该方法要保证后置条件为真.就是说,在重新声明派生类中的例程(routine)时,只能使用相等或者更弱的前置条件来替换原始的前置条件,只能使用相等或者更强的后置条件来替换原始的后置条件.

3.依赖倒置原则(Dependence Inversion Principle),要求客户端依赖于抽象耦合.
(1)表述:抽象不应当依赖于细节,细节应当依赖于抽象.(Program to an interface, not an implementaction)
(2)表述二:针对接口编程的意思是说,应当使用接口和抽象类进行变量的类型声明,参量的类型声明,方法的返还类型声明,以及数据类型的转换等.不要针对实现编程的意思就是说,不应当使用具体类进行变量的类型声明,参量类型声明,方法的返还类型声明,以及数据类型的转换等.
   要保证做到这一点,一个具体的类应等只实现接口和抽象类中声明过的方法,而不应当给出多余的方法.
   只要一个被引用的对象存在抽象类型,就应当在任何引用此对象的地方使用抽象类型,包括参量的类型声明,方法返还类型的声明,属性变量的类型声明等.
(3)接口与抽象的区别就在于抽象类可以提供某些方法的部分实现,而接口则不可以,这也大概是抽象类唯一的优点.如果向一个抽象类加入一个新的具体方法,那么所有的子类型一下子就都得到得到了这个新的具体方法,而接口做不到这一点.如果向一个接口加入了一个新的方法的话,所有实现这个接口的类就全部不能通过编译了,因为它们都没有实现这个新声明的方法.这显然是接口的一个缺点.
(4)一个抽象类的实现只能由这个抽象类的子类给出,也就是说,这个实现处在抽象类所定义出的继承的登记结构中,而由于一般语言都限制一个类只能从最多一个超类继承,因此将抽象作为类型定义工具的效能大打折扣.
   反过来,看接口,就会发现任何一个实现了一个接口所规定的方法的类都可以具有这个接口的类型,而一个类可以实现任意多个接口.
(5)从代码重构的角度上讲,将一个单独的具体类重构成一个接口的实现是很容易的,只需要声明一个接口,并将重要的方法添加到接口声明中,然后在具体类定义语句中加上保留字以继承于该接口就行了.
   而作为一个已有的具体类添加一个抽象类作为抽象类型不那么容易,因为这个具体类有可能已经有一个超类.这样一来,这个新定义的抽象类只好继续向上移动,变成这个超类的超类,如此循环,最后这个新的抽象类必定处于整个类型等级结构的最上端,从而使登记结构中的所有成员都会受到影响.
(6)接口是定义混合类型的理想工具,所为混合类型,就是在一个类的主类型之外的次要类型.一个混合类型表明一个类不仅仅具有某个主类型的行为,而且具有其他的次要行为.
(7)联合使用接口和抽象类:
   由于抽象类具有提供缺省实现的优点,而接口具有其他所有优点,所以联合使用两者就是一个很好的选择.
   首先,声明类型的工作仍然接口承担的,但是同时给出的还有一个抽象类,为这个接口给出一个缺省实现.其他同属于这个抽象类型的具体类可以选择实现这个接口,也可以选择继承自这个抽象类.如果一个具体类直接实现这个接口的话,它就必须自行实现所有的接口;相反,如果它继承自抽象类的话,它可以省去一些不必要的的方法,因为它可以从抽象类中自动得到这些方法的缺省实现;如果需要向接口加入一个新的方法的话,那么只要同时向这个抽象类加入这个方法的一个具体实现就可以了,因为所有继承自这个抽象类的子类都会从这个抽象类得到这个具体方法.这其实就是缺省适配器模式(Defaule Adapter).
(8)什么是高层策略呢?它是应用背后的抽象,是那些不随具体细节的改变而改变的真理. 它是系统内部的系统____隐喻.

4.接口隔离原则(Interface Segregation Principle, ISP)
（1）一个类对另外一个类的依赖是建立在最小的接口上。

（2）使用多个专门的接口比使用单一的总接口要好.根据客户需要的不同,而为不同的客户端提供不同的服务是一种应当得到鼓励的做法.就像"看人下菜碟"一样,要看客人是谁,再提供不同档次的饭菜.
（3）胖接口会导致他们的客户程序之间产生不正常的并且有害的耦合关系.当一个客户程序要求该胖接口进行一个改动时,会影响到所有其他的客户程序.因此客户程序应该仅仅依赖他们实际需要调用的方法.

5.合成/聚合复用原则(Composite/Aggregate Reuse Principle,CARP)
在一个新的对象里面使用一些已有的对象,使之成为新对象的一部分;新的对象通过这些向对象的委派达到复用已有功能的目的.这个设计原则有另一个简短的表述:要尽量使用合成/聚合,尽量不要使用继承.

6.迪米特法则(Law of Demeter LoD)又叫做最少知识原则(Least Knowledge Principle,LKP),就是说,一个对象应当对其他对象有尽可能少的了了解.
迪米特法则最初是用来作为面向对象的系统设计风格的一种法则,与1987年秋天由Ian Holland在美国东北大学为一个叫做迪米特(Demeter)的项目设计提出的,因此叫做迪米特法则[LIEB89][LIEB86].这条法则实际上是很多著名系统,比如火星登陆软件系统,木星的欧罗巴卫星轨道飞船的软件系统的指导设计原则.
没有任何一个其他的OO设计原则象迪米特法则这样有如此之多的表述方式,如下几种:
(1)只与你直接的朋友们通信(Only talk to your immediate friends)
(2)不要跟"陌生人"说话(Don't talk to strangers)
(3)每一个软件单位对其他的单位都只有最少的知识,而且局限于那些本单位密切相关的软件单位.
就是说,如果两个类不必彼此直接通信,那么这两个类就不应当发生直接的相互作用,如果其中的一个类需要调用另一个类的某一个方法的话,可以通过第三者转发这个调用。

7.单一职责原则(Simple responsibility pinciple SRP)
就一个类而言,应该仅有一个引起它变化的原因,如果你能想到多于一个的动机去改变一个类,那么这个类就具有多于一个的职责.应该把多于的指责分离出去,分别再创建一些类来完成每一个职责.

另外：常说的OO五大原则就是指其中的：1、单一职责原则；2、开放闭合原则；3、里氏替换原则；4、依赖倒置原则；5、接口隔离原则。

[转帖] 软件设计--应该避免的问题

游游的家 — Thu, 27 Sep 2007 05:45:00 GMT

引自：http://www.cnblogs.com/lizhiwen/archive/2007/05/31/766434.html

软件开发出来后，无非就两大团体来接触他。一个是用户，一个是开发者。所以在设计软件的时候这两个团体要同时考虑，从各个角度来权衡每个设计点的偏重点。

开发的软件是给用户操作的，用户每天都要与之打交道，所以界面的美观性，功能的实用性，操作的简易性，数据传递的速度以及比较贴近的业务逻辑对于用户来讲都是很重要的。

而对于开发者来说，软件开发完成后并不是就不用管了，软件的后期维护也是一项很重要，很繁琐的事情。用户会随着时间的推移，不断的改变着他的需求，要你对软件进行改进。当然，你会把一些需求挡回去，把一些需求通过现有的条件变种方式来实现，但总有一些你需要增加或修改。这时，你的软件在开始设计的时候是不是够灵活，在你修改的时候便知道了。

如果维护的软件让你头疼，宁愿重新开发也不愿意去修改，那就说明这个软件设计的很不成功。

要想让软件不发生腐化，使以后的维护工作更加容易，那么设计软件的时候应该尽量避免以下几个问题：

1.僵化性（Rigidity）：设计难以改变

当用户提出一个新的需求时，需要对程序的一些地方进行改动，可当你打开代码，发现虽然是添加一个很小的功能，却牵涉到了很多地方。这样单一的改动导致有依赖关系的模块中的连锁改动，那么设计就是僵化的。没人愿意为了一小块玉石而去移掉整座山，愚公移山的精神在这里不值得发扬。

2.脆弱性（Fragility）：设计易于遭到破坏

用户想要添加的功能改完了，然后重新进行测试，这时却发现跟这个新加功能没有概念性关联的其他功能发生了错误。而去修正这些问题又会引出更多的问题。就像在玻璃上钉钉子--越钉越碎。

3.牢固性（Immobility）：设计难以重用

同类系统，总是会有许多相似的地方，甚至有些地方完全相同。当作完一个项目后，又接了一个项目，这两个项目功能方面很相似，只是给不同的客户用，业务逻辑上稍有不同，但是在人员管理和权限管理上基本一致。这时你想把之前的项目中人员管理和权限管理这部分拷过来改改就用，却发现改动的工作量相当巨大，还不如重新作，这就说明之前的项目在设计时重用性能太差了。

4.粘滞性（Viscosity）：难以做正确的事情

改动一个功能时，往往会有多种改动的方法。其中一些方法会保持初始的设计，另外一些方法会破坏初始的设计。按照常理来说，一般会选择保持初始设计的方法，可是你却发现那些保持设计的方法的改动比那些破坏设计方法的改动更难以对付，这就表明初始设计具有高粘滞性。

5.不必要的复杂性（Needless Complexity）：过分设计

不是说越复杂的软件就是好软件，现在的电器还不是功能越多，越容易坏吗！软件也是一样，设计的越复杂，逻辑就会很繁杂，开发起来也会很费时间。本来一个类型列表页面只有三个字段，最多不过10条记录，你非要在页面上加上一个翻页控件，这不是画蛇添足吗！

6.不必要的重复（Needless Repetition）：滥用鼠标（乱拷贝）

拷贝和粘贴确实是能提高开发效率，但是有时会造成过分的滥用。系统中有一个计算总金额的公式过程，在很多地方要用到，于是每个开发人员都

拷贝粘贴到自己的程序里，过了一段时间，国家下政策了，调息了，计算公式要改动，这下大家傻眼了，满“项目”找这个公式过程。费时费力。

7.晦涩性（Opacity）：混乱的表达

开发的模块难以让别人理解。一个软件有时要经过很多开发人员编写，如果模块的命名和编程的格式都按照自己的方式来进行开发，时间一久，愈是往后接手的开发人员就越痛苦，打开代码，根据里面的命名都不知道这段代码是干什么用的，总是要花很多时间先来理解代码。