程序设计七大原则
程序设计总结
程序设计总结程序设计总结程序设计是一门综合性强、需要具备逻辑思维和创造力的学科。
在日常的工作和学习中，我们经常要进行程序设计，因此对程序设计进行总结是非常重要的。
本文将从以下几个方面对程序设计进行总结。
1. 程序设计的基本原则程序设计的基本原则可以概括为以下几点：1.1 单一职责原则（SRP）单一职责原则要求一个类或模块应该有且只有一个引起它修改的原因。
这样可以提高代码的聚焦性和可维护性。
1.2 开放闭合原则（OCP）开放闭合原则要求软件中的对象（类、模块、函数等）对扩展是开放的，对修改是闭合的。
通过使用抽象和接口，我们可以方便地扩展系统的功能而不必修改已有的代码。
1.3 里氏替换原则（LSP）里氏替换原则要求所有引用基类的地方必须能够透明地使用其子类的对象，而不会引发任何异常或错误。
这样可以确保系统在扩展时不会破坏原有的功能。
1.4 依赖倒置原则（DIP）依赖倒置原则要求高层模块不应该依赖低层模块，它们应该依赖于抽象。
通过使用接口和依赖注入，我们可以降低模块之间的耦合，提高系统的灵活性和可测试性。
2. 程序设计的步骤程序设计通常包括以下几个步骤：2.1 分析需求在进行程序设计之前，我们需要清楚地了解用户的需求和系统的功能。
这包括对用户需求的分析、功能的拆解等。
2.2 设计程序框架根据需求分析的结果，我们可以设计出程序的整体框架。
这包括确定系统的模块划分、类的设计、接口的定义等。
2.3 编写代码在设计程序框架之后，我们可以开始编写具体的代码。
这包括实现系统的各个模块和类，编写函数、方法等。
2.4 测试和调试在编写代码之后，我们需要对代码进行测试和调试。
这包括单元测试、集成测试、系统测试等。
2.5 优化和维护在程序运行一段时间后，我们可能需要对程序进行优化和维护。
这包括提高程序的性能、修复bug、添加新功能等。
3. 程序设计的技巧和实践在程序设计中，我们需要掌握一些技巧和实践，以提高开发效率和代码质量。
软件设计7大原则
软件设计7大原则
在软件设计领域，有7个基本原则被认为是设计高质量、易于维护的软件的关键。
这些原则被称为SOLID原则，包括以下七个原则：
1. 单一职责原则(SRP)：每个类或对象都应该专注于单一的职责，而不是尝试做太多的事情。
这样可以使代码更易于维护，因为更改其中一个职责不会影响其他职责。
2. 开放封闭原则(OCP)：软件实体（类、模块等）应该是开放可扩展的，而不是修改已有的代码。
这意味着在修改系统行为时，应该通过添加新代码而不是修改现有代码来实现。
3. 里氏替换原则(LSP)：子类应该能够替换它们的基类并保持行为不变。
这意味着子类应该与其基类遵循相同的契约，以确保子类可以无缝地替换基类。
4. 接口隔离原则(ISP)：客户端不应该依赖于它们不需要的接口。
这可以通过将接口分解成更小的和更具体的接口来实现，以确保每个客户端只依赖于其需要的接口。
5. 依赖倒置原则(DIP)：高层模块不应该依赖于低层模块，两者都应该依赖于抽象。
这可以通过使用依赖注入、依赖反转和工厂模式等技术来实现。
6. 迪米特法则(LoD)：一个对象应该与其他对象之间保持最少的交互。
这可以通过使用中介者模式等来实现。
7. 单元测试原则：每个类都应该有单元测试来确保其行为正确且符合预期。
这些原则可以帮助开发人员编写可扩展、易于维护和可重用的软件。
在实践中，应该尽可能遵循这些原则，但也应该根据特定的情况进行适当地调整。
设计程序时应遵循的基本原则
1、设计程序时应遵循的基本原则：此原则是由“Bertrand Meyer”原文是：“Software entities should be open for extension, but closed for modification”.就是说模块应对扩展开放，而对修改关闭。
模块应尽量在不修改原（是”原“，指原来的代码）代码的情况下进行扩展。
OO设计根本的指导原则是提高可维护性和可复用性。
这些原则主要有：1. 开闭原则2. 依赖倒转原则3. 里氏代换原则4. 合成/聚合复用原则5. 迪米特原则5.6. 接口隔离原则2、数据结构：数据结构是计算机存储、组织数据的方式。
数据结构是指相互之间存在一种或多种特定关系的数据元素的集合。
通常情况下，精心选择的数据结构可以带来更高的运行或者存储效率。
数据结构往往同高效的检索算法和索引技术有关。
数据结构在计算机科学界至今没有标准的定义。
个人根据各自的理解的不同而有不同的表述方法：Sartaj Sahni 在他的《数据结构、算法与应用》一书中称：“数据结构是数据对象，以及存在于该对象的实例和组成实例的数据元素之间的各种联系。
这些联系可以通过定义相关的函数来给出。
”他将数据对象（data object）定义为“一个数据对象是实例或值的集合”。
Clifford A.Shaffer 在《数据结构与算法分析》一书中的定义是：“数据结构是 ADT （抽象数据类型 Abstract Data Type）的物理实现。
”Lobert L.Kruse 在《数据结构与程序设计》一书中，将一个数据结构的设计过程分成抽象层、数据结构层和实现层。
其中，抽象层是指抽象数据类型层，它讨论数据的逻辑结构及其运算，数据结构层和实现层讨论一个数据结构的表示和在计算机内的存储细节以及运算的实现。
3、算法的概念：4、计算机语言的分类和特点主要是从其抽象程度这个方面来考虑：没有抽象：机器语言第一层抽象，只是简单地把机器指令用符号来表示：汇编语言第二层抽象：面向过程的高级语言。
面向对象程序设计的七大原则
面向对象程序设计的七大原则是软件开发中的基本原则，也被称为“SOLID原则”。
这七个原则是由Robert C. Martin所提出的，是为了确保软件系统具有可扩展性、可维护性、可重用性和可测试性等优良的质量属性。
一、单一职责原则(SRP)单一职责原则指的是一个类应该有且只有一个引起它变化的原因。
换言之，一个类只承担一种职责或功能。
如果一个类具有多个职责，那么当其中一个职责变化时，可能影响其他职责的正确性和稳定性，从而导致软件系统出现难以预测的错误。
二、开放封闭原则(OCP)开放封闭原则指的是软件实体（类、模块等）应该是可扩展的，但不可修改的。
这意味着应该允许修改软件实体的行为，但不允许直接修改其源代码。
相反，应该通过添加新代码来扩展其功能。
通过遵循该原则，可以使软件系统更加稳定和易于维护。
三、里氏替换原则(LSP)里氏替换原则指的是，任何基类可以被替换为其子类，而不会影响软件系统的正确性。
换言之，一个子类应该能够替换掉其父类，同时保持其原有的行为和功能。
遵循该原则可以提高软件系统的灵活性和可扩展性。
四、接口隔离原则(ISP)接口隔离原则指的是，不应该限制一个类必须实现其不需要的接口。
接口应该是精简的，只包含其实现类所需要的方法和属性。
这样可以避免代码冗余和不必要的复杂性，从而提高代码的可读性和可维护性。
五、依赖倒置原则(DIP)依赖倒置原则指的是高层模块不应该依赖于低层模块，它们应该依赖于抽象接口。
同时，抽象接口也不应该依赖于具体实现类。
换言之，应该依赖于抽象而不是具体实现。
遵循该原则可以提高代码的灵活性和可重用性。
六、迪米特法则(Law of Demeter)迪米特法则，也被称为最少知识原则(LSP)，其指导思想是一个对象应该尽量不去了解其它对象的内部实现细节。
这意味着一个对象只能与其直接联系的对象发生交互。
这样可以降低对象之间的耦合度，提高代码的可维护性和可测试性。
七、组合/聚合复用原则(CARP)组合/聚合复用原则是建立在利用继承和实现来实现代码重用的六大原则之外的一种方式。
js的七大原则--单一原则、开闭原则、替换原则（一）
js的七⼤原则--单⼀原则、开闭原则、替换原则（⼀）⼀.前⾔：js 的七⼤设计原则：1.单⼀原则2.开闭原则3.⾥⽒替换原则4.依赖倒转原则5.接⼝隔离原则6.合成复⽤原则7.迪⽶尔法则⼆.单⼀原则1.定义：单⼀原则就是⼀个对象或者⼀个⽅法，只做⼀件事。
⽐如，⽬前公司的前端框架，如下图：在src中api只是做接⼝层，assets⾥⾯是公共的⽅法，components是⽤来放组件的,⾥⾯的base和business分别存放的是基础组件和业务组件，mixins是⽤来存放混⼊的东西的。
store⽂件时⽤来放vuex中的东西的，style⽂件是⽤来存放样式的。
每个⽂件都有各⾃的职责，也都只负责⼀件事情。
这就符合单⼀职责的。
遵循单⼀职责的优点：1.可以降低类的复杂度，⼀个类只负责⼀项职责，其逻辑肯定要⽐负责多项职责简单的多。
2.提⾼类的可读性，提⾼系统的可维护性。
3.变更引起的风险降低，变更时必然的，如果单⼀职责原则遵守的好，当修改⼀个功能时，可以显著降低对其他功能的影响。
三.开闭原则尽量通过扩展软件实体来解决需求变化，⽽不是通过修改已有的代码来完成变化。
⼀个软件产品的⽣命周期内，都会发⽣变化，既然变化是⼀个既定的事实，我们就应该在设计的时候，尽量的适应这些变化。
以提⾼项⽬的稳定性和灵活性。
四.⾥⽒替换原则严格的定义：如果对每⼀个类型为T1的对象o1,都有类型为T2的对象o2,使得以T1定义的所有程序p在所有的对象o1都换成o2的时候，程序p的⾏为没有变化，那么类型T2就是类型T1的⼦类型。
通俗的定义：所有引⽤基类的地⽅必须能透明地使⽤其⼦类的功能。
更通俗的定义：⼦类可以扩展⽗类的功能，但是不能改变⽗类原有的功能。
⾸先来看⼀个例⼦，看它是否满⾜“⾥⽒替换”的原则//定义⼀个矩形类class Rectangle {constructor() {this.width=0;this.height=0;}setWidth(width) {this.width = width}setHeight(height) {this.height = height}getArea() {return this.width * this.height}}//定义⼀个正⽅形类，继承于矩形类class Square extends Rectangle {constructor() {super();}setWidth(width) {this.width = width;this.height = width;}setHeight(height) {this.height = heightthis.width = height}}// 执⾏的⽅法function result(rectangles) {rectangles.forEach((rectangle) => {rectangle.setHeight(5)rectangle.setWidth(4)let area = rectangle.getArea()console.log('area', area)})}let rectangles = [new Rectangle(), new Rectangle(), new Square()];result(rectangles) //结果是20 ，20， 16在我当初看到这个代码的时候，我的疑惑点在于为什么正⽅形求⾯积是16。
代码规范七大原则
代码规范七大原则代码规范是在编写代码过程中遵循的一系列准则，旨在提高代码的可读性、可维护性和可扩展性。
在实践中，代码规范可以有很多不同的实现方式，但是大致都会包含以下七个主要原则。
1. 一致性（Consistency）：一致性是代码规范中最重要的原则之一、在代码中使用统一的命名规则、缩进风格、代码结构等，可以使代码更易于阅读和理解。
同时，一致性还可以减少不同团队成员之间可能产生的代码差异，降低协作过程中发生冲突的概率。
2. 可读性（Readability）：可读性是代码规范的核心要求之一，因为可读性直接关系到其他人能否理解和修改你的代码。
为了提高可读性，代码应该遵循一些通用的规则，如使用有意义的命名、提供必要的注释、避免过长的函数和类等。
此外，代码布局的清晰和良好的缩进等也是提高可读性的有效手段。
3. 简洁性（Simplicity）：简洁性是代码规范的另一个重要原则，旨在通过避免过度复杂的结构、逻辑和语法，使代码更清晰、易于理解和维护。
简洁的代码通常具有更好的可读性和可维护性，同时也更易于测试和调试。
编写简洁代码的关键在于选择恰当的算法和数据结构，并避免重复代码和冗余逻辑。
4. 可维护性（Maintainability）：可维护性是指通过清晰的代码结构和模块化的设计，使代码容易被理解、修改和扩展。
为了提高可维护性，应该尽量避免使用过多的全局变量和复杂的控制流程，尽量将代码拆分成小的、独立的模块，方便修改和测试。
此外，合理的注释和文档也是提高代码的可维护性的重要手段。
5. 可扩展性（Scalability）：可扩展性是指代码可以在不改变原有功能的情况下，方便地添加新的功能或适应更大规模的问题。
为了提高代码的可扩展性，应该遵循面向对象编程的原则，如封装、继承和多态。
此外，模块化的设计也是提高可扩展性的有效方法，将功能相似的代码封装成独立的模块，可以方便地替换、添加和删除。
6. 可测试性（Testability）：可测试性是指代码能够方便地被自动化测试工具进行单元测试和集成测试。
举例说明软件设计7原则
举例说明软件设计7原则1. 单一职责原则（Single Responsibility Principle，SRP）一个类或模块应该只有一个改变的原因。
即，一个类或模块应该只有一个责任。
举例：一个数据处理类，它的职责是读取数据、处理数据并将结果返回。
如果将文件读取和数据处理的责任放在同一个类中，这违反了单一职责原则。
应该将文件读取和数据处理分别封装到两个单独的类中。
2. 开放封闭原则（Open-Closed Principle，OCP）软件实体（类，模块，函数等）应该对扩展开放，对修改封闭。
举例：一段代码用于计算员工的薪水，其中有一个计算基础薪水的函数。
如果需要增加一个新的员工类型，只需要创建一个新的类来实现员工的新薪水计算逻辑，而不需要修改原有的计算基础薪水的函数。
3. 里氏替换原则（Liskov Substitution Principle，LSP）子类型必须能够替换其基类型。
即，如果一个类B是类A的子类，那么在任何使用类A的地方都可以用类B来替换。
举例：有一个基类Animal，派生出子类Cat和Dog。
在一个方法中，如果传入一个Animal对象作为参数，应该能够接受任何Animal的子类对象作为参数。
4. 依赖倒置原则（Dependency Inversion Principle，DIP）高层模块不应该依赖于低层模块，二者都应该依赖于抽象。
抽象不应该依赖于细节，细节应该依赖于抽象。
举例：有一个Logger类用于记录日志，该类应该依赖于一个抽象的日志接口，而不应该直接依赖于具体的文件日志类。
这样，在需要更换日志实现方式时，只需要创建一个新的实现了日志接口的类，无需修改Logger类。
5. 接口隔离原则（Interface Segregation Principle，ISP）客户端不应该依赖于它不需要的接口。
一个类不应该强迫其客户端依赖于它们不需要的方法。
举例：有一个图形类，它有用于绘制线条、绘制矩形、绘制圆形的方法。
代码规范化的七大原则
代码规范化的七大原则
1.一致性
代码一致性是指在整个项目中，使用相同的命名规约、风格和格式来编写代码。
这样可以让团队成员之间更容易理解和维护代码，提高代码的可读性。
2.简洁性
代码应该尽量简洁，不包含冗余代码和多余的注释。
简洁的代码更易于理解和修改，并且可以提高代码执行效率。
3.可读性
代码应该具有良好的可读性，即使是其他人也能轻松理解代码的意图和功能。
为了提高代码的可读性，可以使用有意义的命名、合理的缩进和注释，并避免使用过于复杂的逻辑和嵌套结构。
4.模块化
代码应该按照功能和责任进行模块化，将不同的功能拆分为独立的模块。
这样可以提高代码的可维护性和可复用性，并减少代码的重复。
5.错误处理
代码应该具备良好的错误处理机制，能够捕获和处理异常情况，避免程序崩溃或产生不可预期的结果。
错误处理可以通过异常处理机制、错误码返回和日志记录等方式实现。
6.安全性
在编写代码时，应该考虑到安全性问题，避免一些常见的安全漏洞和攻击方式。
例如，输入验证、密码加密、访问控制和数据保护等。
7.可测试性
代码应该具备良好的可测试性，能够方便地进行单元测试、集成测试和性能测试等。
为了提高代码的可测试性，可以使用依赖注入、单一职责原则和解耦等设计原则。
总结起来，代码规范化的七大原则是一致性、简洁性、可读性、模块化、错误处理、安全性和可测试性。
遵循这些原则可以提高代码的质量和可维护性，进而提高软件开发效率和用户满意度。
- 1、下载文档前请自行甄别文档内容的完整性，平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益，请联系客服反馈,我们会尽快为您处理(人工客服工作时间：9:00-18:30)。
软件设计的七大原则
设计模式遵循的一般原则：
1.开-闭原则(Open-Closed Principle, OCP):一个软件实体应当对扩展开发,对修改关闭.说的是,再设计一个模块的时候,应当使这个模块可以在不被修改的前提下被扩展.换言之,应当可以在不必修改源代码的情况下改变这个模块的行为，在保持系统一定稳定性的基础上，对系统进行扩展。
这是面向对象设计（OOD）的基石，也是最重要的原则。
2.里氏代换原则(Liskov Substitution Principle,常缩写为.LSP)
(1).由Barbar Liskov(芭芭拉.里氏)提出，是继承复用的基石。
(2).严格表达:如果每一个类型为T1的对象o1,都有类型为T2的对象o2,使得以T1定义的所有程序P在所有的对象o1都代换称o2时,程序P的行为没有变化,那么类型T2是类型T1的子类型.
换言之,一个软件实体如果使用的是一个基类的话,那么一定适用于其子类,而且它根本不能察觉出基类对象和子类对象的区别.只有衍生类可以替换基类，软件单位的功能才能不受影响，基类才能真正被复用，而衍生类也能够在基类的基础上增加新功能。
(3).反过来的代换不成立
(4).<墨子.小取>中说:"白马,马也; 乘白马,乘马也.骊马(黑马),马也;乘骊马,乘马也."
(5).该类西方著名的例程为:正方形是否是长方形的子类(答案是"否")。
类似的还有椭圆和圆的关系。
(6).应当尽量从抽象类继承,而不从具体类继承,一般而言,如果有两个具体类A,B有继承关系,那么一个最简单的修改方案是建立一个抽象类C,然后让类A和B 成为抽象类C的子类.即如果有一个由继承关系形成的登记结构的话,那么在等级结构的树形图上面所有的树叶节点都应当是具体类;而所有的树枝节点都应当是抽象类或者接口.
(7)."基于契约设计(Design By Constract),简称DBC"这项技术对LISKOV代换原则提供了支持.该项技术Bertrand Meyer伯特兰做过详细的介绍:
使用DBC,类的编写者显式地规定针对该类的契约.客户代码的编写者可以通过该契约获悉可以依赖的行为方式.契约是通过每个方法声明的前置条件(preconditions)和后置条件(postconditions)来指定的.要使一个方法得以执行,前置条件必须为真.执行完毕后,该方法要保证后置条件为真.就是说,在重新声明派生类中的例程(routine)时,只能使用相等或者更弱的
前置条件来替换原始的前置条件,只能使用相等或者更强的后置条件来替换原始的后置条件.
3.依赖倒置原则(Dependence Inversion Principle),要求客户端依赖于抽象耦合.
(1)表述:抽象不应当依赖于细节,细节应当依赖于抽象.(Program to an interface, not an implementaction)
(2)表述二:针对接口编程的意思是说,应当使用接口和抽象类进行变量的类型声明,参量的类型声明,方法的返还类型声明,以及数据类型的转换等.不要针对实现编程的意思就是说,不应当使用具体类进行变量的类型声明,参量类型声明,方法的返还类型声明,以及数据类型的转换等.
要保证做到这一点,一个具体的类应等只实现接口和抽象类中声明过的方法,而不应当给出多余的方法.
只要一个被引用的对象存在抽象类型,就应当在任何引用此对象的地方使用抽象类型,包括参量的类型声明,方法返还类型的声明,属性变量的类型声明等. (3)接口与抽象的区别就在于抽象类可以提供某些方法的部分实现,而接口则不可以,这也大概是抽象类唯一的优点.如果向一个抽象类加入一个新的具体方法,
那么所有的子类型一下子就都得到得到了这个新的具体方法,而接口做不到这一点.如果向一个接口加入了一个新的方法的话,所有实现这个接口的类就全部不能通过编译了,因为它们都没有实现这个新声明的方法.这显然是接口的一个缺点.
(4)一个抽象类的实现只能由这个抽象类的子类给出,也就是说,这个实现处在抽象类所定义出的继承的登记结构中,而由于一般语言都限制一个类只能从最多一个超类继承,因此将抽象作为类型定义工具的效能大打折扣.
反过来,看接口,就会发现任何一个实现了一个接口所规定的方法的类都可以具有这个接口的类型,而一个类可以实现任意多个接口.
(5)从代码重构的角度上讲,将一个单独的具体类重构成一个接口的实现是很容易的,只需要声明一个接口,并将重要的方法添加到接口声明中,然后在具体类定义语句中加上保留字以继承于该接口就行了.
而作为一个已有的具体类添加一个抽象类作为抽象类型不那么容易,因为这个具体类有可能已经有一个超类.这样一来,这个新定义的抽象类只好继续向上移动,变成这个超类的超类,如此循环,最后这个新的抽象类必定处于整个类型等级结构的最上端,从而使登
记结构中的所有成员都会受到影响.
(6)接口是定义混合类型的理想工具,所为混合类型,就是在一个类的主类型之外的次要类型.一个混合类型表明一个类不仅仅具有某个主类型的行为,而且具有其他的次要行为.
(7)联合使用接口和抽象类:
由于抽象类具有提供缺省实现的优点,而接口具有其他所有优点,所以联合使用两者就是一个很好的选择.
首先,声明类型的工作仍然接口承担的,但是同时给出的还有一个抽象类,为这个接口给出一个缺省实现.其他同属于这个抽象类型的具体类可以选择实现这个接口,也可以选择继承自这个抽象类.如果一个具体类直接实现这个接口的话,它就必须自行实现所有的接口;相反,如果它继承自抽象类的话,它可以省去一些不必要的的方法,因为它可以从抽象类中自动得到这些方法的缺省实现;如果需要向接口加入一个新的方法的话,那么只要同时向这个抽象类加入这个方法的一个具体实现就可以了,因为所有继承自这个抽象类的子类都会从这个抽象类得到这个具体方法.这其实就是缺省适配器模式(Defaule Adapter).
(8)什么是高层策略呢?它是应用背后的抽象,是那些不
随具体细节的改变而改变的真理. 它是系统内部的系统____隐喻.
4.接口隔离原则(Interface Segregation Principle, ISP) （1）一个类对另外一个类的依赖是建立在最小的接口上。
（2）使用多个专门的接口比使用单一的总接口要好.根据客户需要的不同,而为不同的客户端提供不同的服务是一种应当得到鼓励的做法.就像"看人下菜碟"一样,要看客人是谁,再提供不同档次的饭菜.
（3）胖接口会导致他们的客户程序之间产生不正常的并且有害的耦合关系.当一个客户程序要求该胖接口进行一个改动时,会影响到所有其他的客户程序.因此客户程序应该仅仅依赖他们实际需要调用的方法.
5.合成/聚合复用原则(Composite/Aggregate Reuse Principle,CARP)
在一个新的对象里面使用一些已有的对象,使之成为新对象的一部分;新的对象通过这些向对象的委派达到复用已有功能的目的.这个设计原则有另一个简短的表述:要尽量使用合成/聚合,尽量不要使用继承.
6.迪米特法则(Law of Demeter LoD)又叫做最少知识原则(Least Knowledge Principle,LKP),就是说,一个对象应当对其他对象有尽可能少的了了解.
迪米特法则最初是用来作为面向对象的系统设计风格的一种法则,与1987年秋天由Ian Holland在美国东北大学为一个叫做迪米特(Demeter)的项目设计提出的,因此叫做迪米特法则[LIEB89][LIEB86].这条法则实际上是很多著名系统,比如火星登陆软件系统,木星的欧罗巴卫星轨道飞船的软件系统的指导设计原则.
没有任何一个其他的OO设计原则象迪米特法则这样有如此之多的表述方式,如下几种:
(1)只与你直接的朋友们通信(Only talk to your immediate friends)
(2)不要跟"陌生人"说话(Don't talk to strangers)
(3)每一个软件单位对其他的单位都只有最少的知识,而且局限于那些本单位密切相关的软件单位.
就是说,如果两个类不必彼此直接通信,那么这两个类就不应当发生直接的相互作用,如果其中的一个类需要调用另一个类的某一个方法的话,可以通过第三者转发这个调用。
7.单一职责原则(Simple responsibility pinciple SRP)
就一个类而言,应该仅有一个引起它变化的原因,如果你能想到多于一个的动机去改变一个类,那么这个类就具有多于一个的职责.应该把多于的指责分离出去,分别再创建一些类来完成每一个职责.
另外：常说的OO五大原则就是指其中的：1、单一职责原则；2、开放闭合原则；3、里氏替换原则；4、依赖倒置原则；5、接口隔离原则。