前言
我写这篇博文,是对我研一这一学期到现在,学习设计模式的总结。我自己使用的是程杰写的《大话设计模式》这本书,我会跟据这本书,对自己这么多天学习到的知识做一个总结。
目前,第一篇先总结前三章。涉及到的只是有:第一章讲述的UML类图和简单工厂模式,第二章的策略模式和第三章的单一职责原则。首先,先来看第一章地1.11节的UML类图。
UML类图
类图
类图分为三层,第一层是类名;第二层是类特性,即类成员;第三层则是列操作,即类的成员函数。其中,+表示public,-表示private,#表示protected。
接口图
接口图分为两层,第一层以<<interface>>打头,接接口名,用来指明这是一个接口。第二层则是接口方法。
连接线
- 类间的继承关系用带有空心三角形的实线表示。
- 实现具体的接口用带有空心三角的虚线表示。
- 关联关系用实线箭头表示。所谓关联关系,可以是友元类的关系。
- 聚合关系使用空心菱形和实线箭头组合来表示。聚合关系表示一种弱拥有关系,例如A包含B,但B对象不一定是A对象的一部分。用文氏图来表示,那A和B是相交的关系。
- 合成关系用实心菱形和实线箭头组合来表示。合成关系是一种强拥有关系,是严格的整体和部分的关系且部分与整体的生命周期是一致的。用文氏图来表示,A和B是包含关系。
- 依赖关系用虚线箭头表示。
书中12页示例图如下所示:
简单工厂模式
1.4节指出,面向对象和设计模式是因为解决代码不容易维护,不容易扩展,不容易复用和灵活性差的问题的。
1.6节指出通过封装、继承和多态把程序耦合度降低,使用设计模式使得使得程序更加机灵活,易于修改和复用。
简单工厂模式考虑用一个单独的类来做这个创造实例的过程。这个类就像是工厂批量生产产品一样,得名简单工厂模式。在1.10节里,OperationFactory类(操作符工厂类)就是为计算器功能生产各种运算功能的工厂类。
书上的参考代码是这样的,以加法为例,将numberA与numberB相加:
Operation oper;
oper = OperationFActory.createOperate('+');
oper.NumberA = 1;
oper.NumberB = 2;
double result = oper.GetResult();
策略模式
第二章,用一个商场促销软件引入,说明简单工厂迷失虽然也可以使用,但是简单工厂模式只是针对对象创建问题而提出的。促销软件包括了所有类似的收费模式,而每个收费模式类似第一章不同的操作符。但有一点不同的是,打折的计费方式是多种多样的,而每次采用新的收费模式时都需要改动工厂类,就违反了封装的要求,所有才需要使用策略模式。
策略模式定义了家族算法,分别封装起来,让他们之间可以互相替换。这个模式让算法变化不会影响使用算法的客户。
策略模式结构图如下:
总之,策略模式是一种定义一系列算法的方法,从概念上来看,所有这些算法完成的都是类似的工作,算法实现不同,程序员调用这些算法时的调用方式是一样的,这样可以减少各种算法类与使用算法的类之间的耦合。且在测试的时候也更加方便测试人员的调试,其实本萌新最早些项目,最近常使用的也是策略模式,将各个功能单独写成函数,一一测试,来判断哪里出错了。要是连在一起写debug时候会把自己累死。
可以这么认为工厂模式封装了生产各种对象的类成员函数,而策划略模式是封装项目里的逻辑功能函数。
单一职责原则
单一职责原则:就一个类而言应该仅有一个引起它变化的原因。简单来说,一个类就因该只负责单一的责任,例如工厂类A只负责产生类似的对象,而工厂类B负责产生另一种类似的对象,这一类对象不同于工厂A产生的对象。
文中3.5节举了俄罗斯方块的例子,说明了界面和游戏逻辑函数不该写在一个类里的原因:如果一个类承担的职责过多,就等同于这些职责会耦合在一起,一个职责的变化可能会削弱或者抑制这个类完成其他职责的能力。这种耦合导致脆弱的设计,当发生变化时,会引发大量的修改。
这一章节只有4页没有实例代码,主要是称述了单一职责原则的含义。
结语
目前我看到了17章,我会按时复习总结,并更新相应的复习记录,希望自己在毕业的时候能拿到满意的薪资!!!