23｜泛化建模（中）：可以不用泛化吗？
钟敬
你好，我是钟敬。
上节课，我们学习了“泛化”，并用这个技术完成了“在子项目上报工时”的需求。如果你是第一次学的话，可能会觉得理解起来有一些难度吧。
今天，我们继续这个建模过程，首先考虑“在子项目上报工时”这个需求的更多细节，增加更多的灵活性。
然后，我们来考虑另一个需求——“为内部项目报工时”。我们会采用使用泛化和不使用泛化两种方式为这个需求建模，并且比较两者的异同，以便你更进一步理解泛化的思路。事实上，用不用泛化有时不是一个非黑即白的决定，而是一种权衡。
还是我当项目经理，你当架构师。
增强灵活性
我们先回顾一下上节课建立的模型。
到现在为止，我们的模型已经基本可以满足按项目、子项目和普通工时项来报工时的需求了。
我们简单复述一下目前的需求。
“零零后公司”只能按项目登记工时。
“九零后公司”只能按子项目登记工时。
“八零后公司”既可以按项目也可按子项目，还可以按普通工时项登记工时。
现在我开始向你提几个更深入的问题。
第一个问题是：怎么控制“零零后公司”只能按项目，而不能按子项目报工时呢？反之，怎么控制“九零后公司”只能按子项目报工时呢？
为了解决这个问题，你决定为每个租户增加一个配置参数。
所有租户级的参数，都在租户参数这个实体里。我们商量了一下，把新的参数命名为项目工时粒度，有三个选项，分别是：“项目”“子项目”和“两可”。对于“零零后公司”只要把这个参数设置成“项目”，就说明只能按项目来报工时。对于其他两个公司的需求，道理是一样的。
公开
同步至部落
取消
完成
0/2000
荧光笔
直线
曲线笔记
复制
AI
- 深入了解
- 翻译
- 解释
- 总结
本文讨论了泛化建模技术及其在项目需求中的应用。作者首先探讨了如何增强模型的灵活性，通过在租户参数和项目级别增加配置参数，以满足不同公司对工时报表的需求。其次，作者讨论了非客户项目的泛化建模，通过泛化的知识，将客户项目和内部项目进行了区分，体现了它们的共性和个性。文章通过具体的需求场景，深入浅出地介绍了泛化建模的思路和应用，为读者提供了技术上的启发和思考。在权衡过程中，需要结合业务和技术视角。另外，通过为两个需求增加灵活性，我们也体会到，相比给特定企业定制的系统，SaaS系统往往需要考虑更多的灵活性。文章提出了两个思考题，引导读者深入思考泛化在不同情境下的应用。
仅可试看部分内容，如需阅读全部内容，请付费购买文章所属专栏
《手把手教你落地 DDD》，新⼈⾸单¥59
《手把手教你落地 DDD》，新⼈⾸单¥59
立即购买
© 版权归极客邦科技所有，未经许可不得传播售卖。 页面已增加防盗追踪，如有侵权极客邦将依法追究其法律责任。
登录 后留言
全部留言(10)
- 最新
- 精选
子衿1. 结合我原来的知识，我理解是否要使用泛化，其实讨论的就是到底是使用继承，还是使用一个状态位来表达区别，那最终其实就是对面向过程还是面向对象的一个权衡，如果不用泛化，而是新增一个属性表示区别，如果该属性只影响这个类的一小部分行为还好，只需在这一小部分行为中加入if..else即可，但如果这个属性，影响了这个类的大部分行为，那就会产生一堆的if..else，此时不如使用泛化，让代码更面向对象，对于上一个迭代，我觉得开发中心、直属部门和组织之间的区别在于他们的性质，而性质这个属性对他们的行为影响不大，可以考虑不使用泛化实现 2. 多重泛化不能使用继承是因为java中不支持多继承，如果非使用继承实现，就会造成类的泛滥，这其实就是设计模式中桥接模式解决的问题作者回复: 1 总体思路没问题。关键看开发中心、直属部门等有没有自己特殊的属性或逻辑，如果有，才考虑使用泛化，否则就没有使用的理由了。 2 C++支持而Java不支持的多继承，和这里说的“多重泛化”不是一个概念。等我找时间和大家讲讲吧。
2023-02-02归属地：浙江214
赵晏龙1 考虑泛化后增加模型复杂度，并且没有提供任何的必要性或者好处，我倾向于不使用泛化。 2 java .net里不能有多个父类？那我CPP来！等等，我是不是泄漏了内存？为什么提示我地址非法？你们先设计模型，我解决完这些马上就来！作者回复: 1 没问题 2 C++支持的“多继承”和建模里的“多重泛化”不是一个概念，我找时间再和大家讲讲。《分析模式》有讲。
2023-02-16归属地：湖南23- 邓西1. 个人理解，是否需要泛化的评判标准应该是各差异属性是否可以归类，用枚举等方式便可区分。如果是，那就没有必要泛化。 2. 求解。语言特性决定？Java不支持多继承，但C++可以
作者回复: 第一题没问题。第二题，多重泛化和多继承还不是一回事，等我找个时间讲讲。
2023-02-17归属地：四川2 
阿昕思考题，开发中心、直属部门和组织之间，主要区别体现在类型、上下级关系之间，只有属性的差异，不用泛化作者回复: 是的。
2023-02-08归属地：浙江2
NoSuchMethodError泛化不泛化取决于是否具有属性的差异作者回复: 多数情况是这样。有时也考虑关联的差异。
2023-04-10归属地：江苏1
6点无痛早起学习的和尚
思考题，看了老师给别人的回复，想到了目前代码里实现的一个点，就采用了泛化类似的想法，感觉这也是一个泛化 在代码里的领域层的对象，都继承了AuditableEntity，这个就是不同对象之间的共性，子类又有不同的个性（字段属性） 不知道这样认为对不对作者回复: 也算泛化，不过这是实现层面的，不是业务概念方面的。
2023-02-20归属地：北京1
特修斯之船我怎么感觉泛化的图更好理解，不喜欢用注解作者回复: 这里确实没有唯一正确，如果业务和开发都觉得泛化好理解，就可以用泛化。另外，后面还会提到，要考虑和实现的一致性。
2023-02-15归属地：广东1
颜如玉继承通常只能解决单维度的泛化问题，多重泛化有多个维度作者回复: 嗯嗯，是这个意思。
2023-07-09归属地：上海
zenkJAVA 每个泛化一个方法，不同的实现对应不同的泛化，而且一一对应，只是子类比较多，是每种泛化种类的乘积作者回复: 是的，这种组合爆炸，已经说明泛化用得不太恰当了。
2023-03-02归属地：上海
tt我觉得开发中心、直属部门和组织之间确实是泛化的关系，但是在这个项目里它们几乎是会存在的实体，为了明确，可以不用泛化实现。 至于多重泛化，我觉得不像是继承，而像是C++模板中的“偏特化”，就是对于模板中的某个属性做特定的实例化。所以不适合用继承实现。作者回复: 如果不同种类的组织，有不同的属性、关联等等，可以考虑用泛化，否则就没必要了。多重泛化的问题，等找个时间再细聊一下。
2023-02-05归属地：北京
收起评论
