看“单一职责原则”的感悟

    最近开始拜读AnyTao的《你必须知道的.NET》，在面向对象的大原则中，他罗列出了七个设计原则，其中“单一职责原则”就是他所谈的第一个。对于这个他里面有一段比较经典的思想：一个类，最好只做一件事情，只有一个一起它变化的原因。正如他所举的例子来说，相对很现实。将验证条件功能和对数据进行增删改查的功能分开，让一个类中只会去做一件事情，这样的好处，我的粗浅认识是：第一便于代码调试，容易将代码的Bug找出来，一个类只完成一件事情，相对调试能简单很多，让其他人员能更快更好的读懂代码、理解这个类的功能；第二是如果一个类的职责过多，就很容易将这些职责耦合在一起，这样的话，一个职责的变化，可能就会影响其他职责的功能，这样的话就可能出现意想不到的后果。
    看到AnyTao在这书上举的数据库管理系统的例子，我就很快联想到以前自己开发的东西，以及现在手头的一些和这个相似的代码，忽然觉得自己自己是应该好好的从面向对象的角度考虑问题。现在做的东西，好多东西没有很好的规划，因为没有架构师，我们只能自己去琢磨，每个人都只是从用户的功能上去考虑，加上领导们只关注项目的进度，从来也不会正确的对待软件的开发周期、流程等内容，在代码方面相对很宽松，只要能完成客户的需求一切万事大吉；当做完几个项目下来，发现自己的开发水平并没有提高多少时，发现自己和正常的软件开发思路已经偏了。
    经过比较长时间的和客户沟通交流，能明白客户的需求，虽然有时候一个需求要经过好多次的交流，最终还是能满足客户的需求；现在的问题就出现了，软件的需求知道，但是真正的将他转换成非常合理的设计还是比较困难的；我现在觉得这方面的水平不怎么样，有了整体的需求，但是对一个软件来说，还是不够的；而现在自己的欠缺就在这里。虽然知道要将一个系统的一些公共的部分提炼出来、将相类似的内容整合到一个模块中，将调用数据库的公用类都单独的提出来。但是具体到细节，却不知道如何下手，我相信，应该有很多人有我相同的想法，也不知道怎么解决。通过看这书，发现有些内容平时可能都在使用，但是就是在无意识的情况下，很多的东西，都没有很好的考虑。这也是自己没有好好看软件设计的相关内容造成的。
     以前总觉得，解决一些应用性的小问题，很有成就感，但是现在现在发现，做好一个软件的设计工作更是一件美妙的事情，虽然这工作开始可能很枯燥、无味，但是我一定会坚持下去，把自己的不知、不足都找出来，加强起来。