1.在C++中,类的继承主要由如下3种方式:
继承方式 | 公有成员 | 私有成员 | 保护成员 | 备注 |
---|---|---|---|---|
公有继承(public) | 公有成员 | 私有成员 | 保护成员 | 保持原有状态 |
私有继承(private) | 私有成员 | 基类私有,不能被继承 | 私有成员 | 公有成员和保护成员作为派生类 的私有成员,不能被派生类所访问 |
保护继承(protected) | 保护成员 | 基类私有,不能被继承 | 保护成员 | 派生类中的保护成员只能被成员 函数和友元访问 |
总结:基类成员对派生类的对象来说,是否能被访问,就要看基类的成员在派生类中变成了什么类型的成员。
2.面向对象分析和设计的活动
名称 | 基础 | 概念 | 活动/作用 |
---|---|---|---|
面向对象分析 | 基于用例模型 | 通过对象建模记录确定的对象、对象封装的数据 和行为以及对象之间的关系。 | 建模系统功能、 发现并且确定业务对象、 组织对象并确定其关系 |
面向对象设计 | 在分析对象模型的基础上 | 设计各个对象、对象之间的关系(如层次关系、继承关系等)和通信方式(如消息模式)等 | 其主要作用是对OOA的结果作进一步规范化整理 |
3.静态成员和普通成员区别较大,体现在以下几点:
(1)普通数据成员属于类的一个具体的对象,只有对象被创建了,普通数据成员才会被分配内存。静态数据成员属于整个类,即使没有任何对象创建,类的静态数据成员变量也存在。
(2)外部访问类的静态成员只能通过类名来访问。
(3)类的静态成员函数无法直接访问普通数据成员(可以通过类的指针等作为参数间接访问),而类的任何成员函数都可以访问类的静态数据成员。
(4)类的静态方法只能访问该类的静态数据成员。
补充:静态成员和类的普通成员一样,也具有public、protected、private 3中访问级别,也可以具体返回值及被修改等性质。
4.UML的系统视图:
UML对系统架构的定义是系统的组织结构,包括系统分解的组成部分,以及它们的关联性、交互机制和指导原则等提供系统设计的信息。
名称 | 作用 |
---|---|
逻辑视图(设计视图) | 表示设计模型中在架构方面具有重要意义的部分,即类、子系统、包和用例实现的子集。 |
进程视图 | 进程视图是可执行线程和进程作为活动图的建模,是逻辑视图的一次执行实例,描述了并发和同步结构。 |
实现视图 | 实现视图对组成基于系统的物理代码的文件和构件进行建模。 |
部署视图 | 部署视图把构建部署到一组物理结点上,表示软件到硬件的映射和分布结构。 |
用例视图 | 用例视图是最基本的需求分析模型。 |
5.构造函数与析构函数的特征
在定义一个对象的同时,希望能给它的数据成员赋初值—对象的初始化。在特定对象使用结束时,还经常需要进行一些清理工作。C++程序中的初始化和清理工作分别由两个特殊的成员函数来完成,即构造函数与析构函数。
函数名称 | 作用 | 概念 | 性质 | 个数 |
---|---|---|---|---|
构造函数 | 数据成员赋初值——对象的初始化 | 如果在定义时,没有为类定义构造函数,编译系统会生成一个默认形成的隐含的构造函数,这个构造函数的函数体是空的,因此默认构造函数不具备任何功能。且构造函数为类的一个成员函数,具有一般成员函数的性质。 | 1.构造函数的函数名必须与定义它的类同名 2.构造函数没有返回值 3.构造函数被声明定义为公有函数 4.构造函数在建立对象时由系统自动调用 | 一个类可拥有多个 构造函数,只要参数个数 和参数类型不同即可 |
析构函数 | 在特定对象结束时,进行清理工作 | 析构函数也叫拆构函数,是在对象消失之前的瞬间自动调用的函数 | 1.析构函数没有任何参数,不能被重载,但可以是虚函数 2.析构函数没有返回值 3.析构函数名与类名相同,但在类名钱加上一个逻辑非运算符"~",以表示与构造函数的区别 | 一个类只能有一个析构函数 |
6.用例之间的基本关系
(1)包含关系:当可以从两个或两个以上的用例中提取公共行为时,应该使用包含关系。 其中这个提取出来的公共用例称为抽象用例,而把原始用例称为基本用例或基础用例。包含关系的一个重要特征,就是被抽象出来的用例是基础用例必须的部分,不可或缺。
(2)扩展关系:如果一个用例明显地混合了两种或两种以上的不同场景,即根据情况可能发生多种分支,则可以将这个用例分为一个基本用例和一个或多个扩展用例。 扩展关系的一个重要特征,就是抽取的用例相对于基础用例来说不是必须的。
(3)泛化关系:当多个用例共同拥有一种类似的结构和行为的时候,可以将它们的共性抽象为父用例,其他的用例作为泛化关系中的子用例。 在用例的泛化关系中,子用例是父用例的一种特殊形式,子用例继承了父用例所有的结构、行为和关系。例如:某学员进行课程注册时,假设既可以通过现场注册,也可以通过网上注册,则“注册课程”的用例就是“现场注册”用例和“网上注册”用例的泛化。
7.UML 2.0包括的14种图
名称 | 概念 | 作用 | 备注 |
---|---|---|---|
类图 | 类图描述了一组类、接口、协作和它们之间的关系 | 类图给出了系统的静态设计视图,活动类的类图给出了系统的静态进程视图 | |
对象图 | 对象图描述了一组对象及他们之间的关系以及在类图中所建立的事物实例的静态快照 | 对象图给出了系统的静态设计视图和静态进程视图 | 它们都是从真实案例或原型案例的角度建立的。 |
构件图 | 构件图描述了一个封装的类和它的接口、端口,以及由内嵌的构件和连接件构成的内部结构 | 构件图用于表示系统的静态设计实现视图 | 构件图是类图的变体 |
组合结构图 | 组合结构图描述结构化类(如构件或类)的内部结构,包括结构化类与系统其余部分的交互点 | 用于画出结构化类的内部内容 | |
用例图 | 用例图描述了一组用例、参与者及它们之间的关系。 | 用例图给出系统的静态用例视图 | |
顺序图 | 顺序图是强调消息的时间次序的交互图 | 交互图(系统的动态视图) | |
通信图(协作图) | 协作图不但描述了对象之间的交互还描述了交互的对象之间的链接关系,即通信图同时反映了系统的动态和静态特征 | 通信图强调收发消息的对象或参与者的结构组织,反映了对象之间的消息交互 | 交互图 |
定时图 | 强调消息跨越不同对象或参与者的实际时间,而不仅仅是关系消息的相对顺序 | 交互图 | |
状态图 | 状态图描述一个状态机,由状态、转移、事件和活动组成 | 状态图给出了对象的动态视图,它对于接口、类或协作的行为建模尤为重要,而且它强调事件导致的对象性行为,有助于对反应式系统建模 | |
活动图 | 活动图将进程或其他计算结构展示位计算内部一步步的控制流和数据流。 | 活动图专注于系统的动态视图,它对于系统的功能建模和业务流程建模特别重要,并强调对相见的控制流程 | |
部署图 | 部署图描述对运行时的处理结点及在其中生存的构件的配置 | 部署图给出了架构的静态部署视图,通常一个结点包含一个或多个部署图 | |
制品图 | 制品图描述计算机中一个系统的物理结构,制品包括文件、数据库和类似的物理比特集合 | 制品图通常与部署图一起使用,制品也给出了它们实现的类和构件 | |
包图 | 包图描述由模型本身分解而成的组织单元,以及它们之间的依赖关系 | ||
交互概览图 | 交互概览图是活动图和顺序图的混合物 交互图 |
结构性视图(静态) 主要是对系统中的结构成员及其相互关系进行描述 | 行为性视图(动态) 描述了系统随时间变化的行为 |
---|---|
类图、对象图、包图、组合结构图、构件图、部署图和制品图 | 用例图、顺序图、通信图、定时图、状态图、活动图、交互概览图 |
8. 23种设计模式
“每一个模式描述了一个在我们周围不断重复发生的问题,以及该问题的解决方案的核心。这样,你就能一次又一次地使用该方案而不必做重复劳动”。设计模式的核心在于提供了相关问题的解决方案,使得人们可以更加简单方便地复用成功的设计和体系结构。
设计模式分类
创建型 | 结构型 | 行为型 | |
---|---|---|---|
类 | Factory Method(工厂方法) | Adapter(类) | Interpreter(解释器) |
对象 | Abstract Factory(抽象工厂) Builder(生成器) Prototype(原型) Singleton(单例) | Adapter(对象) Bridge(桥接) Compisite(组合) Decorator(装饰) Facade(外观) Flyweight(享元) Proxy(代理) | Chain of Responsibility(责任链) Command(命令) Iterator(迭代器) Mediator(中介者) Memento(备忘录) Observer(观察者) State(状态) Strategy(策略) Visitor(访问者) |
设计模式总结
名称 | 意图 | 适用性 |
---|---|---|
Abstract Factory 抽象工厂 | 提供一个创建一系列相关或相互依赖对象的接口,而无需指定它们具体的类 | 1.一个系统要独立于它的产品的创建、组合和表示时 2.一个系统要由多个产品系列中的一个来配置时 3.当要强调一系列相关的产品对象的设计以便进行联合使用时 4.当提供一个产品类库,只想显示它们的接口而不是实现时 |
Builder 生成器 | 将一个复杂对象的构件与它的表示分离,使得同样的构建过程可以创建不同的表示 | 1.当创建复杂对象的算法应该独立于该对象 的组成部分以及它们的装配方式时 2.当构造过程必须允许被构造的对象有不同的表示时 |
Factory Method 工厂方法 | 定义一个用于创建对象的接口,让子类决定实例化哪一个类,使一个类的 实例化延迟到其子类 | 1.当一个类不知道它所必须创建的对象的类的时候 2.当一个类希望由它的子类来指定它所创建的对象的时候 3.当类将创建对象的职责委托给多个帮助子类中的某一个,并且你希望将哪一个帮助子类是代理者这一信息局部化的时候 |
Prototype 原型 | 用原型实例指定创建对象的种类,并且通过复制这些原型创建新的对象 | 1.当一个系统应该独立于它的产品创建、构成和表示时 2.当要实例化的类是在运行时刻指定时,例如,通过动态装载 3.为了避免创建一个与产品类层次平行的工厂类层次时 4.当一个类的实例只能有几个不同状态组合中的一种时。建立相应数目的原型并克隆它们,可能比每次用合适的状态手工实例化该类更方便一些 |
Singleton 单例 | 保证一个类仅有一个实例,并提供一个访问它的全局访问点 | 1.当类只能有一个实例而且客户可以从一个众所周知的访问点访问它时 2.当这个唯一实例应该是通过子类化可扩展的,并且客户无需更改代码就能使用一个扩展的实例时 |
Adapter 适配器 | 将一个类的接口转换成客户希望的另外一个接口。Adapter模式使得原本由于接口不兼容而不能一起工作的那些类可以一起工作 | 1.想使用一个已经存在的类,而它的接口不符合要求 2.想创建一个可以服用的类,该类可以与其他不想管的类或不可预见的类(即那些接口可能不一定兼容的类)协同工作 3.(仅适用于对象Adapter)想使用一个已经存在的子类,但是不可能对每一个都进行子类化以匹配它的接口。对象适配器可以适配它的父类接口 |
Bridge 桥接 | 将抽象部分与其实现部分分离,使它们都可以独立地变化 | 1.不希望在抽象和它的实现部分有一个固定的绑定关系。例如,这种情况可能是因为,在程序运行时刻实现部分应可以被选择或切换 2.类的抽象以及它的实现都应该可以通过生成子类的方法加以扩充。这是Bridge模式使得开发者可以对不同的抽象接口和实现部分进行组合,并分别对它们进行扩充 3.对一个抽象的实现部分的修改应对客户不产生影响,即客户代码不必重新编译 4.(C++)想对客户完全隐藏抽象的实现部分 5.有许多类要生成的类层次结构 6.想在多个对象间共享实现(可能引用计数),但同时要求客户并不知道这一点 |
Composite 组合 | 将对象组合成树形结构以表示“部分-整体”的层次结构。Composite使得用户对单个对象和组合对象的使用具有一致性 | 1.想表示对象的部分-整体层次结构 2.希望用户忽略组合对象与单个对象的不同,用户将统一地使用组合结构中的所有对象 |
Decorator 装饰 | 动态地给一个对象添加一些额外的职责,就增加功能而言,Decorator模式比生成子类更加灵活 | 1.在不影响其他对象的情况下,以动态、透明的方式给单个对象添加职责 2.处理那些可以撤销的职责 3.当不能采用生成子类的方式进行扩充时。一种情况是,可能有大量独立的扩展,为支持每一种组合将产生大量的子类,使得子类数目呈爆炸性增长。另一种情况可能是,由于类定义被隐藏,或类定义不能用于生成子类 |
Facade 外观 | 为子系统中的一组接口提供一个一致的页面,Facade模式定义了一个高层接口,这个接口使得这一子系统更加容易使用 | |
Flyweight 享元 | 运用共享技术有效地支持大量细粒度的对象 | 1.一个应用程序使用了大量的对象 2.完全由于使用大量对象,造成很大的存储开销 3.对象的大多数状态都可变为外部状态 4.如果删除对象的外部状态,那么可以用相对较少的共享对象取代很多组对象 5.应用程序不依赖于对象标识。由于Flyweight对象可以被共享,所以对于概念上明显有别的对象,标识测试将返回真值 |
Proxy 代理 | 为其他对象提供一种代理以控制对这个对象的访问 | 在需要比较通用和复杂的对象针织代替简单的指针的时候 |
剩余略~手敲太累,请谅解