良好的编E原则与良好的设计工E原则密切相兟뀂本文ȝ的这些设计原则,帮助开发者更有效率的~写代码Qƈ帮助成ؓ(f)一名优U的程序员?/p>
1.避免重复原则QDRY – Don’t repeat yourselfQ?/strong>
~程的最基本原则是避免重复。在E序代码中M(x)有很多结构体Q如循环、函数、类{等。一旦你重复某个语句或概念,׃(x)很容易Ş成一个抽象体?/p>
2.抽象原则QAbstraction Principle Q?/strong>
与DRY原则相关。要CQ程序代码中每一个重要的功能Q只能出现在源代码的一个位|?/p>
3.单原则(Keep It Simple and Stupid Q?/strong>
单是软g设计的目标,单的代码占用旉,漏洞,q且易于修改?/p>
4.避免创徏你不要的代码 Avoid Creating a YAGNI (You aren’t going to need it)
除非你需要它Q否则别创徏新功能?/p>
5.可能做可运行的最单的事(Do the simplest thing that could possibly workQ?/strong>
可能做可运行的最单的事。在~程中,一定要保持单原则。作Z名程序员?sh)断的反?#8220;如何在工作中做到化呢Q?#8221;q将有助于在设计中保持简单的路径?/p>
6.别让我思?Don’t make me think )
q是Steve Krug一本书的标题,同时也和~程有关。所~写的代码一定要易于L于理解,q样别h才会(x)ƣ赏Q也能够l你提出合理化的。相反,若是J杂难解的程序,其他人L?x)避而远之的?/p>
7.开闭原?Open/Closed Principle)
你所~写的Y件实体(cR模块、函数等Q最好是开源的Q这样别人可以拓展开发。不q,对于你的代码Q得限定别h不得修改。换句话_(d)别h可以Z你的代码q行拓展~写Q但却不能修改你的代码?/p>
8.代码l护(Write Code for the Maintainer)
一个优U的代码,应当使本人或是他人在来都能够对它l编写或l护。代码维护时Q或许本Z(x)比较Ҏ(gu)Q但对他人却比较ȝ(ch)。因此你写的代码要尽可能保证他h能够Ҏ(gu)l护。用书中原话?#8220;如果一个维护者不再l维护你的代码,很可能他有x(chng)?jin)你的冲动?#8221;
9.最惊讶原?Principle of least astonishment)
最惊讶原则通常是在用户界面斚w引用Q但同样适用于编写的代码。代码应该尽可能减少让读者惊喜。也是_(d)你编写的代码只需按照目的要求来~写。其他华丽的功能׃必了(jin)Q以免弄巧成拙?/p>
10.单一责Q原则(Single Responsibility Principle)
某个代码的功能,应该保证只有单一的明的执行d?/p>
11.低耦合原则(Minimize Coupling)
代码的Q何一个部分应该减对其他区域代码的依赖关pR尽量不要用共享参数。低耦合往往是完结构系l和优秀设计的标志?/p>
12.最大限度凝聚原?Maximize Cohesion)
怼的功能代码应量攑֜一个部分?/p>
13.隐藏实现l节QHide Implementation DetailsQ?/strong>
隐藏实现l节原则Q当其他功能部分发生变化Ӟ能够可能降低对其他lg的媄(jing)响?/p>
14.q米Ҏ(gu)则又叫作最知识原?Law of Demeter)
该代码只和与其有直接关系的部分连接。(比如Q该部分l承的类Q包含的对象Q参C递的对象{)(j)?/p>
15.避免q早优化(Avoid Premature Optimization)
除非你的代码q行的比你想像中的要慢,否则别去优化。假如你真的想优化,必d惛_如何用数据证明,它的速度变快?jin)?/p>
“q早的优化是一切罪恶的Ҏ(gu)”——Donald Knuth
16.代码重用原则QCode Reuse is GoodQ?nbsp;
重用代码能提高(sh)码的可读性,~短开发时间?/p>
17.x(chng)点分(Separation of ConcernsQ?/strong>
不同领域的功能,应该׃同的代码和最重q的模块l成?/p>
18.拥抱改变QEmbrace ChangeQ?/strong>
q是Kent Beck一本书的标题,同时也被认ؓ(f)是极限编E和敏捷Ҏ(gu)的宗旨?/p>
许多其他原则都是Zq个概念的,即你应该U极面对变化。事实上Q一些较老的~程原则如最化耦合原则都是Z(jin)使代码能够容易变化。无Z是否是个极限~程者,Zq个原则ȝ写代码会(x)让你的工作变得更有意义?/p>
作者简?/strong>QChristopher Diggins是加拿大一位有25q编E经验的资深技术h员,曾效力于Microsoft和AutoDeskQƈ创办q两家赢利的互联|公司?/p> 他是《C++ Cookbook》的作者之一Qƈ自己~写?jin)一门编E语aHeron?br />
]]>
Singleton Pattern(单例模式)
改善全局变量和命名空间的冲突Q可以说是一U改良了(jin)的全局变量。这U一个类只有一个实例,且提供一个访问全局点的方式Q更加灵zȝ保证?jin)实例的创徏和访问约束?br /> 有时候在使用cȝ时候,q个cdd在,但是我们又要求这个类在整个工E中只能有一个对象,无论什么时候调用都只能调用q唯一的一个对象,怎么做呢Q?br /> q种模式的核?j)跟javaBean有点cMQ不同在于单例模式要求创建ƈU有化一个对象,同时U有化构造方法,重写构造方法其返回这个对象。ؓ(f)?jin)能够用这个对象,我们在其中创Z个静(rn)态的GetҎ(gu)用来q回该对象?br />
一般的我们?x)用两种单例模式的方法,一个是延迟加蝲Q又叫懒汉式Q另一个是非gq加载,又称饿汗式。区别在于前者是在调用的时候才生成对象Q而后者则是事先生成对象;Ҏ(gu)区别在于是否把生成对象放入getҎ(gu)Q可以加入判断如果该对象不存在就new一个,存在的话p回该已存在的对象Q?br /> q种思想在很多地斚w?x)用,用同L(fng)思想我们可以解决更多的问题?br />
23U模式想?jin)解更多的话可以去谷歌看看。我们重点不是掌握几U方法,而是Nq种思想Q灵zM用这U方法。高内聚Q低耦合Q在写程序之前就要对整个q程?jin)解很透彻Q而不是边写边想究竟该怎么布局?br />