类的层次结构设计

图1

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

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

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

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

  • 0
    点赞
  • 0
    收藏
    觉得还不错? 一键收藏
  • 0
    评论

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值