程序设计原则（总结）
程序设计原则(总结)
（⼀）结构化程序设计的主要原则
1、⾃顶向下
  程序设计时，应先考虑总体，后考虑细节；先考虑全局⽬标，后考虑局部⽬标。不要⼀开始就过多追求众多的细节，先从最上层总⽬标开始设计，逐步使问题具体化。
2、逐步求精
  对复杂问题，应设计⼀些⼦⽬标作为过渡，逐步细化。
3、模块化
  ⼀个复杂问题，肯定是由若⼲稍简单的问题构成。模块化是把程序要解决的总⽬标分解为⼦⽬标，再进⼀步分解为具体的⼩⽬标，把每⼀个⼩⽬标称为⼀个模块。
4、限制使⽤goto语句
  结构化程序设计⽅法的起源来⾃对GOTO语句的认识和争论。肯定的结论是：在块和进程的⾮正常出⼝处往往需要⽤GOTO语句，使⽤GOTO语句会使程序执⾏效率较⾼；在合成程序⽬标时，GOTO语句往往是有⽤的，如返回语句⽤GOTO。否定的结论是：GOTO语句是有害的，是造成程序混乱的祸根，程序的质量与GOTO语句的数量呈反⽐，应该在所有⾼级程序设计语⾔中取消GOTO语句。取消GOTO语句后，程序易于理解、易于排错、容易维护，容易进⾏正确性证明。作为争论的结论，1974年Knuth发表了令⼈信服的总结，并证实了：
GOTO语句确实有害，应当尽量避免；
完全避免使⽤GOTO语句也并⾮是个明智的⽅法，有些地⽅使⽤GOTO语句，会使程序流程更清楚、效率更⾼。怎样写代码 自己做编程
争论的焦点不应放在是否取消GOTO语句上，⽽应放在⽤什么样的程序结构上。其中最关键的是，应在以提⾼程序清晰性为⽬标的结构化⽅法中限制使⽤GOTO语句；
（⼆）⾯向对象程序设计的主要原则
1、单⼀职责原则(Single-Responsibility Principle) 
  就⼀个类⽽⾔，应该只专注于做⼀件事和仅有⼀个引起它变化的原因。所谓职责，我们可以理解为功
能，就是设计的这个类功能应该只有⼀个，⽽不是两个或更多。也可以理解为引⽤变化的原因，当你发现有两个变化会要求我们修改这个类，那么你就要考虑撤分这个类了。因为职责是变化的⼀个轴线，当需求变化时，该变化会反映类的职责的变化。
  优点：消除耦合，减⼩因需求变化引起代码僵化。
2、⾥⽒代换原则(Liskov Substitution Principle)
  ⼦类型必须能够替换它们的基类型。⼀个软件实体如果使⽤的是⼀个基类，那么当把这个基类替换成继承该基类的⼦类，程序的⾏为不会发⽣任何变化。软件实体察觉不出基类对象和⼦类对象的区别。
  优点：可以很容易的实现同⼀⽗类下各个⼦类的互换，⽽客户端可以毫不察觉。
3、依赖倒置原则(Dependence Inversion Principle)
  要依赖于抽象，不要依赖于具体，客户端依赖于抽象耦合；抽象不应依赖于细节，细节应依赖于抽象；要针对接⼝编程，不针对实现编程。
  优点：使⽤传统过程化程序设计所创建的依赖关系，策略依赖于细节，这是糟糕的，因为策略受到细节改变的影响。依赖倒置原则使细节和策略都依赖于抽象，抽象的稳定性决定了系统的稳定性。
  怎样做到依赖倒置？
以抽象⽅式耦合是依赖倒转原则的关键。抽象耦合关系总要涉及具体类从抽象类继承，并且需要保证在任何引⽤到基类的地⽅都可以改换成其⼦类，因此，⾥⽒代换原则是依赖倒转原则的基础。
便⼗分有限，这时可以⽤具体耦合反⽽会更好。
  层次化：所有结构良好的⾯向对象构架都具有清晰的层次定义，每个层次通过⼀个定义良好的、受控的接⼝向外提供⼀组内聚的服务。
  依赖于抽象：建议不依赖于具体类，即程序中所有的依赖关系都应该终⽌于抽象类或者接⼝。尽量做到：
任何变量都不应该持有⼀个指向具体类的指针或者引⽤；
任何类都不应该从具体类派⽣；
任何⽅法都不应该覆写它的任何基类中的已经实现的⽅法；
4、接⼝隔离原则(Interface Segregation Principle)
  使⽤多个专⼀功能的接⼝⽐使⽤⼀个的总接⼝总要好。从⼀个客户类的⾓度来讲：⼀个类对另外⼀个类的依赖性应当是建⽴在最⼩接⼝上的。过于臃肿的接⼝是对接⼝的污染，不应该强迫客户依赖于它们不⽤的⽅法。
  优点：会使⼀个软件系统功能扩展时，修改的压⼒不会传到别的对象那⾥。
  如何实现接⼝隔离原则？
利⽤委托分离接⼝；
利⽤多继承分离接⼝；
5、迪⽶特原则(Law of Demeter)
  迪⽶特法则⼜叫做最少知识原则(Least Knowledge Principle或简写为LKP)，就是说，⼀个对象应当对其他对象有尽可能少的了解，对象与对象之间应使⽤尽可能少的⽅法来关联，避免千丝万缕的关系。
  在软件系统中，⼀个模块设计的好不好的最主要、最重要的标志，就是该模块在多⼤的程度上将⾃⼰的内部数据和其他与实现有关的细节隐藏起来。⼀个设计好的模块可以将它所有的实现细节隐藏起来，
彻底地将提供给外界的API和⾃⼰的实现分割开来。这样⼀来，模块与模块之间就可以仅仅通过彼此的API相互通信，⽽不理会模块内部的⼯作细节。这⼀概念就是“信息的隐藏”，或叫做“封装”，也就是⼤家熟悉的软件设计的基本教义之⼀。信息的隐藏⾮常重要的原因在于，它可以使各个⼦系统之间脱藕，从⽽允许它们独⽴地被开发、优化、使⽤、阅读以及修改。
  如何实现迪⽶特法则？
  迪⽶特法则的主要⽤意是控制信息的过载，在将其运⽤到系统设计中应注意以下⼏点：
在类的划分上，应当创建有弱耦合的类，类之间的耦合越弱，就越有利于复⽤
在类的结构设计上，每⼀个类都应当尽量降低成员的访问权限。⼀个类不应当public⾃⼰的属性，⽽应当提供取值和赋值的⽅法让外界间接访问⾃⼰的属性。
在类的设计上，只要有可能，⼀个类应当设计成不变类
在对其它对象的引⽤上，⼀个类对其它对象的引⽤应该降到最低
对于顶级的类来说，只有两个可能的访问性等级：package-private和public，⼀个类可以设置成为package-private的，就不应该把它设置成为public的
谨慎使⽤Serializable：如果⼀个类实现了Serializable接⼝的话，客户端就可以将这个类串⾏后再并⾏化。假如以后这个类⼀旦修改，客户端势必也将改动。所以能不⽤就不⽤
6、开放－封闭原则(Open-Closed Principle)
  对扩展开放，对修改关闭。
  优点：按照OCP原则设计出来的系统，降低了程序各部分之间的耦合性，其适应性、灵活性、稳定性都⽐较好。当已有软件系统需要增加新的功能时，不需要对作为系统基础的抽象层进⾏修改，只需要在原有基础上附加新的模块就能实现所需要添加的功能。增加的新模块对原有的模块完全没有影响或影响很⼩，这样就⽆须为原有模块进⾏重新测试。
  如何实现“开-闭”原则？
在⾯向对象设计中，不允许更改的是系统的抽象层，⽽允许扩展的是系统的实现层。
在⾯向对象编程中，通过抽象类及接⼝，规定了具体类的特征作为抽象层，相对稳定，不需更改，从⽽满⾜“对修改关闭”；⽽从抽象类导出的具体类可以改变系统的⾏为，从⽽满⾜“对扩展开放”。
对实体进⾏扩展时，不必改动软件的源代码或者⼆进制代码。
（三）优秀程序设计的18⼤原则
1、避免重复原则(DRY - Don’t repeat yourself)
  编程的最基本原则是避免重复。在程序代码中总会有很多结构体，如循环、函数、类等等。⼀旦你重复某个语句或概念，就很容易形成⼀个抽象体。
2、抽象原则(Abstraction Principle)
  与DRY原则相关。要记住，程序代码中每⼀个重要的功能，只能出现在源代码的⼀个位置。
3、简单原则(Keep It Simple and Stupid)
  简单是软件设计的⽬标，简单的代码占⽤时间少，漏洞少，并且易于修改。
4、避免创建你不要的代码(Avoid Creating a YAGNI (You aren’t going to need it))
  除⾮你需要它，否则别创建新功能。
5、尽可能做可运⾏的最简单的事(Do the simplest thing that could possibly work)
  尽可能做可运⾏的最简单的事。在编程中，⼀定要保持简单原则。作为⼀名程序员不断的反思“如何在⼯作中做到简化呢?”这将有助于在设计中保持简单的路径。
6、别让我思考(Don’t make me think)
  这是Steve Krug⼀本书的标题，同时也和编程有关。所编写的代码⼀定要易于读易于理解，这样别⼈才会欣赏，也能够给你提出合理化的建议。相反，若是繁杂难解的程序，其他⼈总是会避⽽远之的。
7、开闭原则(Open/Closed Principle)
  你所编写的软件实体(类、模块、函数等)最好是开源的，这样别⼈可以拓展开发。不过，对于你的代码，得限定别⼈不得修改。换句话说，别⼈可以基于你的代码进⾏拓展编写，但却不能修改你的代码。
8、代码维护(Write Code for the Maintainer)
  ⼀个优秀的代码，应当使本⼈或是他⼈在将来都能够对它继续编写或维护。代码维护时，或许本⼈会⽐较容易，但对他⼈却⽐较⿇烦。因此你写的代码要尽可能保证他⼈能够容易维护。⽤书中原话说“如果⼀个维护者不再继续维护你的代码，很可能他就有想杀了你的冲动。”
9、最⼩惊讶原则(Principle of least astonishment)
  最⼩惊讶原则通常是在⽤户界⾯⽅⾯引⽤，但同样适⽤于编写的代码。代码应该尽可能减少让读者惊喜。也就是说，你编写的代码只需按照项⽬的要求来编写。其他华丽的功能就不必了，以免弄巧成拙。
10、单⼀责任原则(Single Responsibility Principle)
  某个代码的功能，应该保证只有单⼀的明确的执⾏任务。
11、低耦合原则(Minimize Coupling)
  代码的任何⼀个部分应该减少对其他区域代码的依赖关系。尽量不要使⽤共享参数。低耦合往往是完美结构系统和优秀设计的标志。
12、最⼤限度凝聚原则(Maximize Cohesion)
  相似的功能代码应尽量放在⼀个部分。
13、隐藏实现细节(Hide Implementation Details)
  隐藏实现细节原则，当其他功能部分发⽣变化时，能够尽可能降低对其他组件的影响。
14、迪⽶特法则⼜叫作最少知识原则(Law of Demeter)
  该代码只和与其有直接关系的部分连接。(⽐如：该部分继承的类，包含的对象，参数传递的对象等)。
15、避免过早优化(Avoid Premature Optimization)
  除⾮你的代码运⾏的⽐你想像中的要慢，否则别去优化。假如你真的想优化，就必须先想好如何⽤数据证明，它的速度变快了。  “过早的优化是⼀切罪恶的根源”——Donald Knuth
16、代码重⽤原则(Code Reuse is Good)
  重⽤代码能提⾼代码的可读性，缩短开发时间。
17、关注点分离(Separation of Concerns)
  不同领域的功能，应该由不同的代码和最⼩重迭的模块组成。
18、拥抱改变(Embrace Change)
  这是Kent Beck⼀本书的标题，同时也被认为是极限编程和敏捷⽅法的宗旨。
学习前⼈经验，点滴记录。 Bruce Liu 2021-4-9
参考链接：

版权声明：本站内容均来自互联网，仅供演示用，请勿用于商业和其他非法用途。如果侵犯了您的权益请与我们联系QQ:729038198，我们将在24小时内删除。