大家好，又见面了，我是你们的朋友全栈君。如果您正在找激活码,请点击查看最新教程,关注关注公众号 “全栈程序员社区” 获取激活教程,可能之前旧版本教程已经失效.最新Idea2022.1教程亲测有效,一键激活。
Jetbrains全家桶1年46，售后保障稳定
在面向对象编程中，SOLID是5个重要的设计原则的缩写。首先是由著名的软件大师Robert C.Martin (Bob 大叔)在Design Principles and Design Patterns 中提出， 后来Michael Feathers 用SOLID来概括这五大原则。
SOLID原则使得软件设计更加容易理解、灵活和可维护。作为一名软件工程师，这5个原则我们必须知道。
本文，我将涵盖这些原则，并举例说明怎样是违背了原则，以及如何进行纠正来符合SOLID原则。
S — Single responsibility principle
在程序设计中，单一责任原则指的是每个模块或者类应该只有一个职责。
你可能听过这样一句谚语“做一件事并把它做好”，这指的就是单一责任原则。
在文章《Principles of Object Oriented Design》中，Bob 大叔定义责任为“改变的原因”。并认为有一个且仅有一个原因使得类或模块发生改变。
class User
{
void CreatePost(Database db, string postMessage)
{
try
{
db.Add(postMessage);
}
catch (Exception ex)
{
db.LogError("An error occured: ", ex.ToString());
File.WriteAllText("\LocalErrors.txt", ex.ToString());
}
}
}
在上述代码示例中，我们注意到*CreatePost()*方法有多个功能，创建新的邮件，在数据库中记录错误日志以及在本地文件记录错误日志。
这违背了单一责任原则。我们尝试修改如下：
class Post
{
private ErrorLogger errorLogger = new ErrorLogger();
void CreatePost(Database db, string postMessage)
{
try
{
db.Add(postMessage);
}
catch (Exception ex)
{
errorLogger.log(ex.ToString())
}
}
}
class ErrorLogger
{
void log(string error)
{
db.LogError("An error occured: ", error);
File.WriteAllText("\LocalErrors.txt", error);
}
}
通过把错误日志功能抽象出来，我们不再违背单一责任原则。
现在有2个类，每个类都有一个责任；创建邮件和记录一个错误日志。
O — Open/closed principle
在程序设计中，开闭原则指的是软件对象（类，模块，函数等等）应该对扩展开放，对修改关闭。
如果你熟悉OOP，那么对于多态应该不陌生。通过继承或接口实现，使得一个抽象类具有多个子类，就可以确保代码是符合开闭原则的。
这听起来有点困惑，所以接下来举个例子，你就会非常清楚我在说什么。
class Post
{
void CreatePost(Database db, string postMessage)
{
if (postMessage.StartsWith("#"))
{
db.AddAsTag(postMessage);
}
else
{
db.Add(postMessage);
}
}
}
在这个代码段中，每当邮件是用字符“#“开头，我们都需要做一些指定。然而，当有不同的字符开头，代码会有不同的行为，这违背了开闭原则。
比如，如果我们以后想用“@”开头，我们必须在CreatePost()方法中增加一个‘else if’，这修改了类。
这里简单使用了继承来使代码符合开闭原则。
class Post
{
void CreatePost(Database db, string postMessage)
{
db.Add(postMessage);
}
}
class TagPost : Post
{
override void CreatePost(Database db, string postMessage)
{
db.AddAsTag(postMessage);
}
}
通过使用继承，重写*CreatePost()*方法来创建邮件的扩展行为变得更加简单。
现在，判断第一个字符“#”可以在软件其它地方处理。更酷的事情是，如果我们想改变postMessage的判断方式，可以不影响基类的行为。
L — Liskov substitution principle
这个原则可能是第一次介绍时最难理解的一个。
在程序设计中，里氏替换原则指的是如果 S 是T 的子类，那么T 的实例可以用 S 的实例取代。
更一般的表述是，在不改变程序正确性的前提下，派生类对象可以在程序中代替其基类对象。
class Post
{
void CreatePost(Database db, string postMessage)
{
db.Add(postMessage);
}
}
class TagPost : Post
{
override void CreatePost(Database db, string postMessage)
{
db.AddAsTag(postMessage);
}
}
class MentionPost : Post
{
void CreateMentionPost(Database db, string postMessage)
{
string user = postMessage.parseUser();
db.NotifyUser(user);
db.OverrideExistingMention(user, postMessage);
base.CreatePost(db, postMessage);
}
}
class PostHandler
{
private database = new Database();
void HandleNewPosts() {
List<string> newPosts = database.getUnhandledPostsMessages();
foreach (string postMessage in newPosts)
{
Post post;
if (postMessage.StartsWith("#"))
{
post = new TagPost();
}
else if (postMessage.StartsWith("@"))
{
post = new MentionPost();
}
else {
post = new Post();
}
post.CreatePost(database, postMessage);
}
}
}
由于没有覆写，CreatePost()方法在子类MentionPost中不会起到应有的作用。
修改后如下：
...
class MentionPost : Post
{
override void CreatePost(Database db, string postMessage)
{
string user = postMessage.parseUser();
NotifyUser(user);
OverrideExistingMention(user, postMessage)
base.CreatePost(db, postMessage);
}
private void NotifyUser(string user)
{
db.NotifyUser(user);
}
private void OverrideExistingMention(string user, string postMessage)
{
db.OverrideExistingMention(user, postMessage);
}
}
...
通过重构MentionPost类，就能满足可替换性。
这只是一个不违背里氏替换原则的简单例子。然而，在实际使用过程中，这种情形可以用多种方式实现并且不易识别出来。
I — Interface segregation principle
这个原则理解起来很简单，实际上，如果你习惯于使用接口，很大概率上会用到这个原则。
在程序设计中，接口隔离原则指的是客户不应被迫使用对其而言无用的方法或功能。
简单来讲，不要在已有接口上增加新的方法来实现新的功能。相反的，可以创建新的接口，如果有必要，可以让你的类实现多个接口。
interface IPost
{
void CreatePost();
}
interface IPostNew
{
void CreatePost();
void ReadPost();
}
在上述代码示例中，假设我已经有了一个IPost 接口，包含CreatePost()方法；后来，我增加了一个新方法 ReadPost()，修改了这个接口，变成IPostNew 接口，这违背了接口隔离原则。修改如下：
interface IPostCreate
{
void CreatePost();
}
interface IPostRead
{
void ReadPost();
}
一旦任何类需要实现这2个方法，就将同时实现这2个接口。
D – Dependency inversion principle
最后，我们来看一下D，最后一个设计原则。
在程序设计中，依赖倒置原则用于解耦软件中的模块。这个原则表述如下：
- 高层的模块不应该依赖底层的模块，而应该依赖抽象；
- 抽象不应该依赖实现细节，实现细节应该依赖抽象。
为了遵循这一原则，我们需要使用一种设计模式称为依赖注入，典型的，依赖注入通过类的构造函数作为输入参数。
class Post
{
private ErrorLogger errorLogger = new ErrorLogger();
void CreatePost(Database db, string postMessage)
{
try
{
db.Add(postMessage);
}
catch (Exception ex)
{
errorLogger.log(ex.ToString())
}
}
}
观察到我们在Post 类中创建了ErrorLogger 实例，如果我们想使用不同的日志，我们需要修改Post类，这违背了依赖倒置原则。修改如下：
class Post
{
private Logger _logger;
public Post(Logger injectedLogger)
{
_logger = injectedLogger;
}
void CreatePost(Database db, string postMessage)
{
try
{
db.Add(postMessage);
}
catch (Exception ex)
{
_logger.log(ex.ToString());
}
}
}
通过使用依赖注入，我们不再依赖Post类来定义指定类型的日志。
OK，介绍完这么多，也大致理解了这几个原则。这些原则有区别，同时彼此间也有着联系。
- 单一职责原则是 SOLID 所有原则的基础和解决问题的思路。
- 开闭原则是直接保障代码质量的原则，用来解决设计的脆弱性、僵化、难以阅读、难以复用等问题，应用开闭原则的关键在于如何“抽象”。
- 里氏替换原则通过确保子类和父类是 “is a” 的关系，来帮助实现开闭原则。该原则的使用中，引申出面向对象角度的 “is a” 是关于行为的，以及模型的正确性不是内在的，而是由它的客户程序来体现。
- 接口隔离原则提供了一种方案，在不违反里氏替换原则的情况下，如何实现开闭原则。同时接口隔离的思想本身也体现了单一职责原则。
- 依赖倒置原则是过程式设计与面向对象设计的分水岭，通过适当的抽象，让高层模块和底层模块同样地可复用和可测试。同时它也被用来指导接口隔离原则。
参考
【2】Single Responsibility Principle in C++
【4】Open Closed Principle in C++
【6】Liskov’s Substitution Principle in C++
【8】Interface Segregation Principle in C++
【10】Dependency Inversion Principle in C++
That’s it!If you have any questions or feedback, please feel free to comment below.
-EOF-
发布者：全栈程序员-用户IM，转载请注明出处：https://javaforall.cn/215915.html原文链接：https://javaforall.cn
【正版授权，激活自己账号】： Jetbrains全家桶Ide使用，1年售后保障，每天仅需1毛
【官方授权 正版激活】： 官方授权 正版激活 支持Jetbrains家族下所有IDE 使用个人JB账号...