[设计模式] 浅谈SOLID设计原则

SOLID是一个缩写词，代表以下五种设计原则

1. 单一职责原则 Single Responsibility Principle, SRP
2. 开闭原则 Open-Closed Principle, OCP
3. 里氏替换原则 Liskov Substitution Principle, LSP
4. 接口隔离原则 Interface Segregation Principle, ISP
5. 依赖倒转原则 Dependency Inversion Principle, DIP

注：
这些原则是Robert C. Martin 于21世纪初提出的，实际上这只是从其著作&博客中几十条中选择出来的5条。Robert C. Martin，世界级编程大师，设计模式和敏捷开发先驱，敏捷联盟首任主席，C++ Report前主编。20世纪70年代初成为职业程序员，后创办Object Mentor公司并任总裁。后辈程序员亲切地称之为“Bob大叔”。

单一职责原则

现在有一个日记类Journal，包含标题和若干条记录，通过代码可以描述为：

class Journal
{
	std::string title;
	std::vector<std::string> entries;

	explicit Journal(const std::string& _title) : title{_title}{}
};

现在，添加一个 增加记录 的功能，每条记录以一个按序号增加的数字为前缀：

void Journal::add(const std::string& entry)
{
	static uint32_t count = 1;
	entries.push_back(to_string(count) + ": " + entry);
}

现在对于这个类的使用，我们可以直接：

Journal j{ "Happy Day" };

j.add("This is first log");
j.add("This is second log");

将 “添加记录”功能作为Journal类的一部分从业务角度来说，是有意义的，因为日记类本身就需要这个功能，维护日记中的记录是Journal类的职责，所以说Journal类中任何与记录有关的功能都是合理的。

现在有了一个新的需求：将日记信息持久化（简单来说保存到文件吧），那么也可以在Journal中添加一块代码：

void Journal::save(const std::string& filePath)
{
	std::ofstream ofs(filePath);
	for (const auto& s : entries)
	{
		ofs << s << endl;
	}
}

代码好写，但是，这么做是正确的吗？（不能够说这种方式是错的，但至少是不正确的），因为： Journal类的职责是维护日志记录，而不是将他们写到磁盘持久化！
如果将这个功能添加到有持久化需求的类中，有关持久化方法的改动都需要在每个类中修改，这显然不是我们想要的！
比较好的方法是：单独考虑这个功能，将这个feature添加到独立的类中，比如可以：

class PersistenctManager
{
	static void save(const Journal& j, const std::string& filePath)
	{
		std::ofstream ofs(filePath);
		for (const auto& s : j.entries)
		{
			ofs << s << endl;
		}
	}
};

这样就比前面的方式好了很多，涉及到持久化的地方只需要改动一处，而不需要往每个涉及到的类中去修改
这正是所说的单一职责原则：每个类只有一个职责，因此也只有一个修改该类的原因（当然是只有该职责发生变化时）

开闭原则

里氏替换原则

接口隔离原则

依赖倒转原则