我的观点 - 类的设计思路

Posted 2020-08-17 Jinlei

tags:

篇首语：本文由小常识网(cha138.com)小编为大家整理，主要介绍了我的观点 - 类的设计思路相关的知识，希望对你有一定的参考价值。

公共部分
过渡部分
私有部分

如果没有办法划分出明确的区域, 则可以使用过渡区来
放置这些东西，如果说将来发现
放错了地方，可以从过渡区里把它拿走

私有部分应该是各个类自己特殊的

怎么判断要构造哪些类，他们应该放在哪里

首先需要明白写这个类是为了做什么
为了实现功能
这个功能是业务功能还是基础设施功能？
为什么要考虑这个，因为它决定了你要实现在哪一个层级

那如果是模糊的区域，可以任意选一个区，或者专门整一个
区，我目前认为没有明确的过渡区，
因为即便是过渡区，它仍然和其它区域可能有模糊地带，
所以只能暂时让模糊地带归属于某一个地方先

不用纠结这类细节

基于此，

我需要一个类存放公共的东西
需要一个类存放特定的部分
模糊的地方, 可以先放到子类中处理，
因为模糊的地方将来变化的可能性比较大，放到公共区里的话，影响范围比较大

注意影响范围大，并不代表什么，只有发生变化时，影响范围才是我们要考虑的事情

我这里主要是出于控制影响范围，防范改动的问题

例如:
公共头部A
私有部分B

假设引入了新变量C，如果把C放入A中时,
假设C 需要经常更新，那么就要频繁更新头部A，如果说A对更新是友好的，那我觉得C放在A里，没什么问题

什么是更新友好的?
比如 C 的类型，你把它改了，本来是int，你要改成string
那这显然是更新不友好的，要被禁止
所以你就选择添加一个字段，用新的，这时，其它人都必须加代码或者更新代码来
支持你的这次改动，如果是这样的，显然也是更新不友好的

所以，当时如果能把C 丢出来，A就不会有问题，但这样做，就会导致很多类需要引入C

那这样，我们就有折中的办法，就是再创建一个基类，给它定义一个新的范围，

通过这种方式, 我们把影响范围缩小到一定程度，这样就没有那么多缺点了.

这是一个折中的方案，需要类的设计经验。

对于mapping service的测试框架, 我需要抽取一个公共的类，
这个类可以提供很多对象的默认实现.

两层设计，简单，功能划分粗放
多层设计，复杂，但是功能划分的粒度更细

抽象类 -> 它就是提供抽象逻辑，比如程序处理的模板实现

基础类 -> 它应该是要提供基本功能，就像水电基础设施他要提供好
业务类 -> 基于这些基础设施，进行

抽象 <—> 实现
隔离变化的方法 —> 中间加一层(可以是逻辑上的一层，也可以是物理上的一层)
加了一层之后，我们就是要做到变化可控

抽象就只做抽象的事情 - 不要贪多
基础类就只做基础类的事情 - 不要贪多
业务类就只做业务类的事情 - 不要贪多
写代码需要有准入机制

什么东西可以加，什么不能加
什么是鼓励的，什么是不鼓励的，需要有这个标准
就像google招聘的准入标准

一定要对各模块的职责有明确的定义
哪个部分做哪块

要把代码当成一个产品，是你的产品，你肯定想哟的是美的产品
什么是美的产品 - 简洁，清晰，业务它并不简单，但是我希望每个部分可以做到
简单，只是一群简单的东西，聚集在一起，就成为了不简单的系统或服务

为什么需要设计？

简单的两层设计
1）因为我不需要引入第三层去分割权限, 也不需要引入第三层去隔离变化
为什么不需要分割权限，因为没那么多权限
为什么不需要隔离变化，因为没那么多变化 - 这可能是短视了，但我目前只能看到这些
并且我不想陷入过渡设计，将来添加一层的工作量，我相信是可控的，所以按需设计

我们只需要预留1年或者几个月的容量即可

封装变化 - 这个非常重要，这个就是加了一层，或者包装了一层，
然后让变化可控，实际上就是解耦合了

另外就是，因为功能专一，所以就需要有人专门负责摸个模块，
每个模块还需要有备份
多个模块上面再来一个人
这就是组织架构的能力，系统架构和组织架构类似，但需要你对整体和细节都要很了解才可以

global - base
Modules
- module base1
- module base2
- module base3

以上是关于我的观点 - 类的设计思路的主要内容，如果未能解决你的问题，请参考以下文章