习惯1:构造器实现最少的工作
第一个习惯是一个对象的构造器只能实现尽量少的工作。理想的,构造器仅仅是通过它的参数载入数据到它的实例变量。
另一方面,状态的改变和行为方法的名称使用描述性的名称来表达它们更加复杂的意图,就像在"习惯2:方法名要清晰地表达方法的意图"描述的那样。
另一方面,那些构造器的功能超过载入实例变量的对象是难于理解的,并且容易被误用,因为它们的名称没有传递它们的意图。
习惯2:方法名清晰的表达方法的意图
第二个习惯是,通过它们的方法名,所有的方法必须清晰的传递它们的意图。
长的、描述性的方法名帮助开发团队迅速的理解他们的软件的意图和功能。
应用这种技术到测试方法的名称,使得测试表达了软件现有的需求。
描述性的方法名减少了对于常规文档或者Javadoc注释的需要。
习惯3:一个对象执行功能集中的服务集
软件的每一个对象都集中的执行一个小的、独一无二的服务集。
执行小基数工作的对象容易阅读,容易正确使用,因为只有少量的代码需要理解。此外,软件的每一个对象都必须执行独一无二的服务集,因为重复的逻辑浪费开发人员的时间,增加维护的成本。
习惯4:状态改变方法包含最小限度的行为逻辑
混合状态改变逻辑和行为逻辑使得软件理解起来更加的困难,因为它增加了在一个地方发生的工作的数量。状态改变方法通常是用来获取或发送数据到一个远程的数据存储设备,因而容易在产品系统中出现问题。诊断一个状态改变方法的系统问题在远程调用被独立的时候更容易一些,这时候它完全不含有行为逻辑。此外,两者的混合还制约了开发过程。
习惯5:行为方法能够在任何条件下被调用
一个对象的行为方法能够被重复和以任何顺利调用。这个习惯使得对象传递固定的行为。