JAVA------ooad

**软件开发，就跟建筑行业一样，**也需要有前期各种规划，也需要有前期各种设计，同样需要有农名工（程序猿|攻城狮）来参与，同样需要对软件进行各种测试|验收，
同样也存在交付产品的过程。

如果我们不去向上述的方案进行操作的话，那么就有可能会出问题。所以我们软件开发也是非常严谨的事情，容不得半点马虎！

软件开发，同样也有各种需要管理的东西

软件开发中，比较经典的开发步骤：

**瀑布模型：**

    可行性分析    
    需求分析
    软件设计
    编码
    测试
    交付产品
    维护

瀑布模型存在比较严重的问题：需求如果要发生变更，只能在极早期 越往后走，代价越大

改进方案：迭代 +  瀑布模型 

1、计划驱动     文档
2、敏捷开发     客户交流 

需求分析，软件设计，编程  都有两种方式：面向对象  面向过程

采用面向对象的思维习惯来，分析需求（OOA） 软件设计（OOD） 编程（OOP）

软件开发过程中，怎么样去评价一个软件设计的合不合理，好不好？

**评价的标准是：**
    

    1、有没有覆盖用户所提的所有的业务功能（覆盖了所有的需求，也不一定就是一个设计非常好的软件）
    2、前期设计出来的各种文档或者图纸，可读性高不高，能不能被项目所有的干系人快速的理解。一个可读性非常差文档，或者设计的图纸，会给我们后期开发，测试，维护都会带来巨大的影响
    3、软件设计的图纸中，覆盖的类，包，接口，以及其他的各种组件，复用性强不强，能不能被本项目，或者其他项目重复使用
    4、软件开发后期，如果业务需求需要发生变化，业务功能或者性能的扩展性高不高
    5、后期软件的维护，或者开发过程中代码的维护能力强不强（员工离职了，其他员工能不能看懂，能不能快速的理解我们的软件结构）

上述的5个方向，归纳起来就是一句话，软件设计过程中，是否能做到“高内聚，低耦合”？

**高内聚：**1个类只做1件事，以及1个方法只做1件事  具体来说：就是1个类只关注1个点，比如：用户类只关注用户信息或者用户的行为 它不会去关注其他类的属性或者行为   

如果一个类只关注1件事，并且内部每一个方法也只关注1个事，那么说该类的内聚度非常的高，越高代表职责越清晰，代码的复用性越高，类与类之间的牵连越少

**耦合：** 就是指类和类之间的关系紧密程度  如果一个类与例外一个类关系的非常紧密，那么当其中的一个类需要发生变化的时候，调用类将也会跟着变化。

比如下面这段代码：

    public class StudentServiceImpl implements IStudentService {
    
    private IStudentDao studentDaoImpl = new StudentDaoImpl();

    @Override
    public void saveStudent(StudentBean stu) {
        // TODO Auto-generated method stub
        studentDaoImpl.saveStudent(stu);
        }
    }
    

其中的StudentServiceImpl 和 StudentDaoImpl 两个类的关系就非常的紧密。如果一旦StudentDaoImpl需要被替代，那么StudentServiceImpl也就需要跟着修改代码。
 
耦合度这个东西，它是决定了应用软件能否灵活支持需求变化的最大因素。紧密关系越紧，变化度越低，变化的代价越大。
但是我们又不能说就直接取消耦合，所以咱们只能降低“耦合度”，怎么去降低耦合度？

就需要大家去遵循这个行业里面，由前辈给我们总结出来一些设计原则，以及设计模式！

**第一个原则：单一原则 **

一句话描述：“1个类只干1件事”，这是软件设计中高内聚的最重要一点，换句话说：1个类只有1种职责，那么这个职责的确定，需要根据类的对象来确定，看你正在关注对象的哪个方向。比如：学校系统中，学生对象来讲，只需要关注学习，而不应该去关注他或者她怎么当子女。只有1种情况能去改变我这个类。

也就是说在设计类时，类中每一个属性，和每一个方法都必须要根这个类的职责，具有直接关系。如果某一个属性或者某一个行为与本类的职责的无关，那么这个类的设计，就一定违背了“单一原则”

类的职责单一，也是一种降低耦合度的手段，对象的职责越少，耦合关联度越低，代码越容易复用。当然单一职责，同样适用于方法。当方法违背单一原则时，那么方法的代码将会非常冗长，以及可能存在代码的重复，甚至代码的浪费！

**第二个原则：里式替换原则 **

定义：子类可以出现在父类出现的任何地方，并且对于父类之前定义的规则，不出发生任何改变！

目的：为了维护现有的继承体系，保证龙生龙，凤生凤，老鼠儿子依旧会打洞 
这个原则是开闭原则的一种体现，或者是一种重要的保证，保证儿子在新增新的功能的时候，不会去改写父类已经定义好的方法，从而去维护现有的继承体系。
 

第三个原则：依赖倒置原则**

软件设计中，多层次之间，相互之间的依赖关系需要倒置为依赖抽象类或者接口，而不是直接依赖具体实现.
具体实现：
1、上层模块不应该直接依赖下层实现，而应该依赖于下层的抽象.
2、每一单独的层次，抽象不应该依赖于细节，而细节应该依赖与抽象.

依赖倒置原则，用白话来描述就是：面向接口编程.

第四个原则：接口隔离原则** （ISP）

软件设计中，我们索引的实现类在依赖接口的时候，都不应该去依赖那些用不到的方法，只需要依赖那些直接需要的方法.
换句话说：就是我们设计软件的时候，不要强迫实现它不需要的方法.
接口隔离原则，具体提醒有两种情况：
1、接口隔离原则，必须遵循接口最小化原则，但是这里的最小化，不是说1个方法，就是1个接口.而是说1个接口只应该承担1中责任（单一原则的体现）.
那么接口粒度的划分，什么才叫最小化呢？答案是：适度即可.
2、接口隔离原则中的“最小化原则”，同样适用于接口之间的继承，那么由继承多个接口的接口，也同样需要满足“最小化原则”.一个接口只应该承担1种责任.
如果某一天，大家发现某一个接口中，存在多个职责，那么这个接口一定需要重新设计.

**第五个原则：迪米特法则**

迪米特法则，又被称为之“最少知道原则”它要求我们在定义类的时候，或者实现类的方法的时候，尽量做到只与类的朋友进行交互，不予朋友之外的任何类有直接交互.
因为一旦交互，就存在耦合，甚至有的类与类之间的耦合度非常高，那么换句话说：非朋友类如果需要修改，可能导致你也跟着奥修改，这就违背了“开闭原则”
也就是常说的;"我妈说的不要和陌生人说话".

**第六个原则：组合\聚合的复用原则

组合\聚合原则：主要是一种推荐大家使用面向接口编程的一种原则，它的目的在于和继承来区分”代码“的复用问题.
组合\聚合是一种比较特殊的关联关系，它同样满足”has“这种单词所对应的场景，只不过它更多强调的部分和整体的关系.
比如：车和车轮胎（聚合），部分和公司（组合），组合的耦合度比聚合的耦合度强.

继承和组合\聚合，都可以做到关于代码的复用，但是各有各的优缺点：

继承的优缺点：

优点是：
1、父类定义的索引属性和行为，子类都自动继承了.相当于子类不需要在重复定义.
2、子类如果需要重写或者扩展新的方法，非常方便，并且对父类不会产生任何影响！（定义上来将，但是替代上却不是）.

缺点是：
1、继承容易破坏包装，就继承而言父类对于子类是完全透明的，以及子孙类都可以知道超类的方法.（违背了：迪米特法则）.
2、父类如果改变子类或者子孙类也会跟着发生改变.
3、父子关系在Java中采用extends实现，这种实现关系在编译器就可以确定下来，所以我们把这种关系的建立称为”静态关系“.
因为它不具备灵活性，我们重来没听说过：”子类在运行时，可以动态绑定父类“

组合\聚合复用的优点：
1、组合\聚合里面，我们跟多采用面向接口编程（依赖倒转原则）来实现类与类之间的松散耦合，那么就说明：在类中访问接口，就成了访问对象的唯一方法.
2、接口是抽象的它没有细节换句话说：在类中访问接口中定义的方法我们是不知道细节的，这种代码复用更近与”黑箱操作“.
3、面向接口编程永远比面向细节编程，耦合度低.比如：U盘细节极容易发生变化，但是U盘与电脑之间对应的口子却很少发生变化.
4、面向接口编程中，接口的实例在程序运行过程中动态绑定的，那换句话说：”我可以按照自己的需求来进行灵活的改变“.

**第七原则：开闭原则**

开闭原则：开闭原则是所有原则的核心，其他任何原则最终的目的都是为了开闭原则服务.
开闭原则是指组成程序的代码（类，方法，模块....）它们应该对功能的扩展是开放的，而对功能的修改是关闭的.

具体表现为：
对功能的扩展是开放的：对于一个系统而言没业务功能可以随时在改变也可能随时在新增.
该原则的意思是：系统支持我们可以去扩展新的功能，来满足用户的新需求.
对功能修改是关闭的：我们在扩展新功能时候我们对员功能的修改是关闭的.
比如：我们系统以前只支持新手机，现在客户要求我们还要支持老手机.
那么就要求我们：在支持老手机时，不要去修改支持新手机的任何代码.