本文来源:http://r6d.cn/N3Szjava
“本文翻译自Programming Principles。程序员
每一个程序员均可以从理解编程原理和模式中受益。这篇概述用于我我的参考,同时我也把它放在这。也许这在设计、讨论或复查中对你有所帮助。但请注意,这还远远不够,你经常须要在相互矛盾的原则之间作出权衡。web
本文受The Principles of Good Programming启发。我以为这份列表已经足够了,但这并不彻底符合我我的的想法。此外,我还须要更多的论证、细节以及其余资料的连接。若是您有任何反馈或者改进的建议,请让我知道。编程
目录
通用
-
KISS (Keep It Simple Stupid) -
YAGNI -
作最简单的事情 -
关注点分离 -
保持事情再也不重复 -
为维护者写代码 -
避免过早优化 -
童子军军规
模块间/类
-
最小化耦合 -
迪米特法则 -
组合优于继承 -
正交性 -
稳健性原则 -
控制反转
模块/类
-
最大化聚合 -
里氏代换原则 -
开放/封闭原则 -
单一职责原则 -
隐藏实现细节 -
科里定律 -
封装常常修改的代码 -
接口隔离原则 -
命令查询分离
KISS
大多数系统若是保持简单而不是复杂,效果最好。微信
为何app
-
更少的代码能够花更少的时间去写,Bug更少,而且更容易修改。 -
简单是复杂的最高境界。 -
完美境地,非冗杂,而不遗。
相关资料框架
-
KISS principle -
Keep It Simple Stupid (KISS)
YAGNI
YAGNI的意思是“你不须要它”:在必要以前不要作多余的事情。编程语言
为何编辑器
-
去作任何仅在将来须要的特性,意味着从当前迭代须要完成的功能中分出精力。 -
它使代码膨胀;软件变得更大和更复杂。
怎么作函数
-
在当你真正须要它们的时候,才实现它们,而不是在你预见到你须要它们的时候。
相关资料
-
You Arent Gonna Need It -
You’re NOT gonna need it! -
You ain’t gonna need it
作最简单的事情
为何
-
仅有当咱们只解决问题自己时,才能最大化地解决实际问题。
怎么作
-
扪心自问:“最简单的事情是什么?”。
相关资料
-
Do The Simplest Thing That Could Possibly Work
关注点分离
关注点分离是一种将计算机程序分离成不一样部分的设计原则,以便每一个部分专一于单个关注点。例如,应用程序的业务逻辑是一个关注点而用户界面是另外一个关注点。更改用户界面不该要求更改业务逻辑,反之亦然。
引用Edsger W. Dijkstra (1974)所说:
“我有时将其称为“关注点分离”,即便这不可能彻底作到,但它也是我所知道的惟一有效的思惟整理技巧。这就是我所说的“将注意力集中在某个方面”的意思:这并不意味着忽略其余方面,只是对于从某一方面的视角公正地来看,另外一方面是不相关的事情。
为何
-
简化软件应用程序的开发与维护。 -
当关注点很好地分开时,各个部分能够被重用,而且能够独立开发和更新。
怎么作
-
将程序功能分红联系部分尽量少的模块。
相关资料
-
Separation of Concerns
保持事情再也不重复
在一个系统内,每一项认识都必须有一个单一的、明确的、权威的表示。
程序中的每一项重要功能都应该只在源代码中的一个地方实现。类似的函数由不一样的代码块执行的状况下,抽象出不一样的部分,将它们组合为一个函数一般是有益的。
为何
-
重复(无心或有意的重复)会形成噩梦般的维护,保养不良和逻辑矛盾。 -
对系统中任意单个元素的修改不须要改变其余逻辑上无关的元素。 -
此外,相关逻辑的元素的变化都是可预测的和均匀的,所以是保持同步的。
怎么作
-
只在一个处编写业务规则、长表达式、if语句、数学公式、元数据等。 -
肯定系统中使用的每一项认识的惟一来源,而后使用该源来生成该认识的适用实例(代码、文档、测试等)。 -
使用三法则(Rule of three).
相关资料
-
Dont Repeat Yourself -
Don’t repeat yourself -
Don’t Repeat Yourself
类似资料
-
Abstraction principle -
Once And Only Once is a subset of DRY (also referred to as the goal of refactoring). -
Single Source of Truth -
A violation of DRY is WET (Write Everything Twice)
为维护者写代码
为何
-
到目前为止,维护是任何项目中最昂贵的阶段。
怎么作
-
成为维护者。 -
不论什么时候编写代码,要想着最后维护代码的人是一个知道本身住在哪里的暴力精神病人。 -
若是某个入门的人掌握了代码,他们就会从阅读和学习代码中得到乐趣,以这样的想法去编写代码和注释。 -
别让我想(Don’t make me think). -
使用最少惊讶原则(Principle of Least Astonishment).
相关资料
-
Code For The Maintainer -
The Noble Art of Maintenance Programming
避免过早优化
引用Donald Knuth所说:
“程序员浪费大量的时间来思考或担忧程序的非关键部分的速度,而考研尝试这些优化实际上在调试和维护时有很强的负面影响。好比说在97%的开发时间,咱们应该忽略低效率:过早的优化是万恶之源。然而,咱们不该该在关键的3%中放弃咱们的机会。
固然,须要理解什么是“过早”什么不是“过早”。
为何
-
瓶颈在哪是未知的。 -
优化后,阅读和维护可能会更困难。
怎么作
-
使它运做,使它正确,使它更快(Make It Work Make It Right Make It Fast) -
不要在你不须要的时候优化,只有在你发现一个瓶颈以后才能优化它。
相关资料
-
Program optimization -
Premature Optimization
最小化耦合
模块/组件之间的耦合是它们互相依赖的程度,较低的耦合更好。换句话说,耦合是代码单元“B”在未知的代码单元“A”更改后“被破坏”的概率。
为何
-
一个模块的更改一般会致使其余模块的更改,产生涟漪效益。 -
因为模块间的依赖性增长,模块装配可能须要更多的工做和/或时间。 -
特定的模块可能难以重用和/或测试,由于必须包含相关模块。 -
开发人员可能惧怕更改代码,由于他们不肯定什么会收到影响。
怎么作
-
消除,最小化和下降必要关联的复杂性。 -
经过隐藏实现细节,减小耦合。 -
使用迪米特法则。
相关资料
-
Coupling -
Coupling And Cohesion
迪米特法则
不要和陌生人说话。
为何
-
这一般会致使更紧密的耦合。 -
可能会暴露过多的实现细节。
怎么作
对象的方法只能调用如下方法:
-
对象自身的方法。 -
方法参数中的方法。 -
方法中建立的任何对象的方法。 -
对象的任何直接属性或字段的方法。
相关资料
-
Law of Demeter -
The Law of Demeter Is Not A Dot Counting Exercise
组合优于继承
为何
-
类之间的耦合减小。 -
使用继承,子类很容易作出假设,并破坏里氏代换原则(LSP)。
怎么作
-
测试LSP(可替换性)以决定什么时候继承。 -
当存在“有”(或“使用”)的关系时使用组合,当存在“是”的关系时使用继承。
相关资料
-
Favor Composition Over Inheritance
正交性
“正交性的基本概念是,概念上不相关的东西在系统中不该该相关。
来源:Be Orthogonal
“它越简单,设计越正交,异常就越少。这使得用编程语言学习、读写程序变得更容易。正交特征的含义是独立于环境;关键参数是对称性与一致性。
来源:Orthogonality
稳健性原则
“坚持保守本身的做为,自由接受他人的做为。
合做的服务依赖于彼此的接口。一般,接口须要提高,致使另外一端接收未指定的数据。若是接收到的数据没有严格遵照规范,那么简单的实现将仅拒绝合做。更复杂的实现却能够忽略它没法识别的数据。
为何
-
为了可以提升服务,你须要确保提供者能够进行更改以支持新的需求,同时对现有客户端形成最小的破坏。
怎么作
-
向其余机器(或同一机器上的其余程序)发送指令或数据的代码应该彻底符合规范,但接受输入的代码应接受不一致的输入,只要其意义明确。
相关资料
-
Robustness Principle in Wikipedia -
Tolerant Reader
控制反转
控制反转又被称为好莱坞原则,“不要打电话给咱们,咱们会打电话给你”。它是一种设计原则,计算机程序的自定义编写部分从通用框架接收控制流。控制反转具备强烈的含义,便可重用代码和特定于问题的代码是独立开发的,即便它们在应用程序中一同工做。
为何
-
控制反转用于提升程序的模块性,使其具备可扩展性。 -
将任务的执行与实现分离。 -
将模块集中在其设计任务上。 -
使模块不受关于其余系统如何执行其任务的假设约束,而是依赖于约定。 -
以防止模块更换时出现反作用。
怎么作
-
使用工厂模式 -
使用服务定位器模式 -
使用依赖注入 -
使用依赖查找 -
使用模板方法模式 -
使用策略模式
相关资料
-
Inversion of Control in Wikipedia -
Inversion of Control Containers and the Dependency Injection pattern
最大化聚合
单个模块/组件的聚合性是其职责造成有意义的单元的程度,越高的聚合性越好。
为何
-
增长了理解模块的难度。 -
增长了维护系统的难度,由于域中逻辑的更改会影响多个模块,而且一个模块的更改须要相关模块的更改。 -
因为大多数应用程序不须要模块提供的随机操做集,所以重用模块的难度增长。
怎么作
-
与组相关的功能共享一项职责(例如在一个类中)。
相关资料
-
Cohesion -
Coupling And Cohesion
里氏代换原则
里氏代换原则(LSP)彻底是关于对象的预期行为:
“程序中的对象应该能够替换为其子类型的实例,而不会改变该程序的正确性。
相关资源
-
Liskov substitution principle -
Liskov Substitution Principle
开放/封闭原则
软件实体(例如类)应对扩展是开放的,但对修改是封闭的。也就是说,这样的实体能够容许在不改变其源代码的状况下修改其行为。
为何
-
经过最小化对现有代码的修改来提升可维护性和稳定性
怎么作
-
编写能够扩展的类(而不是能够修改的类) -
只暴露须要更换的活动部分,隐藏其余全部部分。
相关资源
-
Open Closed Principle -
The Open Closed Principle
单一职责原则
一个类不该该有多个修改的缘由。
长话版:每一个类都应该有一个单独的职责,而且该职责应该彻底由该类封装。职责能够定义为修改的缘由,一次类或模块应该有且仅有一个修改的缘由。
为何
-
可维护性:仅有一个模块或类中须要修改。
怎么作
-
使用 科里定律.
相关资料
-
Single responsibility principle
隐藏实现细节
软件模块经过提供接口来隐藏信息(即实现细节),而不泄露任何没必要要的信息。
为何
-
当实现更改时,客户端使用的接口没必要更改。
怎么作
-
最小化类和成员的可访问性。 -
不要公开成员数据。 -
避免将私有实现细节放入类的接口中。 -
减小耦合以隐藏更多实现细节。
相关资料
-
Information hiding
科里定律
科里定律是关于为任何特定代码选择一个明肯定义的目标:仅作一件事。
-
Curly’s Law: Do One Thing -
The Rule of One or Curly’s Law
封装常常修改的代码
一个好的设计能够辨别出最有可能改变的热点,并将它们封装在API以后。当预期的修改发生时,修改会保持在局部。
为何
-
在发生更改时,最小化所需的修改。
怎么作
-
封装API背后不一样的概念。 -
将可能不一样的概念分到各自的模块。
相关资料
-
Encapsulate the Concept that Varies -
Encapsulate What Varies -
Information Hiding
接口隔离原则
将臃肿的接口减小到多个更小更具体的客户端特定接口中。接口应该比实现它的代码更依赖于调用它的代码。
为何
-
若是类实现了不须要的方法,则调用方须要了解该类的方法实现。例如,若是一个类实现了一个方法,但只是简单的抛出异常,那么调用方将须要知道实际上不该该调用这个方法。
怎么作
-
避免臃肿的接口。类不该该实现任何违反单一职责原则的方法。
相关资料
-
Interface segregation principle
童子军军规
美国童子军有一条简单的军规,咱们可使用到咱们的职业中:“离开营地时比你到达时更干净”。根据童子军军规,咱们应该至终保持代码比咱们看到时更干净。
为何
-
当对现有代码库进行更改时,代码质量每每会下降,从而积累技术债务。根据童子军军规,咱们应该注意每个提交(Commit)的质量。不管规模有多小,技术债务都会受到不断重构的抵制。
怎么作
-
每次提交都要确保它不会下降代码库的质量。 -
任什么时候候,若是有人看到一些代码不够清楚,他们就应该抓住机会在那里修复它。
相关资料
-
Opportunistic Refactoring
命令查询分离
命令查询分离原则规定,每一个方法都应该是执行操做的命令,或者是向调用者返回数据但不能同时作两件事的查询。提问不该该改变答案。
利用这个原则,程序员能够更加自信地进行编码。查询方法能够在任何地方以任何顺序使用,由于它们不会改变状态。而使用命令,你必须更加当心。
为何
-
经过将方法清晰地分为查询和命令,程序员能够在不了解每一个方法的实现细节的状况下,更加自信地编码。
怎么作
-
将每一个方法实现为查询或命令。 -
对方法名使用命名约定,该方法名表示该方法是查询仍是命令。
相关资料
-
Command Query Separation in Wikipedia -
Command Query Separation by Martin Fowler
本文分享自微信公众号 - 肥朝(feichao_java)。
若有侵权,请联系 support@oschina.cn 删除。
本文参与“OSC源创计划”,欢迎正在阅读的你也加入,一块儿分享。