岚天逸见

类的层次结构设计

20682147_1337742629u2Rn.png

图1

在写程序时,我们会经常遇到如上图所示的一种情形——深层调用,ClassD1和ClassD2需要调用ClassA关联的ClassX、ClassY和ClassZ等,对于这种情况,经常见到通过构造函数一层层往下传递做法。

这做法有什么不好了?它不符合开闭原则,当新增一个依赖类时,就需要增加一个参数,结果会导致参数列表膨胀,样子也非常难看。

那究竟怎么做更好了?对这个问题思考过很多次,但并没有找到一个完全满意的解决方案,针对这种情形,我主要采取两种方法:
1.尽量让ClassA成为一个单例,这样ClassD要获取ClassX等就非常方便了,即使增加一个ClassX1也非常方便,符合开闭原则,简单明了;
2.但并不是每种情况下,都允许ClassA成为单例,这个时候采用第二种办法,即总是通过构造函数将ClassA往下传递,如ClassB(ClassA*);ClassC(ClassA*);ClassD(ClassA*),这种办法也是符合开闭原则的,再增加一个ClassX1也非常方便;

办法是提出来了,但这并不是最优的,这种情形就如同一个公司或一个组织人数众多,在采取以上两个方法 之间,就好先考虑组织的扁平化,减少信息的传递层次,增加传递效率。

posted on   岚天逸见  阅读(177)  评论(0编辑  收藏  举报

编辑推荐:
· .NET Core 中如何实现缓存的预热?
· 从 HTTP 原因短语缺失研究 HTTP/2 和 HTTP/3 的设计差异
· AI与.NET技术实操系列:向量存储与相似性搜索在 .NET 中的实现
· 基于Microsoft.Extensions.AI核心库实现RAG应用
· Linux系列:如何用heaptrack跟踪.NET程序的非托管内存泄露
阅读排行:
· TypeScript + Deepseek 打造卜卦网站:技术与玄学的结合
· 阿里巴巴 QwQ-32B真的超越了 DeepSeek R-1吗?
· 【译】Visual Studio 中新的强大生产力特性
· 【设计模式】告别冗长if-else语句:使用策略模式优化代码结构
· 10年+ .NET Coder 心语 ── 封装的思维:从隐藏、稳定开始理解其本质意义

导航

统计信息

点击右上角即可分享
微信分享提示