类的层次结构设计
原创
©著作权归作者所有:来自51CTO博客作者一见_的原创作品,请联系作者获取转载授权,否则将追究法律责任
在写程序时,我们会经常遇到如上图所示的一种情形——深层调用,ClassD1和ClassD2需要调用ClassA关联的ClassX、ClassY和ClassZ等,对于这种情况,经常见到通过构造函数一层层往下传递做法。
这做法有什么不好了?它不符合开闭原则,当新增一个依赖类时,就需要增加一个参数,结果会导致参数列表膨胀,样子也非常难看。
那究竟怎么做更好了?对这个问题思考过很多次,但并没有找到一个完全满意的解决方案,针对这种情形,我主要采取两种方法:
1.尽量让ClassA成为一个单例,这样ClassD要获取ClassX等就非常方便了,即使增加一个ClassX1也非常方便,符合开闭原则,简单明了;
2.但并不是每种情况下,都允许ClassA成为单例,这个时候采用第二种办法,即总是通过构造函数将ClassA往下传递,如ClassB(ClassA*);ClassC(ClassA*);ClassD(ClassA*),这种办法也是符合开闭原则的,再增加一个ClassX1也非常方便;
办法是提出来了,但这并不是最优的,这种情形就如同一个公司或一个组织人数众多,在采取以上两个方法 之间,就好先考虑组织的扁平化,减少信息的传递层次,增加传递效率。
上一篇:mooon-agent核心设计图
下一篇:常用vim设置
提问和评论都可以,用心的回复会被更多人看到
评论
发布评论
相关文章
-
「从ES到CK 04」Clickhouse表引擎选择和表结构设计
介绍日志平台的clickhouse表引擎选择和表结构设计
表结构 clickhouse ck 日志平台 -
表结构设计
在权限系统中,最核心的三张表为:用户表、角色表和菜单表(权限表),它们间的
RBAC ci 表结构 修改时间

















