程序设计原则(总结)

结构化程序设计的主要原则

主要是对像C语言这类结构化的语言，大多采用的就是结构化程序设计。

一、自顶向下

程序设计时，应先考虑整体，后考虑细节；先考虑全局目标，后考虑局部目标。不要一开始就过多追求众多的细节，先从最上层总目标开始设计，逐步使问题具体化。

二、逐步求精

对复杂问题，应设计一些子目标做为过渡，逐步细化。

三、模块化

一个复杂问题，确定是由若干稍简单的问题构成。模块化是把程序要解决的总目标分解为子目标，再进一步分解为具体的小目标，把每个小目标称为一个模块。

四、限制使用goto语句

结构化程序设计方法的起源来自对GOTO语句的认识和争论。确定的结论是：在块和进程的非正常出口处每每须要用GOTO语句，使用GOTO语句会使程序执行效率较高；在合成程序目标时，GOTO语句每每是有用的，如返回语句用GOTO。否认的结论是：GOTO语句是有害的，是形成程序混乱的祸根，程序的质量与GOTO语句的数量呈反比，应该在全部高级程序设计语言中取消GOTO语句。取消GOTO语句后，程序易于理解、易于排错、容易维护，容易进行正确性证实。做为争论的结论，1974年Knuth发表了使人信服的总结，并证明了：

GOTO语句确实有害，应当尽可能避免；彻底避免使用GOTO语句也并不是是个明智的方法，有些地方使用GOTO语句，会使程序流程更清楚、效率更高。
争论的焦点不该放在是否取消GOTO语句上，而应放在用什么样的程序结构上。其中最关键的是，应在以提升程序清晰性为目标的结构化方法中限制使用GOTO语句；

面向对象程序设计的主要原则

一、单一职责原则(Single-Responsibility Principle)　　

就一个类而言，应该只专一于作一件事和仅有一个引发它变化的缘由。所谓职责，咱们能够理解为功能，就是设计的这个类功能应该只有一个，而不是两个或更多。也能够理解为引用变化的缘由，当你发现有两个变化会要求咱们修改这个类，那么你就要考虑撤分这个类了。由于职责是变化的一个轴线，当需求变化时，该变化会反映类的职责的变化。

优势：消除耦合，减少因需求变化引发代码僵化。

二、里氏代换原则(Liskov Substitution Principle)

子类型必须可以替换它们的基类型。一个软件实体若是使用的是一个基类，那么当把这个基类替换成继承该基类的子类，程序的行为不会发生任何变化。软件实体察觉不出基类对象和子类对象的区别。

优势：能够很容易的实现同一父类下各个子类的互换，而客户端能够绝不察觉。

三、依赖倒置原则(Dependence Inversion Principle)

要依赖于抽象，不要依赖于具体，客户端依赖于抽象耦合；抽象不该依赖于细节，细节应依赖于抽象；要针对接口编程，不针对实现编程。

优势：使用传统过程化程序设计所建立的依赖关系，策略依赖于细节，这是糟糕的，由于策略受到细节改变的影响。依赖倒置原则使细节和策略都依赖于抽象，抽象的稳定性决定了系统的稳定性。

怎样作到依赖倒置？

以抽象方式耦合是依赖倒转原则的关键。抽象耦合关系总要涉及具体类从抽象类继承，而且须要保证在任何引用到基类的地方均可以改换成其子类，所以，里氏代换原则是依赖倒转原则的基础。

在抽象层次上的耦合虽然有灵活性，但也带来了额外的复杂性，若是一个具体类发生变化的可能性很是小，那么抽象耦合能发挥的好处便十分有限，这时能够用具体耦合反而会更好。

层次化：全部结构良好的面向对象构架都具备清晰的层次定义，每一个层次经过一个定义良好的、受控的接口向外提供一组内聚的服务。

依赖于抽象：建议不依赖于具体类，即程序中全部的依赖关系都应该终止于抽象类或者接口。尽可能作到：

• 任何变量都不该该持有一个指向具体类的指针或者引用；
• 任何类都不该该从具体类派生；

• 任何方法都不该该覆写它的任何基类中的已经实现的方法；

  四、接口隔离原则(Interface Segregation Principle)

  使用多个专注功能的接口比使用一个的总接口总要好。从一个客户类的角度来说：一个类对另一个类的依赖性应当是创建在最小接口上的。过于臃肿的接口是对接口的污染，不该该强迫客户依赖于它们不用的方法。

优势：会使一个软件系统功能扩展时，修改的压力不会传到别的对象那里。

如何实现接口隔离原则？

利用委托分离接口；利用多继承分离接口；

五、迪米特原则(Law of Demeter)

迪米特法则又叫作最少知识原则(Least Knowledge Principle或简写为LKP)，就是说，一个对象应当对其余对象有尽量少的了解，对象与对象之间应使用尽量少的方法来关联，避免千丝万缕的关系。

在软件系统中，一个模块设计的好很差的最主要、最重要的标志，就是该模块在多大的程度上将本身的内部数据和其余与实现有关的细节隐藏起来。一个设计好的模块能够将它全部的实现细节隐藏起来，完全地将提供给外界的API和本身的实现分割开来。这样一来，模块与模块之间就能够仅仅经过彼此的API相互通讯，而不理会模块内部的工做细节。这一律念就是“信息的隐藏”，或叫作“封装”，也就是你们熟悉的软件设计的基本教义之一。信息的隐藏很是重要的缘由在于，它可使各个子系统之间脱藕，从而容许它们独立地被开发、优化、使用、阅读以及修改。

如何实现迪米特法则？

迪米特法则的主要用意是控制信息的过载，在将其运用到系统设计中应注意如下几点：

• 在类的划分上，应当建立有弱耦合的类，类之间的耦合越弱，就越有利于复用
• 在类的结构设计上，每个类都应当尽可能下降成员的访问权限。一个类不该当public本身的属性，而应当提供取值和赋值的方法让外界间接访问本身的属性。
• 在类的设计上，只要有可能，一个类应当设计成不变类
• 在对其它对象的引用上，一个类对其它对象的引用应该降到最低
• 对于顶级的类来讲，只有两个可能的访问性等级：package-private和public，一个类能够设置成为package-private的，就不该该把它设置成为public的

• 谨慎使用Serializable：若是一个类实现了Serializable接口的话，客户端就能够将这个类串行后再并行化。假如之后这个类一旦修改，客户端势必也将改动。因此能不用就不用

  六、开放－封闭原则(Open-Closed Principle)

对扩展开放，对修改关闭。

优势：按照OCP原则设计出来的系统，下降了程序各部分之间的耦合性，其适应性、灵活性、稳定性都比较好。当已有软件系统须要增长新的功能时，不须要对做为系统基础的抽象层进行修改，只须要在原有基础上附加新的模块就能实现所须要添加的功能。增长的新模块对原有的模块彻底没有影响或影响很小，这样就无须为原有模块进行从新测试。

如何实现“开-闭”原则？

在面向对象设计中，不容许更改的是系统的抽象层，而容许扩展的是系统的实现层。

解决问题关键在于抽象化，抽象化是面向对象设计的第一个核心本质。对一个事物抽象化，即封装了事物的本质，看不到任何细节。
在面向对象编程中，经过抽象类及接口，规定了具体类的特征做为抽象层，相对稳定，不需更改，从而知足“对修改关闭”；而从抽象类导出的具体类能够改变系统的行为，从而知足“对扩展开放”。
对实体进行扩展时，没必要改动软件的源代码或者二进制代码。

优秀程序设计的18大原则

一、避免重复原则(DRY - Don’t repeat yourself)

编程的最基本原则是避免重复。在程序代码中总会有不少结构体，如循环、函数、类等等。一旦你重复某个语句或概念，就很容易造成一个抽象体。

二、抽象原则(Abstraction Principle)

与DRY原则相关。要记住，程序代码中每个重要的功能，只能出如今源代码的一个位置。

三、简单原则(Keep It Simple and Stupid)

简单是软件设计的目标，简单的代码占用时间少，漏洞少，而且易于修改。

四、避免建立你不要的代码(Avoid Creating a YAGNI (You aren’t going to need it))

除非你须要它，不然别建立新功能。

五、尽量作可运行的最简单的事(Do the simplest thing that could possibly work)

尽量作可运行的最简单的事。在编程中，必定要保持简单原则。做为一名程序员不断的反思“如何在工做中作到简化呢?”这将有助于在设计中保持简单的路径。

六、别让我思考(Don’t make me think)

这是Steve Krug一本书的标题，同时也和编程有关。所编写的代码必定要易于读易于理解，这样别人才会欣赏，也可以给你提出合理化的建议。相反，如果繁杂难解的程序，其余人老是会避而远之的。

七、开闭原则(Open/Closed Principle)

你所编写的软件实体(类、模块、函数等)最好是开源的，这样别人能够拓展开发。不过，对于你的代码，得限定别人不得修改。换句话说，别人能够基于你的代码进行拓展编写，但却不能修改你的代码。

八、代码维护(Write Code for the Maintainer)

一个优秀的代码，应当使本人或是他人在未来都可以对它继续编写或维护。代码维护时，或许本人会比较容易，但对他人却比较麻烦。所以你写的代码要尽量保证他人可以容易维护。用书中原话说“若是一个维护者再也不继续维护你的代码，极可能他就有想杀了你的冲动。”

九、最小惊讶原则(Principle of least astonishment)

最小惊讶原则一般是在用户界面方面引用，但一样适用于编写的代码。代码应该尽量减小让读者惊喜。也就是说，你编写的代码只需按照项目的要求来编写。其余华丽的功能就没必要了，以避免弄巧成拙。

十、单一责任原则(Single Responsibility Principle)

某个代码的功能，应该保证只有单一的明确的执行任务。

十一、低耦合原则(Minimize Coupling)

代码的任何一个部分应该减小对其余区域代码的依赖关系。尽可能不要使用共享参数。低耦合每每是完美结构系统和优秀设计的标志。

十二、最大限度凝聚原则(Maximize Cohesion)

类似的功能代码应尽可能放在一个部分。

1三、隐藏实现细节(Hide Implementation Details)

隐藏实现细节原则，当其余功能部分发生变化时，可以尽量下降对其余组件的影响。

1四、迪米特法则又叫做最少知识原则(Law of Demeter)

该代码只和与其有直接关系的部分链接。(好比：该部分继承的类，包含的对象，参数传递的对象等)。

1五、避免过早优化(Avoid Premature Optimization)

除非你的代码运行的比你想像中的要慢，不然别去优化。假如你真的想优化，就必须先想好如何用数据证实，它的速度变快了。

“过早的优化是一切罪恶的根源”——Donald Knuth

1六、代码重用原则(Code Reuse is Good)

重用代码能提升代码的可读性，缩短开发时间。

1七、关注点分离(Separation of Concerns)

不一样领域的功能，应该由不一样的代码和最小重迭的模块组成。

1八、拥抱改变(Embrace Change)

这是Kent Beck一本书的标题，同时也被认为是极限编程和敏捷方法的宗旨。

本文为转载文，转自http://www.cnblogs.com/gaohongchen01/p/4535670.html