理想的软件设计标准

     前几天一个朋友提到我的博客中空空如也。确实，到园子里也有段日子了。确实也该放点东西了。要不也太对不起DUDU了。这几天又比较清闲,将读书笔记及自己的心得记录下来
     McConnell 大侠说如果设计能实现如下目标，那么就是非常好的设计了。
    一:最少的复杂度
        简单来说，就是要易于理解。McConnell特别还指出了要避免“聪明的”设计。  另外我们在设计某处的时候要能够安全的忽视其它部分才算合格。
   二:易于维护
       这点主要是为做维护工作的程序员着想的，不过我们写的代码，大多数时候做维护的还是自己吧。如果你能一看函数名或代码就能了解它们的作用的话也就OK了。
   三：松耦合
      作为软件设计的军规之一。各部分的关联越少意味着你在测试，集成，维护的时候可以轻松不止一点点。
   四：可扩展
      套用句"古话":做软件唯一就是变化。如果你的作品是不可适用变化的话，基本上就可以贴上不合格的标签了。也许你会说我改代码就可以了。当然可能要修改代码，但面向对象的设计原则里有条，类是可扩展还不可以修改的。扩展一般是通过继承来是想的。而修改特别是接口往往会引起许多莫名其妙的问题的。总之：你在给自己软件加功能的时候不要对底层甚至架构大动干戈就对了。
   五：高扇入
     扇入？扇入是什么东东？我以前还真不知道（我专业是物理学，半路出家写代码的！）仔细一看原来就是指被其它类或方法引用。那高扇入也就是说你这个类/方法...被很多其它类引用了。也就是利用率很高了。按照我的想法如果段代码我连写了三次,我就会把它单独作为一个方法或类
   六:低扇出
      扇出自然就是引用其它类或方法了.按Bob大叔的说法，扇出越高，类就越不稳定，因为任何一个引用对象出问题了，这个类也就会出问题。另外McConnell 说了：引用超过约七个就算高扇出了.
  七：可移植
      这点我觉得大家设计的时候还是得MVC啊。要不哪天客户要求你从B/S转为C/S你就有的忙了。这点我觉得喜欢在页面写逻辑的兄弟得特别注意了。虽然看起来没有双击就写代码那么爽，可实际还是能省不少事的。
  八：精简性
     能少不多，你不能觉得工厂模式爽，就有事没事都加上，这是不对的。另外写《移山之道》的邹欣也说过,程序员不能觉某个功能可能有用你就加上.因为这会增加测试等方面的任务,而且程序员认为用户会喜欢的往往用户偏不喜欢
  九：层次性
     层次性，最常见的就是大家说的三层架构了。好处有几个，你换了数据库而不必管上层。另还有一个就是更好的分工。经验不足的小伙子写的初级代码可以禁闭起来。以后想重构就重构，想换掉就换掉。也就减少了复杂度了。
  十：使用标准技术
     这样会给大家熟悉的感觉.如使用相同的框架,代码风格应该使用相同的标准，可以套用设计模式的就套用一下咯，不要自己整个新的花样出来，毕竟看熟悉的东西容易理解。
   
     代码大全上就这么十点，我觉得还可以加上一点，
   十一：高内聚
       也就是说一个类特别是一个方法应该专注于一件事。比如你的 I男朋友可以有陪女朋友()方法，但就不可以有写代码()方法。因为写代码()方法是I程序员接口才有的.
      而在陪女朋友()方法中你不可以顺便就将花钱这个操作加在里面,因为偶尔有一次陪女友是陪她在家看电视的,自然也就不需花钱了.