【发布时间】:2021-09-27 02:04:56
【问题描述】:
嘿,我对一个真实的单词示例有疑问。 它与我的另外两个有关,但在这里没有真正回答问题:
https://softwareengineering.stackexchange.com/questions/423392/no-trivial-god-class-refactoring
和
假设我们有一个带有switchOn()、switchOff() 方法的开关。
开关包含在其他一些结构中,例如switch-bag,我可以从中拔出开关。
这可以看作是一个现成的系统。
现在我想介绍在一定时间后自动打开这些开关的可能性:A time switch
time switch 现在使用 "normal" switch。
normal switch 不必了解time switch 的任何信息。
但是现在客户可以从switch-bag 中提取normal switch,现在他还想访问与这些normal switch 相关的time-switch,也许是为了配置一个新的时间。
这是我的问题,客户如何才能到达time-switch?
有几种可能:
- 我将
normal switch类重构为第三类,其中normal-switch和time switch捆绑在其中。但为此, 我破坏了其他一些仍然使用normal switch的客户端代码,但是 现在从 switch bag 中取出一个“Combinator”-Class/Object。 - 我不会更改
normal switch类的任何内容。客户如果他 想要访问time switch必须询问与time switch相关的地图。 (我认为这种方法是经典的 关系编程风格,如 sql 关系数据库及其 不再是真正的面向对象风格) - 我扩展了
normal switch:这里我也有不同的选择:- 我将其更改为一个大外观,它将调用委托给
normal-switch和time switch(类似于我的第一个解决方案 组合器,但这里有一个门面,不会破坏一些现有的 客户端代码) - 我扩展了
normal switch让现有的normal switch代码 原封不动,并介绍了一个组件持有人。进入这个组件 持有人我注入time switch。所以我有这些方法:switchOn();switchOff();getComponent("timeSwitch")。但是这些 方法感觉就像一个实体组件系统 (https://medium.com/ingeniouslysimple/entities-components-and-systems-89c31464240d) 但这仍然是面向对象的编程吗?
- 我将其更改为一个大外观,它将调用委托给
我认为最后一种解决方案是最好的,因为它最灵活。
但是您认为哪种方法最好,也许是我在这里没有提到的一些方法?
编辑:
您还必须在这里知道一件事:time switch 是normal switch 的一个扩展。其中之一。所以我当然想向normal switch添加更多不同的东西XYZ开关/行为扩展
【问题讨论】:
-
这家伙会说要避免使用继承(扩展),因为你无法预测你想用你的开关做什么的未来。 youtube.com/watch?v=wfMtDGfHWpA也就是说,我觉得你的问题不会有答案,因为不够集中,而且没有代码。
-
让事情尽可能简单。
-
@Fuhrmanator 它与继承无关(是的,我的问题中的扩展这个词可能会产生误导;但它更像是我通过在其中添加更多代码来扩展它^^,例如我添加了一些列表到正常开关,因为我可以将时间开关保存为相关组件(实体组件......),这样我以后可以轻松地从正常开关中获得时间开关,而不会中断电流客户端代码)
标签: oop design-patterns architecture composite