software design skill

1. oop
2. refactoring
3. uml
4. idea

 

 

面向对象的3个基本要素：封装、继承、多态

面向对象7个设计原则

 

1. 单一职责原则（Single Responsibility Principle）

每一个类应该专注于做一件事情。

2. 里氏替换原则（Liskov Substitution Principle）

超类存在的地方，子类是可以替换的。

3. 依赖倒置原则（Dependence Inversion Principle）

实现尽量依赖抽象，不依赖具体实现。

4. 接口隔离原则（Interface Segregation Principle）

应当为客户端提供尽可能小的单独的接口，而不是提供大的总的接口。

5. 迪米特法则（Law Of Demeter）

又叫最少知识原则，一个软件实体应当尽可能少的与其他实体发生相互作用。

6. 开闭原则（Open Close Principle）

面向扩展开放，面向修改关闭。

7. 组合/聚合复用原则（Composite/Aggregate Reuse Principle CARP）

尽量使用合成/聚合达到复用，尽量少用继承。原则： 一个类中有另一个类的对象。

 

 

 

重构：大布局==>小步快跑

1.拆函数和拆分对象  单一职责  SRP

2.代码复用 DRY

    同一对象：抽取方法

    不同对象：抽取类 or 父类 （or 实体类）

    继承过多：转变成组合

    碎片化：模板模式

    

3.增加扩展点  开闭

4.降低依赖     DIP

5.分层    数据和业务（ 贫血模型 vs 充血模型）

6.领域设计

 

UML类图几种关系的总结

http://blog.csdn.net/tianhai110/article/details/6339565

 

类图中变量和函数名前面的符号

短横线（-）表示private;

井号（#）表示protected;

加号（+）表示public; 变

量和函数参数的类型显示在变量和参数后面的冒号之后。同样，函数的返回值显示在函数后面的冒号之后。

 

在UML类图中，常见的有以下几种关系: 

泛化（Generalization）,  实现（Realization），关联（Association)，聚合（Aggregation），组合(Composition)，依赖(Dependency)

         1. 泛化（Generalization）

        【泛化关系】：是一种继承关系，表示一般与特殊的关系，它指定了子类如何特化父类的所有特征和行为。例如：老虎是动物的一种，即有老虎的特性也有动物的共性。

        【箭头指向】：带三角箭头的实线，箭头指向父类

 

        2. 实现（Realization）

        【实现关系】：是一种类与接口的关系，表示类是接口所有特征和行为的实现.

        【箭头指向】：带三角箭头的虚线，箭头指向接口

 

        3. 关联（Association)

        【关联关系】：是一种拥有的关系，它使一个类知道另一个类的属性和方法；如：老师与学生，丈夫与妻子关联可以是双向的，也可以是单向的。双向的关联可以有两个箭头或者没有箭头，单向的关联有一个箭头。

        【代码体现】：成员变量

        【箭头及指向】：带普通箭头的实心线，指向被拥有者

 

        上图中，老师与学生是双向关联，老师有多名学生，学生也可能有多名老师。但学生与某课程间的关系为单向关联，一名学生可能要上多门课程，课程是个抽象的东西他不拥有学生。 

        下图为自身关联： 

 

        4. 聚合（Aggregation）

        【聚合关系】：是整体与部分的关系，且部分可以离开整体而单独存在。如车和轮胎是整体和部分的关系，轮胎离开车仍然可以存在。

        聚合关系是关联关系的一种，是强的关联关系；关联和聚合在语法上无法区分，必须考察具体的逻辑关系。

        【代码体现】：成员变量

        【箭头及指向】：带空心菱形的实心线，菱形指向整体

 

        5. 组合(Composition)

        【组合关系】：是整体与部分的关系，但部分不能离开整体而单独存在。如公司和部门是整体和部分的关系，没有公司就不存在部门。

       组合关系是关联关系的一种，是比聚合关系还要强的关系，它要求普通的聚合关系中代表整体的对象负责代表部分的对象的生命周期。

【代码体现】：成员变量

【箭头及指向】：带实心菱形的实线，菱形指向整体

 

        6. 依赖(Dependency)

        【依赖关系】：是一种使用的关系，即一个类的实现需要另一个类的协助，所以要尽量不使用双向的互相依赖.

        【代码表现】：局部变量、方法的参数或者对静态方法的调用

        【箭头及指向】：带箭头的虚线，指向被使用者

 

        各种关系的强弱顺序：

        泛化 = 实现 > 组合 > 聚合 > 关联 > 依赖 

        下面这张UML图，比较形象地展示了各种类图关系：

 

 

观念：没有银弹，只能通过职责分配的高内聚和低耦合来实现，

荒岛技能，软件对象分配职责

没有银弹，工具无法弥补设计上的疏漏（uml参考手册）

通过在定量时间内的固定迭代，使系统增量式的增加功能的

uml建模，多人对核心功能，并行地建模，画出大概就行

 

初始，只需确认是不是要深入，而不是真正深入，包括，用例  风险与核心功能 开发计划

进化，需求分析的最大问题是，寻找、沟通和记住什么才是真正需要的，并能够说清楚，不断变化+用户启发

 

职责分配，就是单一职责，包含了最小意外的原则，

GRASP，信息专家 创建者 控制器 低耦合 高内聚 多态 纯虚构 间接性  防止变异

类职责协作，如果。。。怎样  的对象场景

‘不错。。但是。。’是在开发前期需求变化的一种表现，开发人要尽力搞清楚需求的真谛

低耦合，耦合没错，重要的是不要耦合不稳定的元素

高内聚，开闭原则（信息隐藏），也就是对扩展开放，对影响用户的修改关闭，避免用户触发带来的变化

映射关系，动态图—>静态图—>代码（耦合度由低到高编写）

对象设计，用例输入 事件活动  原型输出，UML交互就是在进行职责分配，

对象可见性，包括了属性 参数 局部 全局

 

 

架构，

软件：就是预防变化，通过关注分离和横切面关注来实现的， | 边界 —封装— 暴露 

硬件：关注非功能特性，比如性能

向上通信，好莱坞原则：不要给我们打电话，我们会打给你（观察者）

思想，映射 对象标识 数据库映射器 具体化和虚化 缓存 事务状态 事务操作 滞后实现 代理 安全 异常

异常：缺陷—>错误—>故障

 

 

 

建模：领域  用例 交互 实现

 

uml工具列表：http://www.objectsbydesign.com/tools/umltools_byCompany.html

 

用例模型：

包括，用例名称 范围 级别 主要参与者 涉众 前置条件 后置条件 主成功场景 扩展 特殊需求 技术变化 频率 杂项

其他需求，补充性规格说明  词汇表  设想  业务规则

抓住本质写用例，也就是目标的目标

发现用例，选择系统边界 寻找主要参与者  明确目标  定义用例（动词开头 curd=>统一是管理）

用例图，主要参与者在左边，次要参与者在右边

Page 50   +  参与者 vs 系统的响应

 

领域模型，算是 uml类图的精简，关联（115）和多重性（113）

迭代1：领域模型 设计模型 软件架构文档 数据模型 用例示意和界面原型 | 功能需求等级排序

迭代进化，分析是做正确的事，设计师正确地做事；包容变更，尽早引发不可避免的变更

 

 

系统顺序图，系统事件的操作顺序，事件包括，人和计算机 时间 错误异常

UML包图，贯彻了分层的观念，不要混合逻辑视图和物理视图，最好是按照服务来划分

操作契约（后置条件）：操作 交叉  前置条件  后置条件（创建或删除实例 属性值变化 形成和消除关联）

交互图Page163，类+方法+参数 | 图框操作符，alt loop  opt par  region Page168 | 引用 拆分  多态 异步

UML类图，Page195 + Page181

活动图，横向是不同的类，纵向是类中的方法

部署图，设备节点 环境节点

 

面向对象建模，静态图偏于细化状态，动态图更多展现流程  P442

静态和动态建模，动态有助于逻辑、代码行为和方法体，比如UML交互图（顺序图或通信图 | 状态机图或活动图），静态模型用来设计包、雷鸣、属性和方法

想要支持多态，但又不想受类的层次的约束，那就使用接口

组合原则，多种因素的触发策略

泛化，有属性和关联，子类要有额外的特性 | 状态机图，流程 动作 角色

包含关系要是可复用的，减少不稳定包依赖，不相关类分离出去，打破循环依赖

关联类，存在于发生交互的类之间的

 

 

 

步骤：

 

流程，定义用例 定义领域模型 定义交互图 定义设计类

会议分析，开发功能=>开发周期==>开发==>评审

迭代，风险+客户=>架构为中心

 

业务流程：

建模，领域模型

需求，用例模型 设想 补充说明 词汇表

设计，设计模型 软件架构文档  数据模型

实现，实现模型

 

科目与阶段：Page 28

—科目，需求 设计 实现

—阶段，初始 细化 开发 移交