开闭原则的定义
Software entities should be open for extension, but closed for modification.
软件实体应该对扩展是开放的,但是对于修改应当是关闭的.凡是定义一般都是很晦涩的,那么下面举一个应用场景来说明开闭原则的价值.
第一天,客户提出一个需求,我们需要将用户对象存储到文件的UserDAO.
解决方案:
public class UserDAO{
public void saveUser(User user)
{
//将一个用户对象存储到文件.
}
}
半个月后,客户有了新的需求,它们需要将一部分用户对象存储到XML文件.
方案1(破坏OCP原则):
public class UserDAO {
public void saveUser(User user, String saveMethod) {
if (saveMethod.equals("txt")) {
// 将一个用户对象存储到文本文件.
} else if (saveMethod.equals("xml")) {
// 将一个用户对象存储到xml文件.
}
}
}
这个方案带来的变化:
1.我要修改依赖UserDAO的类,让其多传入一个参数saveMethod
2.我要维护if...else判断的正确性,如果传入的字符不是txt和xml,那么我还要进行异常处理.
3.加入存储到xml的代码后我无法预知对原来存储到txt的功能是否造成了影响.
4.如果需求再一次变化,那么我必须继续修改saveUser方法,甚至可能因为需要更多的参数而修改了依赖UserDAO的类.
方案2(遵循OCP原则):
public interface IUserDAO {
public void saveUser(User user);
}
public class UserDAOTXTImp implements IUserDAO
{
public void saveUser(User user)
{
//存储到txt
}
}
public class UserDAOXMLImp implements IUserDAO
{
public void saveUser(User user)
{
//存储到xml
}
}
这个方案带来的变化:
1.我要修改依赖UserDAO的类,让其依赖IUserDAO接口.
2.我重新实现一个存储到xml的UserDAO.
3.即使需求发生变化,需要存储到数据库的,我只需要重新实现IUserDAO接口.
4.这样的修改不会破坏原有程序.
以上看来是一个标准的OCP原则教程,那么下面我们进行进一步的思考:
来看看我们破坏了几次OCP原则.
第一天的开发,没有破坏OCP原则,我们只是单纯的增加了一个新功能.
半个月后的开发,无论我们采用方案一还是方案二我们都破坏了OCP原则.
如果我们使用方案一,在以后的变化中我们就会继续破坏OCP原则,并且带来很多负面的影响.
如果我在第一天就采用IUserDAO,整个过程都不会破坏OCP原则,听起来很不错.
那么我来对比一下第一天就采用IUserDAO所带来的不同:
IUserDAO方案:
1.我要做更多的工作,如果以后没有两种以上的实现,这个接口将毫无意义.
2.如果接口不稳定,比如要增加一个读取用户的操作,那么我们必须修改IUserDAO与UserDAO两个地方,增加了额外的工作量.
3.增加了程序的复杂度.
这个方案如果以后没有需求变化,将给系统带来无用的设计以及更多的维护成本.
UserDAO方案:
1.即使有了需求变化,要抽取出一个借口也是非常方便的,相对于IUserDAO方案并没有多出太多的工作量.
2.使用UserDAO方案破坏了OCP原则,破坏了DIP原则,没有依赖于抽象而依赖于具体实现.但是,我们一定要遵循这些原则吗?
3.程序简单直接,易维护.
我无法预期半个月后的那次需求变动,因此我不应该做提前的设计.
我对OpenClose原则的解释:
你对一类问题需要
一个以上的解决方案,
那么当加入新的解决方案时,你的修改不应该对已有模块产生影响,而你可以通过对抽象的实现来进行扩展.
OpenClose原则对于此外的场景是无意义的,比如你要加入一个新功能,IUserDAO现在需要读取用户的方法,你肯定要打开IUserDAO进行修改,这个时候破坏OpenClose原则是必然的.
分享到：
何出此言？
相关推荐
2. **设计原则**：书中涵盖了设计模式和SOLID原则，如单一职责原则（SRP）、开闭原则（OCP）、里氏替换原则（LSP）、接口隔离原则（ISP）和依赖倒置原则（DIP）。这些原则有助于创建可维护、可扩展的代码结构。 3. ...
《敏捷软件开发原则、模式与实践》一书是由著名软件开发专家、软件工程大师Robert C. Martin所著。这本书自出版以来，就被视为敏捷开发领域内的经典之作，对于软件开发人员、项目经理以及软件项目领导者来说，它提供...
《敏捷软件开发：原则模式与实践》是由著名软件开发专家、软件工程大师Robert C. Martin（别名Uncle Bob）所著的指导书籍，旨在为软件开发人员、项目经理以及软件项目领导提供解决实际问题的方法和策略。本书将敏捷...
敏捷软件开发：原则、模式与设计.pdf敏捷软件开发：原则、模式与设计.pdf
### 敏捷开发原则详解 #### 一、引言 敏捷开发是一种强调适应性和灵活性的软件开发方法论，旨在提高团队的工作效率并确保项目的成功。本文将深入探讨敏捷开发的核心原则，包括其背景、核心价值观以及十二项指导原则...
然而，我仍可以就【标题】和【描述】中提及的主题——“传统企业敏捷转型的策略与思考”——提供一些详细的背景信息和知识点。 首先，传统企业在面临快速变化的市场和技术压力时，往往需要采取更加灵活和响应市场...
例如，他强调面向对象设计的重要性，提倡使用设计原则，如单一职责、开闭原则、依赖倒置原则等，以提高软件设计的质量。 此外，书中还包含了大量可复用的C++和Java源代码示例。这些代码示例不仅展示了如何实现特定...
本书中，享誉全球的软件开发专家和软件工程大师RobertC.Martin深入而生动地使用真实案例讲解了面向对象基本原则、重要的设计模式、UML和敏捷实践等程序员必备的知识。本书于2003年荣获第13届Jolt大奖，是C++和Java...
本书讲授了一些原则、模式以及实践，它们可以帮助软件开发人员在追求美的程序、设计以及团队的道路上迈出第一步。本书探索了基本的设计原则，软件设计结构的通用模式以及有利于团队融为一个有机整体的一系列实践。...
在本资源中，我们主要探讨的是敏捷软件开发的原则、模式与实践，特别是在C++编程语言中的应用。这一主题源于《敏捷软件开发》一书的第19章，该章节通过一个具体的薪水支付案例来阐述敏捷开发的方法。在这个案例中，...
3. **设计原则**：Uncle Bob提出了SOLID原则，这是面向对象设计的基本准则，包括单一职责原则、开闭原则、里氏替换原则、接口隔离原则和依赖倒置原则。这些原则指导开发者编写可维护、可扩展的代码。 4. **模式与...
SOLID代表的是单一职责原则（Single Responsibility Principle）、开闭原则（Open/Closed Principle）、里氏替换原则（Liskov Substitution Principle）、接口隔离原则（Interface Segregation Principle）和依赖...
《敏捷宣言及原则》深刻揭示了现代软件开发领域的一次重大变革，标志着传统瀑布式开发模式向更加灵活、高效、以人为本的敏捷开发方法的转变。本文将深入解析敏捷宣言的核心理念及其背后的十二项原则，旨在为读者提供...
5. **模式和实践**：Uncle Bob引入了一些软件开发的模式，如SOLID原则（单一职责原则、开闭原则、里氏替换原则、接口隔离原则和依赖倒置原则），这些原则有助于创建可维护和可扩展的代码。 6. **重构**：书中会讨论...
敏捷过程与极限编程，极限编程的有效实践 敏捷软件开发宣言
敏捷软件开发：原则、模式与设计 （中文pdf版）
敏捷开发实践与思考 敏捷开发是一种软件开发方法，它强调团队协作、快速响应变化、灵活适应需求和业务价值的 deliveries。敏捷开发实践的目的是为了提高项目的成功率，降低项目的风险和成本。以下是敏捷开发实践的...
敏捷软件开发 原则、模式与实践 （美）Robert C.Martin 著 邓辉 译 敏捷软件开发经典书籍 高清PDF
在C#编程中，敏捷方法鼓励采用面向对象设计原则，如单一职责原则（SRP）、开闭原则（OCP）、里氏替换原则（LSP）、接口隔离原则（ISP）和依赖倒置原则（DIP）。这些原则有助于构建松耦合、高内聚的代码结构，提高...