|
锁定老帖子 主题：请版主删除此帖子
精华帖 (1) :: 良好帖 (0) :: 新手帖 (1) :: 隐藏帖 (0)
|
|
|---|---|
| 作者 | 正文 |
|
发表时间：2013-01-28
robert.wei 写道 楼主， 下一个处理器可以在剥离下, 单独整一个处理器的管理逻辑；
另外：checker 直接继承process本身没有问题， 但在语义上感觉怪怪的。建议增加一个另一个接口吧。checker \process 同时继承一个接口不利于后续的进一步的演化。比如说，图片在处理之前都要先备份一次. 可以详细说明一下么？ |
| 返回顶楼 | |
|
发表时间：2013-01-28
nighthawk 写道 gdpglc 提到的，其实是一个需求边界的问题。
也要看你这个功能的重要程度。如果仅是一个非功能性需求，使用修改都不频繁，整这么复杂，项目还要不要进度了。 自己学习，怎么复杂都没事，最好二十三种模式都用上，compress部分你搞个策略模式，在弄出N种算法来。 另外，Processor跟ResultProcessor一点关系都没有，改个名吧 改名这个建议提的好，是一个改善点。谢谢提醒。 其实这种类型的文章只要一出来，就肯定跟着一种非议的声音“过度设计” 现在“过度设计”往往被一些根本不懂设计的2货选手用来“炫耀”自己知识渊博的有力武器。 真的要倡议大家要先懂得设计，再研究“过度设计”。 软件的复杂性来自于哪儿？难道用一个有明确意义的类来分割一个冗长方法的一部分就增加复杂性了？ 很多不懂设计，不懂面向对象（暂不讨论面向对象的利弊这么高深的问题）的人认为。把事儿都在一个方法（或者有点儿经验的人会用一个类的多个方法）里实现，就是简单，多了一个类，就像要了他们的命一样，他们会高喊“过度设计”。 软件的复杂性在哪里？设计为了什么？ |
| 返回顶楼 | |
|
发表时间：2013-01-28
对了，还有一点：
“compress部分你搞个策略模式，在弄出N种算法来。” compress部分不是策略模式，是适配器模式。 这么做这不是过度设计的结果，依赖于既有组件完成系统功能，最好使用一个接口隔离。 这是一个设计常识。 弱弱问一句，这么做增加复杂性了么？ |
| 返回顶楼 | |
|
发表时间：2013-01-28
不错，可惜例子的场景太小了
|
| 返回顶楼 | |
|
发表时间：2013-01-28
zengjd 写道 对了，还有一点：
“compress部分你搞个策略模式，在弄出N种算法来。” compress部分不是策略模式，是适配器模式。 这么做这不是过度设计的结果，依赖于既有组件完成系统功能，最好使用一个接口隔离。 这是一个设计常识。 弱弱问一句，这么做增加复杂性了么？ 我觉得第二张图就已经达到了设计与实现的平衡点了，既保证了扩展，又方便可能会给其他同事的使用。 DBAccesser我觉得没必要加在这个链中。 |
| 返回顶楼 | |
|
发表时间：2013-01-29
nighthawk 写道 zengjd 写道 对了，还有一点：
“compress部分你搞个策略模式，在弄出N种算法来。” compress部分不是策略模式，是适配器模式。 这么做这不是过度设计的结果，依赖于既有组件完成系统功能，最好使用一个接口隔离。 这是一个设计常识。 弱弱问一句，这么做增加复杂性了么？ 我觉得第二张图就已经达到了设计与实现的平衡点了，既保证了扩展，又方便可能会给其他同事的使用。 DBAccesser我觉得没必要加在这个链中。 确实是这样的，实际项目中，到第二张图基本架构设计阶段就结束了。也足够用来。 DBAccesser确实值得商榷的。 |
| 返回顶楼 | |
|
发表时间：2013-01-29
robert.wei
楼主， 下一个处理器可以在剥离下, 单独整一个处理器的管理逻辑； ------------------------- 这句话我是非常赞同的.. |
| 返回顶楼 | |
|
发表时间：2013-01-29
解未知数 写道 robert.wei
楼主， 下一个处理器可以在剥离下, 单独整一个处理器的管理逻辑； ------------------------- 这句话我是非常赞同的.. 没太明白怎么做，可以详细点不 |
| 返回顶楼 | |
|
发表时间：2013-02-05
中国功夫是学会了招放到一块就是高手了。
软件真不是这样的... |
| 返回顶楼 | |
