学会思考

        已经很久没有更新blog了。这些天一直为一个自命名为“资源编辑器”的小项目而忙碌。今天终于给我的老大交了“成果”，先也不管老大如何臭骂我等小子的无知和狂妄，先给自己定个基调再说。

       项目虽然很小，但五脏俱全。从需求分析，到设计，到编码实现等等都有一定的规范，当然只是一定程度上的。所以，从这个个小小的项目中我学习到之前所无法体会的设计的快乐(Happy for Design).

      给自己制定项目计划这是第一步(之前的项目风险分析等等这里就没有了,毕竟练手而作)。如何设定计划，可以看出有设计和项目经验的人和普通的Coder的差距。我开始认为8-9时间，至少要用5天coding.但是这样的提法，马上招来异议。把编码时间设定之长，必定要损失设计的时间，而如果不能保证设计的时间，以后反工的时间会更加长，甚至失败。这样的说法简单，实现真难。后来我决定：

这样的设定表面上看起来已经开始重视设计了 :)

在整个项目过程中，UML图是设计思路的展现。在需求分析阶段，有了用例图：

进入类设计是非常让人兴奋的。之前学习OO,学习模式，这些东西只有在设计的时候，但是从来没有给自己这样的机会，总是没有这样的思路，没有有效的方法来进行。如果你要我写一两个类，实现某种功能，也许还可以，但是如果要我用OO,用自己的类来组织一个系统，哈哈，怕怕！这次感谢老大我这样的机会和丰富的指导。让我大胆的写自己核心类库。通过类图来展现这一切是最好的选择：

其中必定有错误和不足够，但是这时我已经体会到了Design的快乐。不用在纠缠于实现的细节，转而去按照自己的思路去思考问题，真是快乐的事情:)

对于类设计，很多朋友肯定和我有过一样的感觉，不知道如何入手，如何把某项功能放在那个类中。是的，这也是我最大的困扰之一。通过时序图来分析类方法似乎确实是个不错的方法:)（这是老大说的，感谢ing）！

写了这么多似乎并没有最大的表达我的想法。

最后说一点，就是设计与实现的矛盾。

和很多朋友一样，花大把大把的时间来研究某个技术实现，来研究一个细节性的问题。记得<<Clouds to Code>> 有这样一句话，大概是这样的：几乎没有一件事情比谈论细节层次更低，除了优化。是的，如果在项目设计阶段过多的考虑细节，考虑如何实现，将使你分心，同时使你不能真正的关注设计层面，思考的过程也会经常被打断。通过这个项目，我也体会到了这点。

好好的设计，分清类的职责，让各个类做自己的事情，困难的实现都会被分解。

很遗憾这个项目中没有用到模式的，不是没有可用的地方，而是因为缺乏重构的能力。没有能够发掘出来而已。我感觉RFileEditor这里就可以用Singleton模式.我是把它设计成一个abstract的类，通过static提供服务。

初次设计，也不谈的太多。不想误人，自己做个备注而已:)

最后贴出界面截图：

 

如果你对模式有兴趣，加这个群哦：26227899。

 

2006-9-25