我的观点 - 类的设计思路
公共部分
过渡部分
私有部分
如果没有办法划分出明确的区域, 则可以使用过渡区来
放置这些东西， 如果说将来发现
放错了地方，可以从过渡区里把它拿走
私有部分应该是各个类自己特殊的
怎么判断要构造哪些类，他们应该放在哪里
首先需要明白写这个类是为了做什么
为了实现功能
这个功能是业务功能还是基础设施功能？
为什么要考虑这个， 因为它决定了你要实现在哪一个层级
那如果是模糊的区域，可以任意选一个区，或者专门整一个
区，我目前认为没有明确的过渡区，
因为即便是过渡区，它仍然和其它区域可能有模糊地带，
所以只能暂时让模糊地带归属于某一个地方先
不用纠结这类细节
基于此，
我需要一个类存放公共的东西
需要一个类存放特定的部分
模糊的地方, 可以先放到子类中处理，
因为模糊的地方将来变化的可能性比较大，放到公共区里的话，影响范围比较大
注意影响范围大，并不代表什么， 只有发生变化时，影响范围才是我们要考虑的事情
我这里主要是出于控制影响范围，防范改动的问题
例如:
公共头部A
私有部分B
假设引入了新变量C，如果把C放入A中时,
假设C 需要经常更新，那么就要频繁更新头部A， 如果说A对更新是友好的，那我觉得C放在A里，没什么问题
什么是更新友好的?
比如 C 的类型，你把它改了，本来是int，你要改成string
那这显然是更新不友好的，要被禁止
所以你就选择添加一个字段，用新的，这时，其它人都必须加代码或者更新代码来
支持你的这次改动， 如果是这样的，显然也是更新不友好的
所以，当时如果能把C 丢出来，A就不会有问题，但这样做，就会导致很多类需要引入C
那这样，我们就有折中的办法，就是再创建一个基类，给它定义一个新的范围，
通过这种方式, 我们把影响范围缩小到一定程度，这样就没有那么多缺点了.
这是一个折中的方案，需要类的设计经验。
对于mapping service的测试框架, 我需要抽取一个公共的类，
这个类可以提供很多对象的默认实现.
- 对象的默认实现
两层设计，简单，功能划分粗放
多层设计，复杂，但是功能划分的粒度更细
抽象类 -> 它就是提供抽象逻辑，比如程序处理的模板实现
基础类 -> 它应该是要提供基本功能，就像水电基础设施他要提供好
业务类 -> 基于这些基础设施，进行
抽象 <—> 实现
隔离变化的方法 —> 中间加一层(可以是逻辑上的一层，也可以是物理上的一层)
加了一层之后，我们就是要做到变化可控
抽象就只做抽象的事情 - 不要贪多
基础类就只做基础类的事情 - 不要贪多
业务类就只做业务类的事情 - 不要贪多
写代码需要有 准入机制
什么东西可以加，什么不能加
什么是鼓励的，什么是不鼓励的，需要有这个标准
就像google招聘的准入标准
一定要对各模块的职责有明确的定义
哪个部分做哪块
要把代码当成一个产品，是你的产品，你肯定想哟的是美的产品
什么是美的产品 - 简洁，清晰， 业务它并不简单，但是我希望每个部分可以做到
简单，只是一群简单的东西，聚集在一起，就成为了不简单的系统或服务
为什么需要设计？
- 我们希望代码清晰
- 什么是清晰，别人不需要过多了解实现细节，甚至不用看代码，就能了解清楚
- 那你怎么做到这一点？
- 1 肯定是让单个代码做的事情越少越好, 就做一个功能，不允许实现两个功能
- 2 你得提供很清晰的文档，大段的文档我觉得非常不好，文档应该分两个部分
- 简介和详细的， 简介的就是要让别人不看代码也能了解清楚你在做什么
- 当然，如果你的代码，每一个部分做的都很细，代码文档自然也会跟着缩小
- 所以精髓还是分而治之
- 目录结构
- 日志格式
- 模块划分
- 模块名称
- 函数名称
- 变量名称
- 不管你怎么分，禁止随意划分，每种分需要有一套理论支撑，只要合理即可，没有标准
- 范式，不是所有东西都可以精确的，我们这是艺术品, 艺术无法精确, 不要模板
Ok
简单的两层设计
1） 因为我不需要引入第三层去分割权限, 也不需要引入第三层去隔离变化
为什么不需要分割权限，因为没那么多权限
为什么不需要隔离变化，因为没那么多变化 - 这可能是短视了，但我目前只能看到这些
并且我不想陷入过渡设计，将来添加一层的工作量，我相信是可控的，所以按需设计
我们只需要预留1年或者几个月的容量即可
封装变化 - 这个非常重要，这个就是加了一层，或者包装了一层，
然后让变化可控，实际上就是解耦合了
另外就是，因为功能专一，所以就需要有人专门负责摸个模块，
每个模块还需要有备份
多个模块上面再来一个人
这就是组织架构的能力， 系统架构和组织架构类似，但需要你对整体和细节都要很了解才可以
global - base
Modules
- module base1
- module base2
- module base3