面向对象设计
UML
矩形框
- 第一层:类的名称,若为抽象类,斜体显示
- 第二层:类的特性,通常是字段和属性
- 第三层:类的操作,通常是方法或行为
- 符号:'+':public, '-':private,'#':protected
类与类之间的关系
- 继承:空心三角形+实线
关联:实线箭头
双向的关联关系
单向的关联关系
关系是固定的 A has B
彼此并不负责对方的生命周期
一般使用指针或者引用
聚合:空心菱形+实线箭头
- 比较强的一种关联关系
- 对象之间的关系表现为分为整体和局部
- 整体部分并不负责局部对象的销毁
- 合成(组合)关系:实心的菱形+实线箭头
- 更强的一种关联关系
- 对象之间的关系表现为分为整体和局部
- 整体部分负责局部对象的销毁
- A has B
- 依赖关系:虚线+箭头
- 从语义上来说是 A use B,是偶然的,临时的,并非固定的
- B作为A的成员函数参数
- B作为A的成员函数的局部变量
- A的成员函数调用B的静态方法
各关系的比较
耦合强弱:
依赖 < 关联 < 聚合 < 组合从语义上来看
继承(A is B)
关联、聚合、组合(A has B)
依赖(A use B)
SOLID的5原则
单一职责原则
核心思想:一个类,最好只做一件事,只有一个引起它变化的原因。
如果一个类承担的职责过多,就等于把这些职责耦合在一起,一 个职责的变化可能会削弱或者抑制这个类完成其它职责能力。这种耦合会导制脆弱的设计,当变化发生时,设计会遭受到意想不到的破坏。
如果你能够想到多于一个的动机去改变一个类,那么这个类就具有多于一个的职责。
举例
Rectangle类做了下面两件事:
计算矩形面积;
在界面上绘制矩形;
有两个应用使用了Rectangle类:
计算几何应用程序用这个类计算面积;
图形程序用这个类在界面上绘制矩形;
开放-封闭原则
核心思想:对扩展开放,对修改封闭。
软件实体可以扩展,但是不可修改。即对于扩展是开放的,对于修改是封闭的。面对需求,对程序的改动是通过增加代码来完成的,而不是改动现有的代码。
当变化发生时,我们就创建抽象来隔离以后发生同类的变化。
开放――封闭原则是面向对象的核心所在。开发人员应该对程序中呈现出频繁变化的那部分做出抽象,拒绝对任何部分都刻意抽象及不成熟的抽象。
里氏代换原则
核心思想:子类型必须能够替换掉它们的父类型。
实现的方法是面向接口编程:将公共部分抽象为基类接口或抽象类,通过提取抽象类,在子类中通过覆写父类的方法实现新的方式支持同样的职责。
依赖倒转原则
核心思想:面向接口编程,依赖于抽象。
抽象不应该依赖细节,细节应该依赖抽象。即针对接口编程,不要对实现编程。
高层模块不能依赖低层模块,两者都应依赖抽象。
当两个模块之间存在紧密的耦合关系时,最好的方法就是分离接口和实现:在依赖之间定义一个抽象的接口使得高
层模块调用接口,而底层模块实现接口的定义,以此来有效控制耦合关系,达到依赖于抽象的设计目标。
举例
接口分离原则
核心思想:使用多个小的专门的接口,而不要使用一个大的总接口。
举例
IBird接口包含很多鸟类的行为,包括Fly()行为。现在如果一个Bird类(如Ostrich)实现了这个接口,那么它需要实现不必要的Fly()行为(Ostrich不会飞)。
这个"胖接口"应该拆分未两个不同的接口,IBird和IFlyingBird,IFlyingBird继承自IBird。
设计模式
分类:
创建型设计模式:主要用于描述如何创建对象
结构型设计模式:主要用于描述如何实现类和对象的组合
行为型设计模式:主要用于描述类或对象怎样交互以及怎样分配职责
每一位软件开发人员也都希望成为一名兼具淋漓招式和深厚内功的“上乘”软件工程师,而对设计模式的学习与领悟将会让你“内功”大增,再结合你日益纯熟的“招式”,你的软件开发“功力”一定会达到一个新的境界。