SOLID原则：解释和实例

Posted 2022-12-07 J-A

tags:

篇首语：本文由小常识网(cha138.com)小编为大家整理，主要介绍了SOLID原则：解释和实例相关的知识，希望对你有一定的参考价值。

在面向对象编程中，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” 是关于行为的，以及模型的正确性不是内在的，而是由它的客户程序来体现。
接口隔离原则提供了一种方案，在不违反里氏替换原则的情况下，如何实现开闭原则。同时接口隔离的思想本身也体现了单一职责原则。
依赖倒置原则是过程式设计与面向对象设计的分水岭，通过适当的抽象，让高层模块和底层模块同样地可复用和可测试。同时它也被用来指导接口隔离原则。