uml结构图讲解（概述耦合UML）

uml结构图讲解（概述耦合UML）​例如写一个加法程序，很容易就可以写的出来，这个时候变化还没有发生无论模块是多么“封闭”，都会存在一些无法对之封闭的变化。既然不可能完全封闭，设计人员必须对他设计的模块应该对那种变化封闭做出选择，他必须先猜测出最有可能发现的变化种类，然后构造抽象来隔离那些变化 ——《大话设计模式》预先猜测程序的变化，实际上是有很大难度，或许不完善，亦或者完全是错误的，所以为了规避这一点，我们可以选择在刚开始写代码的时候，假设不会有任何变化出现，但当变化发生的时候，我们就要立即采取行动，通过 “抽象约束，封装变化” 的方式，创建抽象来隔离发生的同类变化举例：

public class FTP{ private String ip; private int port; private String user; private String pwd; ...... 省略 get set } 复制代码

两种方式看似都是差不多的，也都能实现要求，但是如果我们想要在其基础上增加一个新的参数

• 如果以定义一的做法，一旦接口被修改，所有调用 connectServer 方法的位置都会出现问题
• 如果以定义二的做法，我们只需要修改 FTP 这个实体类，添加一个属性即可这种情况下没有用到这个新参数的调用处就不会出现问题，即使需要调用这个参数，我们也可以在 FTP 类的构造函数中，对其进行一个默认的赋值处理

B：具体层次

对原有的具体层次的代码进行修改，也是不太好的，虽然带来的变化可能不如抽象层次的大，或者碰巧也没问题，但是这种问题有时候是不可预料的，或许一些不经意的修改会带了和预期完全不一致的结果

(2) 对扩展开放

对扩展开放，也就是我们不需要在原代码上进行修改，因为我们定义的抽象层已经足够的合理，足够的包容，我们只需要根据需求重新派生一个实现类来扩展就可以了

(3) 开发时如何处理

无论模块是多么“封闭”，都会存在一些无法对之封闭的变化。既然不可能完全封闭，设计人员必须对他设计的模块应该对那种变化封闭做出选择，他必须先猜测出最有可能发现的变化种类，然后构造抽象来隔离那些变化 ——《大话设计模式》

预先猜测程序的变化，实际上是有很大难度，或许不完善，亦或者完全是错误的，所以为了规避这一点，我们可以选择在刚开始写代码的时候，假设不会有任何变化出现，但当变化发生的时候，我们就要立即采取行动，通过 “抽象约束，封装变化” 的方式，创建抽象来隔离发生的同类变化

举例：

例如写一个加法程序，很容易就可以写的出来，这个时候变化还没有发生

​

如果这个时候让你增加一个减法或者乘除等的功能，你就发现，你就需要在原来的类上面修改，这显然违背了 “开闭原则”，所以变化一旦发生，我们就立即采取行动，决定重构代码，首先创建一个抽象类的运算类，通过继承多态等隔离代码，以后还想添加什么类型的运算方式，只需要增加一个新的子类就可以了，也就是说，对程序的改动，是通过新代码进行的，而不是更改现有代码