设计模式原则—单一职责原则（二）

  单一职责原则解释：就一个类而言，应该只有一个引起它变化的原因

   . 我跟大家一样不喜欢看教条，教条太抽象不好理解，那我就举个生活中的例子便于大家理解我们知道现在的手机有拍照，打电话，彩信，摄像，听歌等等很多功能，我们出去旅游的时候其实只要带一个手机就好了，坐在车上无聊的时候可以听歌，打游戏，欣赏风景的时候可以拍照，碰到趣人趣事得时候还可以摄像，真是好啊，但是仔细想想，手机听歌有MP4或MP5声效好吗？打游戏有PS效果好吗？拍照有数码相机像素高吗？摄像有SONY摄像机效果好吗？答案是没有，其实有时候一件产品简单一些，职责单一一些或许是更好的选择

   . 我们有时候在做编程的时候，很自然而然的会给一个类增加这样那样的功能，比如：我们要做一个网站，会给这样一个default.aspx.cs后台文件加入算法的代码，数据库访问的SQL语句，业务逻辑的代码等等都写到这个类文件中，这就意味着，无论任何需求要来，你都需要去动这个类文件，这其实是很糟糕的，维护麻烦，复用根本不可能，更别提灵活性了，假如你又要做一个类似的应用程序，不过它运行的平台是手机，Web界面的程序不能使用，那之前的这个Web应用程序如何移植到手机上以达到复用的效果

   . 所以至少至少我们可以将程序分为两个类，一个是业务逻辑类，一个是界面UI类，当有一天要改变界面的时候，不过是界面表现类的变化而已，和业务逻辑类无关，以此达到复用的目的

   . 如果一个类承担的职责过多，就等于把这些职责耦合在一起，一个职责的变化会限制这个类完成其他职责的能力，这是种脆弱的设计，当需求发生变化时，这种设计就崩溃了

   . 其实我们以前经常做的三层架构就体现了单一职责原则，业务逻辑层处理业务逻辑，数据访问层访问数据库，表现层处理界面