Dojo
最新
最佳
搜索
订阅
解道Jdon
架构设计
领域驱动
DDD介绍
DDD专辑
战略建模
领域语言UL
领域事件
商业分析
工作流BPM
规则引擎
架构师观点
数据工程
产品经理
系统思维
微服务
微服务介绍
微服务专辑
模块化设计
SOA
API设计
clean架构
SpringBoot
分布式事务
事件溯源
Kafka消息
Kubernetes
DevOps
编程设计
GoF设计模式
模式专辑
面向对象
函数式编程
编程语言比较
编程工具比较
形式逻辑
前端编程
Reactive编程
Jdon框架
Rust语言
人工智能
Web3
模因梗
幽默梗
程序员吐槽
面试技巧
Java入门
数字化转型
认知偏差
道德经
更多话题
设计模式趣味谈
02-08-26
why10k
老板交给总经理一项任务,总经理觉得一下子做不完,怎么办呢?分给五个副经理分别做吧,副经理们又按同样的思路分给各各项目经理,一直到工作人员.当然这个过程有不同的分配方式,由此产生了不同的
设计模式
.
现在总经理很轻松,各级领导也很轻松,工作人员也很轻松,因为他们只要完成一件事就好了.挺完美的系统吧.
可是编程序的时候你既是总经理,又是副经理,还是工作人员,分来分去所有的事还得自己做,记性好呢这些模式很好,灵丹妙药,记性不好就有点惨,调程序跟踪进去忽然发现一个方法调用是接口方法,真正的类在哪呢,程序大了真是乖乖的不的了,模式很巧妙,也通常是代码膨胀的源泉,能真正掌握模式的程序员恐怕百分比也不是很大,一个项目组工作起来就有点问题,项目工期会更长吧?有些时候读代码真有点累,明知道三五句话就能完成的功能,你就不知道他在说些什么,哈哈,我脑袋有点大,不过这样也好,反正老板给银子,时间越长越好.
不知道大家有何感想?
banq
2002-08-26 17:30
你说的不是真正的模式,如果严格按照模式来做,每个角色都是固定的,不会有太多class或接口。
关于代码膨胀,是系统可重用性增强的一个象征,膨胀的程度,需要控制,原则很简单,每个class或每个方法尽可能简单明了,责任明确而单一。这就需要对代码进行refactor,所以并不是编程完成后就可以了,还需要refactor,refactor后,再增加新功能,会轻松明了。
不能把简单问题复杂化,这也是refactor一个目标。
关于refactor由谁来做,最好自己做,或者由系统设计师来做。
cc
2002-08-27 13:28
Banq说得对,但是不是只有大的系统才适合做
设计模式
呢?
几个设计师将所有的设计用类图表现出来,这时候,虽然代码还没有编,但基本上已经宣布了软件开发的大部分已经完成。这样才能发挥模式的重要性!
banq
2002-08-27 17:22
设计模式使用无论系统大小。
创建型模式和结构型模式对于中大型系统应用较多。
但是很多行为模式是不分大小系统,具体说如Iterator
几乎都要用
cc
2002-08-28 11:38
是的,Iterator是非常普遍的模式,你也曾经说过自己做Iterator当数据集。
模式的根本还是利用继承与多态。
用
设计模式
重构才是最关键的。
banq
2002-08-28 13:28
你总结得很正确,模式可以说就是围绕继承和多态展开。
在开发系统时,很少有能一下子确定使用什么模式,只有在重构(refactoring 或叫重整)时,才能发现并实现。
设计模式