文章目录
一、面向对象基础
(一)面向对象的基本概念
-
对象:基本的运行时的实体。通常可由对象名、属性(状态)和方法三部分组成。
-
消息:对象之间进行通信的一种构造。
-
类:定义一组大体上相似的对象,包含方法和数据。可以分为实体类、接口类(边界类)和控制类三种。
-
继承:父类和子类之间共享数据和方法的机制。根据语言不同可能包括“单重继承”和“多重继承”。
-
多态:不同的对象收到同一消息可以产生完全不同的结果,实现受继承机制的支持。
a. 通用的多态:参数多态、包含多态(子类型化)。
b. 特定的多态:过载多态(同一名字上下文含义不同)、强制多态。
-
动态绑定:编译时进行的绑定叫作静态绑定,运行时进行的绑定叫作动态绑定。
(二)面向对象分析(OOA)
- 面向对象分析的活动:认定对象、组织对象。、对象间的相互作用、基于对象的操作。
(三)面向对象设计(OOD)
-
面向对象设计的活动:识别类及对象、定义属性、定义服务、识别关系、识别包。
-
面向对象设计的原则。
a. 单一责任原则。
b. 开放-封闭原则:软件实体应该是可以扩展的,但是不可修改的。
c. 里氏替换原则:子类必须能替换父类。
d. 依赖倒置原则:抽象不应该依赖于细节,细节应该依赖于抽象。
e. 接口分离原则:不应强迫客户依赖于它们不用的方法。依赖于抽象,不要依赖于具体。
f. 共同封闭原则:包中所有类对于同一性质的变化应该是共同封闭的。
g. 共同重用原则:一个包中的所有类应该是共同重用的。
(四)面向对象程序设计(OOP)
-
类。
-
继承和类层次结构。
-
对象、消息传递和方法。
-
对象自身引用。
-
重置。
-
类属类。
-
无实例的类。
(五)面向对象测试
- 面向对象测试可分为四个层次:算法层、类层、模板层、系统层。
二、UML
(一)基本概念
-
UML构成:UML的基本构造块、支配这些构造块如何放置在一起的规则、运用于整个语言的一些公共机制。
-
UML的3种构造块:事物、关系、图。
(一)事物
-
结构事物:模型的静态部分,描述概念或物理元素。包括类、接口、协作、用例、主动类、构件、制品、结点。
-
行为事物:模型的动态部分,描述跨越时间和空间的行为。包括交互、状态机、活动。
-
分组事物:模型的组织部分。最主要的分组事物是包。
-
注释事物:模型的解释部分。注解是一种主要的解释事物。
(二)关系
-
依赖: 两个事物间的语义关系,独立事物发生变化会影响依赖事物的语义。
-
关联:一种结构关系,它描述了一组链,链是对象之间的连接。聚集是一种特殊类型的关联,描述整体和部分间的结构关系。在关联上可以标注重复度和角色。
a. 聚合:部分和整体的生命周期不一致,部分可以脱离整体存在。
b. 组合:部分和整体的生命周期一致,部分不可以脱离整体存在。
-
泛化:一种特殊/一般关系,特殊元素(子元素)可以替代一般元素(父元素)的对象。
-
实现:类元之间的语义关系,其中一个类元指定了由另一个类元保证执行的契约。
(三)UML中的图
- 类图:展现一组对象、接口、协作和它们之间的关系,给出系统的静态设计视图。类图通常包括类、接口、协作、依赖/泛化/关联关系。使用类图可以对系统的词汇建模、对简单的协作建模、对逻辑数据库模式建模。
-
对象图:展现某一时刻一组对象以及它们之间的关系,描述了在类图中所建立的事物的实例的静态快照。对象图一般包括对象和链。使用对象图可以对对象结构进行建模。
-
用例图:展现一组用例、参与者以及它们之间的关系。用例图通常包括用例、参与者、用例之间的扩展和包含关系/参与者和用例之间的关联关系/用例与用例以及参与者与参与者之间的泛化关系。使用用例图可以对系统的语境建模、对系统的需求建模。
-
交互图:用于对系统的动态方面进行建模,表现为序列图、通信图、交互概览图和计时图。交互图一般包括对象、链、消息。交互图可以用来对一个用例的特定的控制流进行建模。
a. 序列图是强调消息时间顺序的交互图。相较通信图,序列图有对象生命线、控制焦点。
b. 通信图是强调接收和发送消息的对象的结构组织的交互图。相较序列图,通信图有路径、顺序号。
c. 交互概览图。d. 计时图。
-
状态图:展现一个状态机,它由状态、转换、事件和活动组成,关注系统的动态视图。状态图通常包括简单状态和组合状态、转换(事件和动作)。使用状态图可以对反应型对象建模。
-
活动图:一种特殊的状态图,展现了在系统内从一个活动到另一个活动的流程。活动图一般包括活动状态和动作状态、转换和对象。使用活动图可以对工作流建模、对操作建模。
-
构件图(组件图):展现一组构件之间的组织和依赖,专注于系统的静态实现视图,与类图相关。
-
组合结构图。
-
部署图:用来对面向对象系统的物理方面建模的方法,展现运行时处理节点以及其中构件(制品)的配置,与构件图相关,通常在实施阶段使用。部署组件之间的依赖关系类似于包依赖。
-
包图。
三、设计模式
(一)设计模式的要素
-
设计模式的核心在于提供相关问题的解决方案,是的可以更加简单方便地复用成功的设计和体系结构。
-
设计模式一般有4个基本要素:模式名称、问题、解决方案、效果。
-
按照设计模式的目的进行分类。(丹丹原本想去工厂买瓶生抽)
(二)创建型设计模式
-
Factory Method(工厂方法):定义一个用于创建对象的接口,让子类决定实例化哪个类。Factory Method使一个类实例化延迟到其子类。
-
Abstract Factory(抽象工厂):提供一个创建一系列相关或相互依赖对象的接口,而无需指定它们具体的类。
-
Builder(生成器):将一个复杂对象的构建与它的表示分离,使得同样的构建过程可以创建不同的表示。
-
Prototype(原型):用原型实例指定创建对象的种类,并且通过复制这些原型创建新的对象。
-
Singleton(单例):保证一个类仅有一个实例,并且提供一个访问它的全局访问点。
(三)结构型设计模式
-
Adapter(适配器):将一个类的接口转换成客户希望的另一个接口,使得原本由于接口不兼容而不能一起工作的那些类可以一起工作。
-
Bridge(桥接):将抽象部分与其实现部分分离,使它们都可以独立地变化。
-
Composite(组合):将对象组合成树型结构以表示“部分-整体”的层次结构,是的对象对单个对象和组合对象的使用具有一致性。
-
Decorator(装饰):动态地给一个对象添加一些额外的职责,增加功能方面会比生成子类更加灵活。
-
Facade(外观):为子系统中的一组接口提供一个一致的界面,定义了一个高层接口使得子系统更加容易使用。
-
Flyweight(享元):运用共享技术有效地支持大量细粒度的对象。
-
Proxy(代理):为其他对象提供一种代理以控制对这个对象的访问。
(四)行为型设计模式
-
Interpreter(解释器):给定一个语言,定义它的文法的一种表示,并定义一个解释器使用该表示来解释语言中的句子。
-
Template Method(模板方法):定义一个操作中的算法骨架,而将一些步骤延迟到子类中,使得子类可以不改变一个算法的结构即可重新定义该算法的某些特定步骤。
-
Chain of Responsibility(责任链):使多个对象都有机会处理请求,从而避免请求的发送者和接收者之间的耦合关系。
-
Command(命令):将一个请求封装为一个对象,从而使得可以用不同的请求对客户进行参数化,对请求排队或记录请求日志,以及支持可撤销的操作。
-
Iterator(迭代器):提供一种方法顺序访问一个聚合对象中的各个元素,且不需要暴露该对象的内部表示。
-
Mediator(中介者):用一个中介对象来封装一系列的对象交互,中介者使各对象不需要显式地相互引用,从而使求和松散,而且可以独立地改变它们之间的交互。
-
Memento(备忘录):在不破坏封装性的前提下捕获一个对象的内部状态,并在对象之外保存这个状态,以后就可以将对象恢复到原先保存的状态。
-
Observer(观察者):定义对象间的一种一对多的依赖关系,当一个对象的状态发生改变时,所有依赖于它的对象都得到通知并被自动更新。
-
State(状态):允许一个对象在其内部状态改变时改变它的行为,对象看起来似乎修改了它的类。
-
Strategy(策略):定义一系列的算法,把它们一个个封装起来,并且使他们可以相互替换,使得算法可以独立于使用它们的客户而变化。
-
Visitor(访问者):表示一个作用于某对象结构中的各元素的操作,允许在不改变各元素的类的前提下定义作用于这些元素的新操作。
. State(状态):允许一个对象在其内部状态改变时改变它的行为,对象看起来似乎修改了它的类。 -
Strategy(策略):定义一系列的算法,把它们一个个封装起来,并且使他们可以相互替换,使得算法可以独立于使用它们的客户而变化。
-
Visitor(访问者):表示一个作用于某对象结构中的各元素的操作,允许在不改变各元素的类的前提下定义作用于这些元素的新操作。