接口与接口设计原则
接口设计6大原则
接口设计6大原则
x
一、可控原则
可控原则要求在接口设计时，尽可能考虑所有的参数以及它们之间的依赖关系，而且要明确接口的输入输出和参数列表的并发情况，避免参数混淆，以此来确保接口的可控性。
二、易用原则
易用原则要求在接口设计时，应该考虑用户的使用习惯，避免使用复杂的参数，而是使用简单的参数，让用户更容易理解和使用接口，以此来提高接口的易用性。
三、高效原则
高效原则要求在接口设计时，考虑接口执行的效率，降低接口调用的开销，简化接口的功能，并优化程序的运行时间，以此来提高接口的执行效率。
四、可扩展原则
可扩展原则要求在接口设计时，应该考虑接口的可扩展性，并为接口设计一些插件接口，这样可以给接口添加更多的功能，以此来提高接口的可扩展性。
五、可持续原则
可持续原则要求在接口设计时，应该考虑接口的维护性和可持续性，避免使用过时的技术，而是选择稳定性更高、技术更新更快的技术，以此来确保接口的可持续性。
六、安全原则
安全原则要求在接口设计时，考虑接口的安全性，避免接口受到未授权的访问，采取加密等机制来保护接口的安全性，以此来保证接口的安全性。
API接口设计原则
API接口设计原则一、针对接口编程，而不是针对实现编程-客户无需知道所使用对象的特定类型，只需要知道对象拥有客户所期望的接口。
小注：接口是定义行为，只是定义我们要做什么事情，至于如何做这些事情是由接口的实现来做的，当我们定义接口的时候无需关心这个行为如何实现，只要知道有这个接口就可以。
别人在调用你的代码的时候，都是调用你的接口对象，至于如何实现，对别人是透明的。
二、优先使用对象组合，而不是类继承-类继承通常为“白箱复用”，对象组合通常为“黑箱复用”。
继承在某种程度上破坏了封装性，子类父类耦合度高；而对象组合则只要求被组合的对象具有良好定义的接口，耦合度低。
小注：因为继承在编译时刻就定义了，所以无法在运行时刻改变从父类继承的实现。
更糟的是，父类通常至少定义了部分子类的具体表示。
因为继承对子类揭示了其父类的实现细节，所以继承常被认为破坏了封装性”。
子类中的实现与它的父类有如此紧密的依赖关系，以至于父类实现中的任何变化必然会导致子类发生变化。
当你需要复用子类时，实现上的依赖性就会产生一些问题。
如果继承下来的实现不适合解决新的问题，则父类必须重写或被其他更适合的类替换。
这种依赖关系限制了灵活性并最终限制了复用性。
一个可用的解决方法就是只继承抽象类，因为抽象类通常提供较少的实现。
对象组合是通过获得对其他对象的引用而在运行时刻动态定义的。
组合要求对象遵守彼此的接口约定，进而要求更仔细地定义接口，而这些接口并不妨碍你将一个对象和其他对象一起使用。
这还会产生良好的结果：因为对象只能通过接口访问，所以我们并不破坏封装性；只要类型一致，运行时刻还可以用一个对象来替代另一个对象；更进一步，因为对象的实现是基于接口写的，所以实现上存在较少的依赖关系。
对象组合对系统设计还有另一个作用，即优先使用对象组合有助于你保持每个类被封装，并被集中在单个任务上。
这样类和类继承层次会保持较小规模，并且不太可能增长为不可控制的庞然大物。
系统之间接口设计原则
系统之间接口设计原则
1. 单一职责原则
每个系统之间的接口应该只涉及到其特定的领域和职责。
2. 开闭原则
接口应该尽可能地开放和扩展，同时保持稳定性和兼容性。
3. 接口明确原则
接口需要明确表达其意图和能力，以便使用者可以准确地理解其功能。
4. 规范化原则
接口需要遵循一定的规范和标准，以便与其他系统相互通信。
5. 可测试性原则
接口需要具有良好的可测试性，以便开发、测试和维护人员能够快速有效地进行调试和修正。
6. 一致性原则
接口的命名、参数和返回值应该保持一致性，以便开发人员能够方便地使用。
7. 考虑安全原则
接口需要考虑安全性，以防止非法操作和攻击。
8. 性能优化原则
接口需要优化其性能，以便能够快速响应请求，并且尽可能减少造成系统阻塞和资源耗尽的问题。
接口应该支持可扩展性，以便能够适应未来的需求变化和发展。
接口需要支持可重用性，以方便其他系统可以直接复用已有的接口，减少重复造轮子的开发成本。
接口设计六大原则
接⼝设计六⼤原则⼀.单⼀职责原则Single Responsibility Principle, 简称SRP。
定义：There should never be more than one reason for a class to change.应该有且仅有⼀个原因引起类的变更。
职责的划分？单⼀的定义和级别？应该根据实际业务情况⽽定。
关注变化点。
实际使⽤时，类很难做到职责单⼀，但是接⼝的职责应该尽量单⼀。
⼆.⾥⽒替换原则Liskov Substitution Principle, 简称LSP。
定义：Functions that use pointers or references to base classes must be able to use objects of derived classes without knowing it. (所有引⽤基类的地⽅必须能透明地使⽤其⼦类的对象)⾥⽒替换原则为良好的继承定义了⼀个规范：1.⼦类必须完全实现⽗类的⽅法2.⼦类可以有⾃⼰的个性（属性和⽅法）。
3.覆盖或实现⽗类的⽅法时输⼊参数可以被放⼤。
4.覆写或实现⽗类的⽅法时输出结果可以被缩⼩。
注：在类中调⽤其他类时务必要使⽤⽗类或接⼝，如果不能使⽤⽗类或接⼝，则说明类的设计已经违背了ＬＳＰ原则。
三.依赖倒置原则Dependence Inversion Principle, 简称DIP定义：High level modules should not depend upon low level modules.Both should depend upon abstractions.Abstractions should not depend upon details.Details should depend upon abstractions.翻译过来，包含三层含义：1.⾼层模块不应该依赖低层模块，两者都应该依赖其抽象。
接口设计原则如何设计易用和可扩展的接口
接口设计原则如何设计易用和可扩展的接口在软件开发中，接口是系统不同部分之间进行通信和交互的关键组成部分。
一个好的接口设计可以使系统更易用和可扩展。
本文将介绍一些接口设计原则，帮助开发者设计易用和可扩展的接口。
一、一致性原则一致性是接口设计中非常重要的原则之一，它指的是接口设计应该遵循统一的设计规范和风格。
一致的接口设计可以提供用户熟悉和可预测的交互体验，减少学习和使用难度。
在接口设计中，可以通过以下方式提高一致性：1. 使用统一的命名规范：接口中的方法、属性和参数应使用统一的命名规范，避免使用混乱或不一致的命名方式。
2. 遵循统一的设计风格：界面元素的布局、颜色、图标等应保持一致，使用户在不同的界面中能够迅速找到所需功能。
3. 提供一致的交互方式：相似功能的接口应该有相似的交互方式，用户可以通过类似的操作完成不同的任务，提高使用效率。
二、简洁性原则接口设计应尽量简洁明了，避免冗余和复杂化的设计。
简洁的接口设计能够提高使用效率，并减少出错的可能性。
以下是一些建议来实现简洁的接口设计：1. 最小化接口方法和参数：接口中的方法和参数应该尽量减少，只包含必需的功能和信息，避免接口臃肿。
2. 提供清晰的文档说明：接口应该有清晰的文档说明，描述接口的功能、使用方法和预期行为等信息，帮助用户快速了解接口。
3. 合理使用默认值：对于可选的参数或属性，可以提供一个默认值，避免用户在每次使用接口时都必须指定。
三、可扩展性原则为了适应系统的发展和变化，接口设计应具备良好的可扩展性。
一个可扩展的接口可以方便地添加新功能和改进现有功能，而不会破坏已有的代码或接口。
以下是一些提高接口可扩展性的原则：1. 单一职责原则：接口应该只包含一个单一的功能或职责，避免接口过于庞大和复杂。
2. 松耦合原则：接口之间应该松耦合，避免接口之间的依赖性过强。
接口之间的耦合度越低，对接口的修改对其他接口的影响就越小。
3. 扩展点设计：在接口中设置一些扩展点，通过插件机制或回调函数来扩展接口的功能。
接口设计的基本原则及其实现
接口设计的基本原则及其实现接口设计的基本原则及其实现随着现代软件开发的迅速发展，软件设计中的接口设计显得尤为重要。
好的接口设计可以帮助我们实现良好的代码设计、提高软件的可维护性、可扩展性和可重用性。
本文将探讨接口设计的基本原则及其实现，以期为日后的软件开发工作提供一些指导和参考。
一、接口设计的基本原则1.简洁明了好的接口设计应该是简洁明了的，用户能够较快地读懂并使用接口。
在设计接口时，应当考虑用户体验和易用性。
2.让接口有意义接口应该具有明确的含义，而不应该是难以理解或理解困难的代码。
在编写接口时，应该使接口的名称和参数具有意义，并确保它们与接口的实际用途相符。
3.开闭原则好的接口设计应该遵循开闭原则。
这意味着在增加新功能时，不需要修改已有的代码。
为了实现这个目标，在设计接口时应该考虑到可能的需求变化，并相应地设计和实现接口。
4.容错性好的接口设计应该容错，即使用户使用不合理的输入，它也能够生成正确的异常。
在设计接口时，应该确保在所有情况下，接口都能正常工作，并对任何不合理的输入进行适当的处理。
5.文档化好的接口设计应该有清晰、准确的文档，这可以帮助用户和开发者了解接口的用法和数据结构。
文档应该包含有关接口的输入和输出的描述以及如何使用接口的示例。
6.避免让用户记忆太多信息好的接口设计应该尽量减少要求用户记忆的信息。
例如，一些工具库可能需要用户记住大量的函数名称和参数，这会降低接口的易用性。
在设计接口时，应该将必要的信息嵌入到接口本身，以方便用户使用。
二、接口设计的实现1.设计RESTful Web接口RESTful Web接口是一种在现代软件开发中普遍使用的接口设计方法。
它可以使用HTTP协议定义API接口。
设计RESTful Web接口时，应该遵循以下原则：-每个资源都应该有一个唯一的URI（统一资源标识符）。
-使用HTTP方法来定义对资源的操作。
例如，GET方法表示获取资源，POST方法表示创建资源，PUT方法表示更新资源，DELETE方法表示删除资源。
掌握软件设计中的接口设计
掌握软件设计中的接口设计接口设计是软件设计中至关重要的一部分，它指定了不同模块之间的通信规范和数据交互方式。
在软件开发过程中，掌握好接口设计的技巧和原则，可以提高软件的扩展性、可重用性和可维护性。
本文将从接口设计的基本概念、重要性以及一些实用的设计原则等方面进行探讨。
1. 接口设计的基本概念接口是软件系统中的一个重要概念，它定义了模块与模块之间的协议，规定了它们之间如何进行通信和数据交互。
接口可以看作是两个或多个对象之间的“契约”，它规定了对象之间可调用的方法和参数等。
在软件设计中，接口通常以接口类或接口文件的形式存在。
2. 接口设计的重要性2.1 实现模块化接口设计有助于实现软件的模块化，将一个庞大复杂的系统分解成若干独立的模块，各模块之间通过接口进行通信和交互。
这样可以提高系统的可读性、可维护性和可重用性。
2.2 解耦合接口设计可以解耦合不同模块之间的依赖关系，使得模块之间的修改相互独立。
当一个模块发生改变时，只需要关注与之相关的接口定义，而不影响其他模块的实现。
2.3 提高系统拓展性通过接口设计，可以为模块提供统一的扩展点，方便后续对系统功能进行拓展和升级。
3. 接口设计的原则3.1 单一职责原则接口应该遵循单一职责原则，即每个接口只负责一个功能或一个业务逻辑。
这样可以降低接口的复杂度，提高可理解性和可维护性。
3.2 依赖倒置原则接口设计应该遵循依赖倒置原则，即依赖于抽象而非具体实现。
模块之间的依赖关系应该基于接口而非具体类，这样可以提高系统的灵活性和扩展性。
3.3 接口内聚性原则接口应该具有高内聚性，即相近的行为应该放在同一个接口中。
这样可以提高接口的可读性和可理解性。
3.4 接口的命名规范接口的命名应该抽象、清晰，并且能够准确地表达其所代表的功能或业务。
命名规范可以提高代码的可读性和可维护性。
4. 接口设计的实践方法4.1 面向对象设计原则在接口设计中，可以借鉴面向对象设计原则，如开闭原则、里氏替换原则等，以提高接口的灵活性和可复用性。
接口的设计原则有哪些？
接口的设计原则有哪些？一、单一职责原则单一职责原则是指一个接口只负责一个职责或者功能。
一个接口承担过多的职责会导致接口设计复杂，不易维护和扩展。
因此，在设计接口时应该遵循单一职责原则，将不同的功能拆分成多个接口，并且每个接口只关注自己的功能。
单一职责原则的优点在于可以提高代码的可读性和可维护性。
同时，通过将功能拆分成多个接口，可以使得代码更加灵活，当系统需要新增功能时，不会影响到其他功能的实现。
二、开闭原则开闭原则是指接口设计应该是对扩展开放，对修改关闭。
这意味着当系统需要新增功能时，不应该修改已有的接口，而是应该通过扩展接口来实现功能的新增。
开闭原则的核心思想是通过接口的抽象来实现功能的扩展。
通过定义一个稳定的接口，可以保证系统的稳定性和可维护性。
当需要新增功能时，只需要实现新的接口，而不需要修改已有的接口，可以有效减少代码的改动范围，提高系统的稳定性。
三、依赖倒置原则依赖倒置原则是指高层模块不应该依赖于低层模块的具体实现，而应该依赖于抽象。
接口的设计应该基于抽象，而不是具体的实现。
这样可以降低模块之间的耦合性，提高系统的灵活性。
依赖倒置原则的好处在于可以实现模块间的解耦，当需要修改某个模块的具体实现时，不会影响到其他模块的运行。
同时，通过依赖抽象，可以使得系统更加可扩展，当需要新增功能时，只需要实现抽象接口，不会影响到其他模块的运行。
四、接口隔离原则接口隔离原则是指接口的设计应该精细化，不应该一次性暴露所有的功能。
一个接口应该只提供给客户端需要的功能，而不是提供所有的功能。
通过精细化的接口设计，可以提高代码的可复用性和灵活性。
接口隔离原则的优点在于可以避免接口的臃肿和冗余。
当一个接口提供了过多的功能时，会导致客户端依赖于不需要的功能，增加客户端代码的复杂性。
通过将接口细分成多个小的接口，可以避免这种问题，提高代码的可读性和可维护性。
五、迪米特原则迪米特原则是指一个对象应该尽可能少的与其他对象进行交互。
接口设计规范范文
接口设计规范范文1.接口一致性：接口应该尽可能地统一命名，使用相同的参数命名和返回值类型，以减少不必要的学习成本和开发难度。
2.接口简洁性：接口应该尽可能地简单明了，只包含必要的方法和参数。
过于复杂的接口不仅会增加理解和使用的难度，还会降低系统的性能。
3.接口的单一职责原则：接口应该只负责一个特定的功能，不同功能的接口应该分开设计，遵循“高内聚、低耦合”的设计原则。
4.接口的可扩展性：接口应该预留足够的扩展空间，允许新增功能的加入而不影响已有的功能。
可以通过使用抽象类或接口来定义公共方法和属性，以方便后续的扩展。
5.接口的可维护性：接口应该明确规定每个方法的输入、输出以及可能的异常情况，提供足够的文档和注释。
这样可以降低发生错误的几率，减少维护成本。
6.接口的可重用性：接口应该尽可能地通用化，避免与具体的实现细节耦合在一起。
这样可以提高接口的重用率，减少代码的重复编写。
7.接口的安全性：接口应该进行必要的身份验证和授权，以防止非法访问和操作。
可以使用认证和授权机制，如OAuth等。
8.接口的性能优化：接口应该设计成高性能的，尽量减少不必要的数据传输和计算，避免使用过于复杂的数据结构。
9.接口的版本管理：当接口需要进行修改时，应该通过版本管理的方式来兼容旧版本的接口。
可以通过在接口名称中添加版本号或者使用适配器模式来实现。
总结来说，一个好的接口设计规范应该具有一致性、简洁性、单一职责原则、可扩展性、可维护性、可重用性、安全性和性能优化。
通过遵循这些规范，可以提高系统的质量和开发效率，减少后续的维护成本。
接口设计：合理设计接口,提高系统的可扩展性和可维护性
接口设计：合理设计接口，提高系统的可扩展性和可维护性章节一：介绍引言：接口设计在软件开发中起着至关重要的作用，合理设计接口可以提高系统的可扩展性和可维护性。
本文将介绍接口设计的重要性以及一些常用的接口设计原则。
段落一：接口设计的重要性现代软件系统通常由多个组件或模块组成，这些组件通过接口进行通信和交互。
接口设计的好坏直接影响系统的灵活性、可扩展性和可维护性。
合理设计的接口能够降低模块之间的耦合度，提高代码的可复用性和可测试性。
段落二：常用的接口设计原则1. 单一职责原则（SRP）：一个接口应该只有一个职责或功能。
这样可以确保接口的职责清晰，提高代码的可读性和可维护性。
2. 开闭原则（OCP）：接口应该对扩展开放，对修改关闭。
当需求发生变化时，我们应该通过扩展接口而不是修改已有的接口来满足新的需求。
这样可以避免对原有代码的影响，提高系统的可维护性。
3. 里氏替换原则（LSP）：子类型必须能够替换其基类型。
接口设计应该遵循里氏替换原则，保证子类型对象能够无缝地替换基类型对象，不破坏原有系统的行为。
4. 接口隔离原则（ISP）：客户端不应该依赖它不需要的接口。
接口应该精简而具体，只包含客户端所需的方法。
这样可以避免接口的臃肿和冗余。
5. 依赖倒置原则（DIP）：依赖于抽象而不是具体实现。
客户端应该依赖于接口而不是具体的实现类，这样可以降低模块之间的耦合度。
段落三：接口设计的实践1. 定义清晰的接口：接口应该具有明确的名称和功能描述，让其他开发人员容易理解接口的用途和使用方式。
2. 合理划分接口：将功能相似的方法或属性划分到同一个接口中，遵循单一职责原则。
这样可以提高接口的内聚性，降低接口的耦合度。
3. 接口版本管理：当需要对接口进行变更时，应该采用适当的版本管理策略。
通过版本管理，可以确保对接口进行有序的更新和向后兼容。
4. 引入中间层：对于复杂的系统，可以引入中间层来对接口进行封装和管理。
中间层可以提供额外的功能，如缓存、安全验证等，同时也能够对接口进行统一的管理和监控。
- 1、下载文档前请自行甄别文档内容的完整性，平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益，请联系客服反馈,我们会尽快为您处理(人工客服工作时间：9:00-18:30)。
接口与接口设计原则一．11种设计原则1.单一职责原则 - Single Responsibility Principle(SRP)就一个类而言，应该仅有一个引起它变化的原因。
职责即为“变化的原因”。
2.开放-封闭原则 - Open Close Principle(OCP)软件实体（类、模块、函数等）应该是可以扩展的，但是不可修改。
对于扩展是开放的,对于更改是封闭的. 关键是抽象.将一个功能的通用部分和实现细节部分清晰的分离开来。
开发人员应该仅仅对程序中呈现出频繁变化的那些部分作出抽象. 拒绝不成熟的抽象和抽象本身一样重要 )3.里氏替换原则 - Liskov Substitution Principle(LSP)子类型(subclass)必须能够替换掉它们的基类型(superclass)。
4.依赖倒置原则(IoCP) 或依赖注入原则 - Dependence Inversion Principle(DIP)抽象不应该依赖于细节。
细节应该依赖于抽象。
Hollywood原则: "Don't call us, we'll call you". 程序中所有的依赖关系都应该终止于抽象类和接口。
针对接口而非实现编程。
任何变量都不应该持有一个指向具体类的指针或引用。
任何类都不应该从具体类派生。
任何方法都不应该覆写他的任何基类中的已经实现了的方法。
5.接口隔离原则(ISP)不应该强迫客户依赖于它们不用的方法。
接口属于客户，不属于它所在的类层次结构。
多个面向特定用户的接口胜于一个通用接口。
6.重用发布等价原则(REP)重用的粒度就是发布的粒度。
7.共同封闭原则(CCP)包(类库、DLL)中的所有类对于同一类性质的变化应该是共同封闭的。
一个变化若对一个包产生影响，则将对该包中的所有类产生影响，而对于其他的包不造成任何影响。
8.共同重用原则(CRP)一个包(类库、DLL)中的所有类应该是共同重用的。
如果重用了包(类库、DLL)中的一个类，那么就要重用包(类库、DLL)中的所有类。
(相互之间没有紧密联系的类不应该在同一个包(类库、DLL)中。
)包(类库、DLL)耦合原则9.无环依赖原则(ADP)在包的依赖关系图中不允许存在环。
10.稳定依赖原则(SDP)朝着稳定的方向进行依赖。
应该把封装系统高层设计的软件（比如抽象类）放进稳定的包中，不稳定的包中应该只包含那些很可能会改变的软件（比如具体类）。
11.稳定抽象原则(SAP)包的抽象程度应该和其稳定程度一致。
一个稳定的包应该也是抽象的，一个不稳定的包应该是抽象的.其它扩展原则12.BBP(Black Box Principle)黑盒原则多用类的聚合，少用类的继承。
13.DAP(Default Abstraction Principle)缺省抽象原则在接口和实现接口的类之间引入一个抽象类,这个类实现了接口的大部分操作.14.IDP(Interface Design Principle)接口设计原则规划一个接口而不是实现一个接口。
15.DCSP(Don't Concrete Supperclass Principle)不要构造具体的超类原则，避免维护具体的超类。
16.迪米特法则一个类只依赖其触手可得的类。
二．类的设计原则1.开闭原则Software entities (classes, modules, function, etc.) should be open for extension, but closed for modification.软件实体（模块，类，方法等）应该对扩展开放，对修改关闭。
开闭原则（OCP：Open-Closed Principle）是指在进行面向对象设计（OOD：Object Oriented Design）中，设计类或其他程序单位时，应该遵循：- 对扩展开放（open）- 对修改关闭（closed）的设计原则。
开闭原则是判断面向对象设计是否正确的最基本的原理之一。
根据开闭原则，在设计一个软件系统模块（类，方法）的时候，应该可以在不修改原有的模块（修改关闭）的基础上，能扩展其功能（扩展开放）。
- 扩展开放：某模块的功能是可扩展的，则该模块是扩展开放的。
软件系统的功能上的可扩展性要求模块是扩展开放的。
- 修改关闭：某模块被其他模块调用，如果该模块的源代码不允许修改，则该模块修改关闭的。
软件系统的功能上的稳定性，持续性要求是修改关闭的。
这也是系统设计需要遵循开闭原则的原因：1）稳定性。
开闭原则要求扩展功能不修改原来的代码，这可以让软件系统在变化中保持稳定。
2）扩展性。
开闭原则要求对扩展开放，通过扩展提供新的或改变原有的功能，让软件系统具有灵活的可扩展性。
遵循开闭原则的系统设计，可以让软件系统可复用，并且易于维护。
开闭原则的实现方法为了满足开闭原则的对修改关闭（closed for modification）原则以及扩展开放（open for extension）原则，应该对软件系统中的不变的部分加以抽象，在面向对象的设计中，- 可以把这些不变的部分加以抽象成不变的接口，这些不变的接口可以应对未来的扩展；- 接口的最小功能设计原则。
根据这个原则，原有的接口要么可以应对未来的扩展；不足的部分可以通过定义新的接口来实现；- 模块之间的调用通过抽象接口进行，这样即使实现层发生变化，也无需修改调用方的代码。
接口可以被复用，但接口的实现却不一定能被复用。
接口是稳定的，关闭的，但接口的实现是可变的，开放的。
可以通过对接口的不同实现以及类的继承行为等为系统增加新的或改变系统原来的功能，实现软件系统的柔软扩展。
简单地说，软件系统是否有良好的接口（抽象）设计是判断软件系统是否满足开闭原则的一种重要的判断基准。
现在多把开闭原则等同于面向接口的软件设计。
开闭原则的相对性软件系统的构建是一个需要不断重构的过程，在这个过程中，模块的功能抽象，模块与模块间的关系，都不会从一开始就非常清晰明了，所以构建100%满足开闭原则的软件系统是相当困难的，这就是开闭原则的相对性。
但在设计过程中，通过对模块功能的抽象（接口定义），模块之间的关系的抽象（通过接口调用），抽象与实现的分离（面向接口的程序设计）等，可以尽量接近满足开闭原则。
2.单一职责原则前言Robert C. Martin氏为我们总结了在面向对象的设计（OOD）中应该遵循的原则，这些原则被称为“Principles of OOD”，关于“Principles of OOD”的相关文章可以从Object Menter得到。
本文介绍“Principles of OOD”中的单一职责原则：Single Responsibility Principle (SRP)。
可以从这里查看Single Responsibility Principle (SRP)的原文。
概要There should never be more than one reason for a class to change.永远不要让一个类存在多个改变的理由。
换句话说，如果一个类需要改变，改变它的理由永远只有一个。
如果存在多个改变它的理由，就需要重新设计该类。
SRP（Single Responsibility Principle）原则的核心含意是：只能让一个类有且仅有一个职责。
这也是单一职责原则的命名含义。
为什么一个类不能有多于一个以上的职责呢？如果一个类具有一个以上的职责，那么就会有多个不同的原因引起该类变化，而这种变化将影响到该类不同职责的使用者（不同用户）：1，一方面，如果一个职责使用了外部类库，则使用另外一个职责的用户却也不得不包含这个未被使用的外部类库。
2，另一方面，某个用户由于某个原因需要修改其中一个职责，另外一个职责的用户也将受到影响，他将不得不重新编译和配置。
这违反了设计的开闭原则，也不是我们所期望的。
职责的划分既然一个类不能有多个职责，那么怎么划分职责呢？Robert.C Martin给出了一个著名的定义：所谓一个类的一个职责是指引起该类变化的一个原因。
If you can think of more than one motive for changing a class, then that class has more than one responsibility.如果你能想到一个类存在多个使其改变的原因，那么这个类就存在多个职责。
Single Responsibility Principle (SRP)的原文里举了一个Modem的例子来说明怎么样进行职责的划分，这里我们也沿用这个例子来说明一下：SRP违反例：public interface Modem {public void dial(String pno); //拨号public void hangup(); //挂断public void send(char c); //发送数据public char recv(); //接收数据}咋一看，这是一个没有任何问题的接口设计。
但事实上，这个接口包含了2个职责：第一个是连接管理（dial, hangup）；另一个是数据通信（send, recv）。
很多情况下，这2个职责没有任何共通的部分，它们因为不同的理由而改变，被不同部分的程序调用。
所以它违反了SRP原则。
下面的类图将它的2个不同职责分成2个不同的接口，这样至少可以让客户端应用程序使用具有单一职责的接口：接口定义具体类实现让ModemImplementation实现这两个接口。
我们注意到，ModemImplementation又组合了2个职责，这不是我们希望的，但有时这又是必须的。
通常由于某些原因，迫使我们不得不绑定多个职责到一个类中，但我们至少可以通过接口的分割来分离应用程序关心的概念。
事实上，这个例子一个更好的设计应该是这样的，如图：接口定义具体类实现小结Single Responsibility Principle (SRP)从职责（改变理由）的侧面上为我们对类（接口）的抽象的颗粒度建立了判断基准：在为系统设计类（接口）的时候应该保证它们的单一职责性。
3接口分隔原则前言Robert C. Martin氏为我们总结了在面向对象的设计（OOD）中应该遵循的原则，这些原则被称为“Principles of OOD”，关于““Principles of OOD”的相关文章可以从Object Menter得到。
本文介绍“Principles of OOD”中的接口分隔原则：Interface Segregation Principle (ISP)。
可以从这里查看Interface Segregation Principle (ISP)的原文。