大多数系统如果保持简单而不是复杂,效果最好。
为什么
YAGNI的意思是“你不需要它”:在必要之前不要做多余的事情。
为什么
怎么做
为什么
怎么做
关注点分离是一种将计算机程序分离成不同部分的设计原则,以便每个部分专注于单个关注点。例如,应用程序的业务逻辑是一个关注点而用户界面是另一个关注点。更改用户界面不应要求更改业务逻辑,反之亦然。
引用Edsger W. Dijkstra (1974)所说:
我有时将其称为“关注点分离”,即使这不可能完全做到,但它也是我所知道的唯一有效的思维整理技巧。这就是我所说的“将注意力集中在某个方面”的意思:这并不意味着忽略其他方面,只是对于从某一方面的视角公正地来看,另一方面是不相关的事情。
为什么
怎么做
在一个系统内,每一项认识都必须有一个单一的、明确的、权威的表示。
程序中的每一项重要功能都应该只在源代码中的一个地方实现。相似的函数由不同的代码块执行的情况下,抽象出不同的部分,将它们组合为一个函数通常是有益的。
为什么
怎么做
为什么
怎么做
引用Donald Knuth所说:
程序员浪费大量的时间来思考或担心程序的非关键部分的速度,而考研尝试这些优化实际上在调试和维护时有很强的负面影响。比如说在97%的开发时间,我们应该忽略低效率:过早的优化是万恶之源。然而,我们不应该在关键的3%中放弃我们的机会。
当然,需要理解什么是“过早”什么不是“过早”。
为什么
怎么做
模块/组件之间的耦合是它们互相依赖的程度,较低的耦合更好。换句话说,耦合是代码单元“B”在未知的代码单元“A”更改后“被破坏”的几率。
为什么
怎么做
不要和陌生人说话。
为什么
怎么做
对象的方法只能调用以下方法:
为什么
怎么做
正交性的基本概念是,概念上不相关的东西在系统中不应该相关。
来源:Be Orthogonal
它越简单,设计越正交,异常就越少。这使得用编程语言学习、读写程序变得更容易。正交特征的含义是独立于环境;关键参数是对称性与一致性。
来源:Orthogonality
坚持保守自己的作为,自由接受他人的作为。
合作的服务依赖于彼此的接口。通常,接口需要提升,导致另一端接收未指定的数据。如果接收到的数据没有严格遵守规范,那么简单的实现将仅拒绝合作。更复杂的实现却可以忽略它无法识别的数据。
为什么
怎么做
控制反转又被称为好莱坞原则,“不要打电话给我们,我们会打电话给你”。它是一种设计原则,计算机程序的自定义编写部分从通用框架接收控制流。控制反转具有强烈的含义,即可重用代码和特定于问题的代码是独立开发的,即使它们在应用程序中一同工作。
为什么
怎么做
单个模块/组件的聚合性是其职责形成有意义的单元的程度,越高的聚合性越好。
为什么
怎么做
里氏代换原则(LSP)完全是关于对象的预期行为:
程序中的对象应该可以替换为其子类型的实例,而不会改变该程序的正确性。
软件实体(例如类)应对扩展是开放的,但对修改是封闭的。也就是说,这样的实体可以允许在不改变其源代码的情况下修改其行为。
为什么
怎么做
一个类不应该有多个修改的原因。
长话版:每个类都应该有一个单独的职责,并且该职责应该完全由该类封装。职责可以定义为修改的原因,一次类或模块应该有且仅有一个修改的原因。
为什么
怎么做
软件模块通过提供接口来隐藏信息(即实现细节),而不泄露任何不必要的信息。
为什么
怎么做
科里定律是关于为任何特定代码选择一个明确定义的目标:仅做一件事。
一个好的设计可以辨别出最有可能改变的热点,并将它们封装在API之后。当预期的修改发生时,修改会保持在局部。
为什么
怎么做
将臃肿的接口减少到多个更小更具体的客户端特定接口中。接口应该比实现它的代码更依赖于调用它的代码。
为什么
怎么做
美国童子军有一条简单的军规,我们可以使用到我们的职业中:“离开营地时比你到达时更干净”。根据童子军军规,我们应该至终保持代码比我们看到时更干净。
为什么
怎么做
命令查询分离原则规定,每个方法都应该是执行操作的命令,或者是向调用者返回数据但不能同时做两件事的查询。提问不应该改变答案。
利用这个原则,程序员可以更加自信地进行编码。查询方法可以在任何地方以任何顺序使用,因为它们不会改变状态。而使用命令,你必须更加小心。
为什么
怎么做
原创声明:本文系作者授权腾讯云开发者社区发表,未经许可,不得转载。
如有侵权,请联系 cloudcommunity@tencent.com 删除。
原创声明:本文系作者授权腾讯云开发者社区发表,未经许可,不得转载。
如有侵权,请联系 cloudcommunity@tencent.com 删除。