请版主删除此帖子

我看懂了，写的很清晰

说实话那些写设计模式的书我看上边的例子都不是很理解，赶脚都是硬套上去的。哥们多写点吧，让我也提高一下。

一个小问题，却需要这么多类,想象力是有坏处的。
注意呀，别变成这样的人：
http://www.iteye.com/news/27020

另外，具我所知。

领域模型、分析模型、概念模型 三者同意，都是OOA中的工件。它基本的特征是类图里没有方法。

你下文的描述，都是在说设计，这应该是OOD中的事。所以个人觉得很有问题。

如果，软件设计，是想到什么就可以做什么的话，真不知软件会做成个什么样子。

关于你说的想象力的问题，其实是关于过度设计的讨论。
我承认“这是一个简单而直接的设计。当然正在的项目这么做也许就足够了..."这一段之后确实有过度设计的迹象，而且文中提到了。
但是前面那些完全没有过度设计的问题，如果你遇到这个需求，你没做到这些.只能说明你不是合格的开发人员。
另外，过度设计不好，但也不要拿过度设计当作不去设计的借口。

“据你所知”后面那一段话，未免太八股了吧。经验不足的充分体现。初学者往往喜欢这么八股教条生搬硬套的去考虑问题。就两句句提醒：想想什么是设计，为什么而设计？

若我实现你说的功能，可能只是一个类里的几个方法就足够了。
从用例出发，首先要设计界面上的交互功能，这直接会影响软件设计。

总有人把我当初学者，真是奇怪呀！

若我实现你说的功能，可能只是一个类里的几个方法就足够了。
从用例出发，首先要设计界面上的交互功能，这直接会影响软件设计。
-------------------
你能把一个需求写在一个方法里实现，但是也能分成N个方法实现，或者用N个类去实现，或者其他的什么方案实现。
这时候你就要综合各方面因素考虑一下，我选择哪个方法更好。这个过程就是设计，就是架构。当然你也不能闭关三月去考虑。这就是过度设计。
这中间你要有个权衡。

总有人把我当初学者，真是奇怪呀！
-------------------
这个...我可能错怪你了。但是我的意见就是，你先理解别人的意见在发表观点。这样你就会让人感觉你成熟很多。（个人意见，未免偏颇）


如果这是学校老师布置给我的一个作业，我会毫不犹豫的在一个静态方法里完成这些需求。

一个功能你都能“毫不犹豫”的作完了，这说明这东西复杂度很低，用不着用什么设计模式。

看来项目管理工作，真是难免政治斗争。道理讲不通，除了行政手段，也没有别的办法。

楼主， 下一个处理器可以在剥离下, 单独整一个处理器的管理逻辑；
另外：checker 直接继承process本身没有问题， 但在语义上感觉怪怪的。建议增加一个另一个接口吧。checker \process 同时继承一个接口不利于后续的进一步的演化。比如说，图片在处理之前都要先备份一次.

gdpglc 提到的，其实是一个需求边界的问题。
也要看你这个功能的重要程度。如果仅是一个非功能性需求，使用修改都不频繁，整这么复杂，项目还要不要进度了。

自己学习，怎么复杂都没事，最好二十三种模式都用上，compress部分你搞个策略模式，在弄出N种算法来。

另外，Processor跟ResultProcessor一点关系都没有，改个名吧