我理解的是要因场景而异，但是最终的目的都是降低沟通的成本。
场景1：在大多数人对UML不是很熟练的情况下，如果采用UML来进行沟通，大家在理解上一定会存在Gap，无形之中会提高学习和沟通的成本，在这种情况下，建议不使用UML。举个例子，《实现领域驱动》的作者一开始是使用UML和领域专家沟通，作者认为UML很简单，但是许多领域专家或开发人员并不能很好地理解，最后又出现了ES（事件风暴）的形式来替代。
场景2：如果需要准确传达设计意图，还是需要UML这样的通用设计工具的，目的也是降低沟通的成本。例如，架构师的设计理念想准确传达给工程师，如果使用UML工具，可以避免模糊意图，带来额外的沟通成本。
敏捷宣言的第一条就是“个体和沟通”高于“流程和工具”。所以要因人而异，因场景而异，在专栏里“很多类图我并没有完全遵守 UML 的规范标准”的策略，我想是一个不错的折中。

下班后发现争哥让我出代码示例和说明区别，赶紧做。
写点简单粗暴的个人理解。
一 show me the code ..
泛化（Generalization）class BaseComponent { ... } class Dingdding extend BaseComponent { .. }
实现(Realization) 类实现接口 虚线加三角interface crud { func create(); func update();func get(); func() del{ } }
class DingdingModel implements crud {
func create(){ ...}
func update(){ ...}
func get(){ ...}
func del(){ ...}
}
关键是后面四个 （关联，聚合，组合，依赖）先说关联关系。 （A has B）
class DingdingUser {
privte $account; //有一个账号对象，
}
再说聚合，是一种特殊的关联。
聚合，组合， 一对多的关联
聚合关系是“has-a”关系，组合关系是“contains-a”关系，少一个宿主对象死掉没。
uml2.x 已合并这种无聊的区分
聚合示例class birdsGroup(){
private $birds;
//聚合往往可以干增减相关的操作
public func addBird( $bird) { ... }
public func removeBird( $bird) { ... }
}
组合示例。class bird (){public $wing; //鸟由翅膀 组成.
}
最后说关联合依赖。
泛化 = 实现 > 组合 > 聚合 > 关联 > 依赖
2 然后说些个人理解：我回顾了一下，oop 的过程。
在框架的辅助下，数据库建模一作，其实文件放哪，啥关系就出来了，画uml 图反正了一个体力活。
往往是去实现一个需求，将一个业务流走通，写了一段代码后，发现这里写死了，于是做点配置管理（中心控制原则） ，一个类权责过多，于是将其支解。（类的单一职责原则），重复的代码出现了，赶紧抽离出来，先简单粗爆的用一个类的静态方法抽（很多大神不建议这样做，我不明其理，慢慢研究）， 某个操作，有几种不同的类可以去做实施。例如日志。（redis 写日志，文本日志，数据库日志，控制台输出） 于是搞个工厂模式，遵守下dip原则，让Log::log($log_msg, $type,$tags) 成为一种面向抽象开始，而不是面向具体实现。老板看到gmail 的undo 很酷闲着蛋疼的让你对所有操作 ，都要求在半分钟类允许undo ，上个command 应付下，不出意外 没多久，老板的redo 需求来了，就顺着扩展 ，进一步的有时候，一个主体业务完成后，要做一堆关联的杂七杂八的事，于是搞个观察者模式，这样将主体业务和后序操作业务解耦了。 继续扯到解藕(decouple)了, 我粗浅的来看，折腾设计模式，本质是解藕，找到合适的方法，在合适的场景下做对应的解藕操作。
这么一折腾下来，类和类啥关系，好像压根没太在意到。。。。 但类之前又确实有关系 。 挺想想知道其它伙伴们是如何做oop 的。
自我总结，套路包确实掌握了几个，但总感觉是在很浅的层面上折腾，上述错的乱七八糟的，烦请指正，个人平时就这么想的，这八个月就跟着争哥好好学习了。