第二组第二次作业
第一章
单一职责原则
1.1 编写类或接口执行单一职责原则，定义是有且仅有一个原因引起类的变更。我对于它的理解是：把实现的每个功能归称一个大类，在每个功能大类中编写对应的类或接口。
1.2 单一职责的好处：
1类的复杂性降低，实现什么职责都有清晰明确的定义。
2可读性提高，复杂性降低。
3可维护性提高。
4变更引起的风险降低。
单一职责的量化标准：用“职责”或“变化原因”来衡量接口或设计得是否优良，这两个衡量标准因项目，环境而已。
1.3 方法也要单一职责，不能贪心一个方法完成一个笼统的功能。
1.4 由于写类时需要考虑很多外部因素，所以很难做到单一职责，但接口要做到单一职责，类的设计尽量知道只有一个原因引起变化。
第二章
里氏替换原则
2.1 继承的优点：
1子类共享父类代码。
2提高代码重用性。
3提高代码的可扩展性。
4提高产品或项目的开放性。
继承的缺点：
1继承中父类相当于侵入子类。
2降低子类代码灵活性。
3增强子类与父类的耦合性，不易于修改。
里氏替换原则：父类能出现的地方子类也可以出现并能替换成子类，反之不能。
2.2 子类必须完全实现父类的方法，可以有自己独有的方法。子类的输入参数宽于或等于父类的输入参数，子类的方法才不会被调用。
第三章
依赖倒置原则
3.1原则含义：高层模块不依赖底层模块，两者应依赖其抽象（接口或抽象类）。
细节（实现类）应依赖抽象，反之不能。细节之间不发生直接的依赖关系，依赖关系是通过抽象产生的。
3.2 依赖倒置原则的优点:
1减少内间的耦合性。
2提高系统的稳定性。
3降低并行开发引起的风险。
4提高代码的可读性和可维护性(并行开发的风险是一段程序的错误和异常毁了整个项目 )。
一个变量可以有两种类型，表面类型(定义时赋予的类型)和实际类型(对象的类型 )。
独立运行单元测试的小工具:JMock工具 ,可以根据抽象虚拟一个对象进行测试。
3.3 依赖的三种写法
1构造函数传递依赖对象
2 setter方法传递依赖对象
3接口声明依赖对象
3.4 依赖倒置原则的本质是通过抽象使各个类或模块实现彼此独立，不相互影响，实现模块之间的松耦合。具体是指：
1每个类尽量都有接口或抽象类，变量的表面类型尽量是接口或抽象类，任何类都不能从具体类派生，尽量不要复写基类的方法，因为可能会对依赖的稳定性产生影响。 2结合里氏替换原则使用，依赖倒置原则比较适合中大型项目中，实现开闭原则的前提是实现依赖倒置原则。
第四章
接口隔离原则
4.1接口隔离原则的定义：首先接口分为实例接口和类接口(用Interface定义的接口 )，类接口是指在Java中声明一个类 ，再new产生一个实例，这个类就是对类型的事物的描述，这是实例接口。
接口尽量细化，里面的方法尽量少。它与单一职责的不同是:单一职责注重的是职责，是业务逻辑上的划分。接口隔离原则要求接口的方法尽量少，不需要为了满足多个模块就建立臃肿的接口。
4.2 为了便于程序的扩展，不能过度封装，也应使用接口隔离原则。
4.3 根据接口隔离原则拆分接口时要先满足单一职责原则。
注意:
1接口要高内聚。高内聚是提高接口类模块的处理能力，减少对外的交互，具体到接口隔离原则就是在接口中少使用public。
2定制服务 指只提供访问者需要的方法。
3越拆分接口系统会越灵活，但同时结构越复杂，越难维护，所以要注意适度。
4.4 1一个接口只服务一个子模块或业务逻辑。
2少量使用public，根据需求进行拆分接口，不能生搬硬套。
第五章
迪米特法则
5.1 迪米特法则含义:一个类应该对自己需要耦合或调用的类知道的最少。
5.2 方法是类的一个行为，这个方法只能与本类产生依赖关系，不允许与其他类产生依赖关系，不同类之间的关系是建立在类间，不是方法间，这样就会降低系统间的耦合，提高系统的健壮性。
但是同个类中的方法也要注意保持距离，减少公开的属性或方法 (这样修改时候，设计面和风险会更大)，尽量使用private、package、protected等访问权限。
假如一个方法可以放在不同的类中，但这个方法要优先放在不增加类间关系，也不对类产生负面影响的类。
5.3 迪米特法则的核心观念就是类间解耦，弱耦合，但是要尽量少产生中转或跳转类(量不要超过两次 )，因为跳转的越多，维护就越困难 。
第六章
开闭原则
6.1 定义：一个软件实体如类，模块和函数应该对扩展开放，对修改关闭。（通过扩展实现变化，而不是通过修改已有代码实现。）
6.2 但对修改关闭不是绝对不修改的，如果合适可以适当的修改，修改可以归纳为：
1只对某个逻辑进行变化。
2子模块的修改。
3可见试图的变化尽量通过扩展完成。
完成项目应经过：
1项目开发。
2重构（指对原有设计和代码修改）。
3测试。
4投产。
5运维（避免修改原有代码）。
6.3 开闭原则相比前五个原则重要
开闭原则的重要性：
1测试要保证业务逻辑，边界条件，异常要测试到。单元测试是对类的测试，类中的方法耦合是允许的，所以尽量不要修改方法，因为如果牵扯到这个方法有复杂的逻辑，在整个测试类中的方法就会被修改的面目全非，要通过扩展来实现业务逻辑的变化。
2提高复用性，便于维护。因为通过扩展来实现业务逻辑的变化，所以这个逻辑粒度是很小的，不用读懂原有代码中的逻辑关系，直接扩展一个类。
6.4 怎样使用开闭原则？
1通过接口或抽象类约束扩展，只能在现有的基础上进行扩展 。参数类型、引用对象尽量使用抽象类或者接口。抽象层一旦确定就不允许修改 。实现对扩展开放的前提条件就是抽象约束。
2元数据(用来描述环境和数据的数据 )控制模块行为。
3制定项目章程。
4封装变化(封装可能发生的变化 )相同的变化封装到一个接口或抽象类中 。
6.5 封装变化依赖的六大原则：
1单一职责原则。
2 开闭原则。
3里氏替换原则。
4迪米特法则。
5接口隔离原则。
6依赖倒置原则。
但是封装变化并不局限于这六大设计原则， 尽量采用最好。其中类必须做到高内聚、低耦合，以此来避免一些不可预料的事故。封装变化前也要做好项目规章制度，预知变化。
UML概述
定义:统一建模语言UML是一种直观化、明确化、构建和文档化软件系统产物的通用可视化建模语言。
支持大多数面向对象的开发过程，也可用于迭代的开发过程。
UML不是编程语言，是通用性的建模语言，是离散的建模语言，是对诸如软件、硬件或数字逻辑的离散系统建模的通用语言。
静态结构:分为类、属性、操作。多个类可以使用概括共享通用的结构，元素之间的一些关系可以用依赖来分组，包括抽象层次的转移，模块参数的绑定，许可的授予和元素对其他元素的使用。
这些元素包括接口、数据类型、用例和信号。合并在一起成为分类。
动态行为:建模动态行为有两种方式:
1通过与外界交互的对象的生命史。
2使用一系列对象的通信模式。这些相互连接的对象交互实现行为。
被隔离的对象视图是状态机，对象依照当前状态对事件响应，执行动作，迁移至新状态。
依赖上下文的对象和互相之间链的视图是协作。
UML预览 静态视图 用例视图
