一、 类
类通常由变量、属性和方法组成。按照书中所讲的Java的约定，类应该由一组变量开始，如果有静态公共常量，应该放在前面，然后是私有静态变量和私有实体变量。公共函数跟在变量之后，一些供公共函数调用的私有工具函数在公共函数之后。
和函数一样，类也应该要尽可能的短小。但和函数不同不是以代码行数来权衡，而是以职责。如果无法准确的为某个类命名，则有可能是该类的职责过多。
单一职责原则（SRP）：类或模块应该有且只有一条加以修改的理由。
在实际的工作中很多开发人员往往不会思考这么多，他们只想着让代码可以工作就可以了，所以经常出现几千行的大类。系统应该是有许多短小的类而不是少量巨大的类组成。每个小类有单一的职责，只有一个修改的原因，所有这些小类在一起协同工作完成系统的功能。
- 高内聚：如果一个类中每个变量都被每个方法所使用，则该类有最大的内聚性。
高内聚低耦合：提出与结构化编程，内聚表述模块内部功能不同操作逻辑之间的距离，如果一个类的每个变量都被每个方法所使用为最大的内聚；耦合描述模块之间的依赖程度；高内聚低耦合以简单的方式表述就是功能完备（高内聚）对象之间是通过稳定的接口（低耦合）交互的。保持内聚性得到许多短小的类。
重构函数也会促使类职责的分离，看下面场景：
将一个有许多变量的大函数拆分成小函数，如果拆出来的代码使用了其中4个变量，那么就会将这4个变量作为参数传入到小函数中，如果使用的变量越多，就意味着小函数的参数越多，这时可以讲这4个变量升级成实体变量，小函数就不需要参数了，可以直接使用这些变量。这样就使内聚性变低，因为类中有很多的变量只为少数的函数服务，这时就可以将这些变量和函数拆分出来，单独成类。
- 开放闭合原则（OCP）
类应当对扩展开放，对修改封闭。我们可以借助接口和抽象类来隔离这些细节带来的影响。
- 依赖倒置原则（DIP）
描述组件之间高层组件不应该依赖于底层组件。依赖倒置是指实现和接口倒置，采用自顶向下的方式关注所需的底层组件接口，而不是其实现。DI模式很好的就是应用IOC（控制反转）框架，构造方式分为构造注入，函数注入，属性注入。
小结：
- 类第一原则应是是小并足够的小。
- 单一原则（SRP）
- 内聚
- 依赖倒置（DIP）
- 开放闭合原则（OCP）
二、 注释
注释是一把双刃剑，好的注释能够给我们好的指导，不好的注释只会将我们误导。注释是弥补代码子表述不足的一种手段，就像设计模式是用来弥补语言不足一样。
代码是我们获取信息的准确来源，注释随着项目人员的更替，反复的修改最终可能词不达意了，因为很多开发人员在整合代码，修改方法的时候并不是总是同步修改注释。
有时候看到一个函数的代码写的很糟糕，逻辑很混乱，有开发人员可能想，给这个函数加上几行注释，这样有可能起到适得其反的作用，这时要做的是将函数整理干净。
代码即注释，很多书和大师都这么讲，意思是我们要用代码本身来解释我们的意图，那就要求我们要控制好函数只做一件事，函数名和变量名要规范和可读。
当然也不是所有的注释都没有用，像下面几种类型的注释是有必要的：
具有警示性的注释；
描述一些负责业务场景；
有些函数现在还是一个空壳，但在将来可能有用，有必要写。
当我们不得不写一些注释的时候，要确保言简意赅，能够很好的表达意思，不要造成误解，也不要写多余的废话。
还有一种注释被称为日志式注释，一般出现在一个类的开始部分，记录每次修改时的时间、人员名称和修改内容。随着时间的推移这类注释会变得非常冗长。这类注释在一些项目中很普遍，而且有时会被严格要求写，但书中强调现在的源代码都会有源代码工具来进行管理，修改记录在源代码工具中有保存，这种日志式的注释应该全部删除。
项目代码中经常会出现被注释掉的代码，这对后面的维护人员会造成困扰，也会使代码变得混乱，这种代码同样可以删掉，因为我们有源码管理工具。
对于书上的这段描述传结合亲身经历产生了异议，和大家讨论一下。
经历1：
Merge。
很多公司都会为新的feature，或fix defect而开辟新的分支，而当分支合并时原始分支的历史版本，可能将会丢失。
经历2：
根据重构的需要，有些模块需要搬迁到新的文件中，有些文件需要新命名/重命名。
而在有些版本控制工具中，如SVN，重命名一个文件，它是当作删除然后添加过来处理的。这样一来，新的文件将会有新的历史，而原来的历史，已随老的文件烟消云散。
也许，从版本控制中还能找回被删除的老的文件。但如果作为一个新接触的员工，对于将重命名分解为删除和添加的操作而言，谁又知道以前被删除的文件是哪一个？时间长了，老员工也记不住啊！
总结：
对于以后有影响的或者增强性能比对的注释，请不要删除。除非确定以后真的不再需要。因为，版本控制工具，其实并不能满足我们所想象的需求。
