开闭原则(C++)

概念

   对于扩展是开放的,对于更改是封闭的。面对新的需求,对程序的改动是通过新加代码而进行的,不是更改现有的代码。

简述

   开闭原则是面向对象设计的核心所在。遵循这个原则可以带来面向对象技术所声称的巨大好处,也就是可维护,可扩展,可复用,灵活性好。开发人员应该仅对程序中出现频繁变化的那些部分做出抽象,对于应用程序每个部分都刻意进行抽象同样不是一个好主意。拒绝不成熟的抽象和抽象本身一样重要。

场景一:

   当前需要写一个加减法的计算器。可以这样实现。

UML类图:

代码:

#include <stdio.h>
#include <iostream>

//计算器类
class Calculator
{
public:
	Calculator()
	{

	}
	~Calculator() {};

	double getompute(char c)
	{
		switch (c)
		{
		case '+':
			return mA + mB;
			break;
		case '-':
			return mA - mB;
			break;
		default:
			break;
		}
	}
public:
	double mA;
	double mB;
};

//客户端
int main(void)
{
	Calculator calculator;

	while (true)
	{
		std::cout << "请输入数字:";
		std::cin >> calculator.mA;
		std::cout << "请输入数字:";
		std::cin >> calculator.mB;
		std::cout << "进行计算:";
		char c = '0';
		std::cin >> c;
		
		std::cout << "计算结果:" << calculator.getompute(c) << std::endl;
	}

	return 0;
}

场景二:

    由于需求变化,现在需要加上乘法和除法。

代码:

//计算器类
class Calculator
{
public:
	Calculator()
	{

	}
	~Calculator() {};

	double getompute(char c)
	{
		switch (c)
		{
		case '+':
			return mA + mB;
			break;
		case '-':
			return mA - mB;
			break;
		case '*':
			return mA * mB;
			break;
		case '/':
			return mA / mB;
			break;
		default:
			break;
		}
	}
public:
	double mA;
	double mB;
};

    修改后也可以实现功能,但如果需要再添加开方,取余等功能。必须再次修改Calculator,明显违背了开闭原则。

场景三:

   对Calculator进行改进

UML类图:

代码:

#include <stdio.h>
#include <iostream>

//计算器类  
class Calculator
{
public:
	Calculator()
	{

	}
	~Calculator() {};

	//抽象接口类,子类实现
	virtual double getompute()
	{
		return 0;
	}
public:
	double mA;
	double mB;
};

//除
class Division : public Calculator
{
public:
	virtual double getompute()
	{
		return mA / mB;
	}
};
//乘
class Multiplication : public Calculator
{
public:
	virtual double getompute()
	{
		return mA * mB;
	}
};
//减
class Subtraction : public Calculator
{
public:
	virtual double getompute()
	{
		return mA - mB;
	}
};
//加
class Addition : public Calculator
{
public:
	virtual double getompute()
	{
		return mA + mB;
	}
};

//工厂,根据不同的计算方式生产类
Calculator* CreateCalculator(char c)
{
	switch (c)
	{
	case '+':
		return new Addition;
		break;
	case '-':
		return new Subtraction;
		break;
	case '*':
		return new Multiplication;
		break;
	case '/':
		return new Division;
		break;

	default:
		return NULL;
		break;
	}
}

//客户端
int main(void)
{
	Calculator *calculator = NULL;

	calculator = CreateCalculator('-');

	calculator->mA = 10;
	calculator->mB = 5;
	std::cout << "计算结果:" << calculator->getompute() << std::endl;

	while (true) {};
	return 0;
}


  • 4
    点赞
  • 12
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
设计模式通常遵循以下几种原则: 1. 单一职责原则(Single Responsibility Principle,SRP):一个类应该只有一个引起变化的原因。换句话说,一个类应该只负责一项职责。 2. 开闭原则(Open-Closed Principle,OCP):软件实体(类、模块、函数等)应该对扩展开放,对修改关闭。这意味着当需要添加新功能时,应该通过扩展已有代码来实现,而不是修改已有代码。 3. 里氏替换原则(Liskov Substitution Principle,LSP):子类应该能够替换掉父类并且不会产生任何错误或异常。换句话说,子类应该能够以父类的形式出现,而不引起任何问题。 4. 依赖倒置原则(Dependency Inversion Principle,DIP):高层模块不应该依赖低层模块,两者都应该依赖于抽象。抽象不应该依赖于具体实现细节,具体实现细节应该依赖于抽象。 5. 接口隔离原则(Interface Segregation Principle,ISP):客户端不应该依赖它不需要的接口。一个类对另一个类的依赖应该建立在最小的接口上。 6. 迪米特法则(Law of Demeter,LoD):一个对象应该对其他对象有尽可能少的了解。一个类应该只与其直接合作的类进行通信,而不应该了解一大堆其他的类。 这些原则帮助开发人员设计出可维护、可扩展、松耦合的软件系统,提高代码的质量和可复用性。它们被广泛应用于设计模式中,帮助解决各种软件开发中常见的问题。

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值