软件工程
嗯...软件工程.. 如果这也算一门学科的话，那这门学科就是关于失败的学科，它是从一次次软件危机中诞生出的一堆东西。 这种失败也许算种人类普遍的失败，数学也是经历了一次次危机才有了今天这样庞大又折磨人的体系。
但在一开始，它们这些“失败经验”可能并没有那么重要，重要的是失败本身，那堆语言特性与设计模式，在自己也遇到那样的失败时，自然都会想到。
对的，去动手。
vim和命令行=> python csv/excel数据库 网页=> 服务端 数据库/操作系统 客户端=>
开始
回忆一下，我初来乍到的时候，看到想到的一些东西。 那时候，vue2，我发现了在这里，组件也有一个父子关系，但这个父子与 java 与传统面向对象的类的父子差别太大...parent-chid
- vue 这边大组件、parent 组件是更大更全的；而 java 类的 parent 虽然是一个根基但却很空，有太多没有实现或者需要修改的，依赖之后的多态去重写。最后干活上，vue 就是那个大 parent 直接去干，而java则是需要之后的子类去干。
以上是两种不同的设计思路，而因为碰巧，我找到了一个很合适的区分点，vue 那边是自底向上，而java则是自顶向下。
java 也许能让手熟的人快速的建立起一个架构，但对于一上来没有总体意识的菜鸟..稍微有点点灾难。而在后续的更新迭代上，因为存在那样一个根基以及一层层磊摞的关系，也更容易遇到不兼容的问题。但怎么说，也许对于老手而言，它快啊。
而再再之后，我又看到了另一种对此的区分，那就是 继承 vs 组合。就是直直的 diss 到面向对象的继承上，这种代码复用方式与当时比较贫瘠的计算机资源也有关，但不管怎样以这种方式实现的复用，代码之间的耦合度会很高。而对此，另一种复用方式被推了出来——组合。组合最简单的有上面 vue 的组件的组合，也有函数式编程里的一堆骚操作，有游戏开发那边的ECS...那面向对象怎么办呢，不救一救吗？
好了先回到 vue，组件组合这种关系的一个常见范例是，parent 组件拿到数据传给子组件的 props，然后子组件根据拿到的数据去渲染，这个传数据的过程，让我想到了“注入”...进而想到了依赖注入这个词——这是面向对象为了解耦而搞的一种操作。
哦~这句话好炫酷... [https://www.zhihu.com/question/59716738]
Objects are poor man's closures.
&
Closures are poor man's objects.
确实哦...java 出了一堆依赖注入的框架，js 到了es6 也终于好好搞了模块化和闭包...
嗯...想到了UML图里的那一堆东西......啊。。。。。这真tmd是一堆玄学。
按 UML 的分析方式，类有4种关系，1.依赖/关联/组合，2.实现(继承接口/实现对象)，3.泛化(继承)。 而前几种，相对较弱的相互关系...也会耦合的很强...吗。
局域变量、静态方法的调用，成员变量、方法形参，。
UML
三个基本模块：事务，关系，图。
- 事务
- 结构事务：类，接口，协作，用例，活动类，组件，节点。
- 行为事务：交互，状态机。
- 分组事务：包
- 注释事务：注释。
- 关系
- 依赖
- 关联
- 实现
- 泛化
- 图
- 用例图
- 类图
- 对象图
- 包图
- 部署图
- 活动图
- 状态图
- 序列图
- 协作图
- 组件图
设计模式
[https://www.zhihu.com/question/308850392/answer/1324509357]
也许我应该把这些搬到 java 那边...
设计模式基于六大原则：
- 开闭原则：一个软件实体如类、模块和函数应该对修改封闭，对扩展开放。
- 单一职责原则：一个类只做一件事，一个类应该只有一个引起它修改的原因。
- 里氏替换原则：子类应该可以完全替换父类。也就是说在使用继承时，只扩展新功能，而不要破坏父类原有的功能。
- 依赖倒置原则：细节应该依赖于抽象，抽象不应依赖于细节。把抽象层放在程序设计的高层，并保持稳定，程序的细节变化由低层的实现层来完成。
- 迪米特法则：又名「最少知道原则」，一个类不应知道自己操作的类的细节，换言之，只和朋友谈话，不和朋友的朋友谈话。
- 接口隔离原则：客户端不应依赖它不需要的接口。如果一个接口在实现时，部分方法由于冗余被客户端空实现，则应该将接口拆分，让实现类只需依赖自己需要的接口方法。
在这里，也许是对抽象的，一个最基本的使用，抽象与具体的实例、对象间的桥梁。而之后的结构(我会想称之为静态关系)，与行为模式，则是抽象与抽象之间的对舞了。
构建型模式，一共五种，分别是：
- 工厂方法模式
- 抽象工厂模式
- 单例模式
- 建造型模式
- 原型模式
结构型模式是用来设计程序的结构的。结构型模式就像搭积木，将不同的类结合在一起形成契合的结构。包括以下 7 种结构型模式：：
- 适配器模式
- 桥接模式
- 组合模式
- 装饰模式
- 外观模式
- 享元模式
- 代理模式
行为型模式重点关注 类与类之间的交互与协作，行为型模式共 11 种，分别是：
- 责任链模式
- 命令模式
- 解释器模式
- 迭代器模式
- 中介者模式
- 备忘录模式
- 观察者模式
- 状态模式
- 策略模式
- 模板方法模式
- 访问者模式
代码美学
组合 vs 继承 || 抽象 with 耦合
组合与图，继承与树
命名
起名字很难，并且很多时候，不在起名本身，还有，代码结构等等问题。
注释
类型，测试，命名...这些东西都可以作为注释。
而注释...可以在更高，在更抽象的层面，来解释代码的意图。
拒绝嵌套
嗯...但是有些地方，比如 UI 设计，还有 XML 该嵌套就嵌套。