1、保持系统最大可测试 只要系统可测试并且越丰富的单元测试越会导向保持类短小且目的单一的设计方案,遵循单一职责的类,测试起来比较简单。 遵循有关编写测试并持续运行测试的简单、明确规则,系统就会更贴近OO低偶尔度,高内聚度的目标。编写测试越多,就越会遵循DIP之类的规则,编写最大可测试可改进并走向更好的系统设计。 2、避免重复 重复是拥有良好设计系统的大敌。它代表着额外的工作、额外的风险和额外且不必要的复杂度。除了雷同的代码,功能类似的方法也可以进行包装减少重复,“小规模复用”可大量降低系统复杂性。要想实现大规模复用,必须理解如何实现小规模复用。 共性的抽取也会使代码更好的符合单一职责原则。 3、更清晰的表达开发者的意图 软件项目的主要成本在于长期维护,当系统变得越来越复杂,开发者就需要越来越多的时间来理解他,而且也极有可能误解。 所以作者需要将代码写的更清晰:选用好名称、保持函数和类的短小、采用标准命名法、标准的设计模式名,编写良好的单元测试。用心是最珍贵的资源。 4、尽可能减少类和方法 如果过度使用以上原则,为了保持类的函数短小,我们可能会造出太多细小的类和方法。所以这条规则也主张函数和类的数量要少。 如应当为每个类创建接口、字段和行为必须切分到数据类和行为类中。应该抵制这类教条,采用更实用的手段。目标是在保持函数和类短小的同时,保持系统的短小精悍。不过这是优先级最低的一条。更重要的是测试,消除重复和清晰表达。
1.通过所有测试(Passes its tests) 2.尽可能消除重复(Minimizes duplication) 3.尽可能清晰表达(Maximizes clarity) 4.更少代码元素(Has fewer elements)
版权声明:本文内容由阿里云实名注册用户自发贡献,版权归原作者所有,阿里云开发者社区不拥有其著作权,亦不承担相应法律责任。具体规则请查看《阿里云开发者社区用户服务协议》和《阿里云开发者社区知识产权保护指引》。如果您发现本社区中有涉嫌抄袭的内容,填写侵权投诉表单进行举报,一经查实,本社区将立刻删除涉嫌侵权内容。