Go最全Python 中的 SOLID 原则_正交四原则和solid原则 python(4)，2024年最新最新2024年Golang大厂面试经验

既有适合小白学习的零基础资料，也有适合3年以上经验的小伙伴深入学习提升的进阶课程，涵盖了95%以上Go语言开发知识点，真正体系化！

由于文件比较多，这里只是将部分目录截图出来，全套包含大厂面经、学习笔记、源码讲义、实战项目、大纲路线、讲解视频，并且后续会持续更新

如果你需要这些资料，可以戳这里获取

现在 可以重新设计Board类，使其不关心传递给它的形状类型，只要它们实现 area() 方法即可。

class Board():
def __init__(self, shapes):
self._shapes = shapes

def calculateArea(self):
    area = 0
    for shape in self._shapes:
        area += shape.area()
    return area

我们现在已经设置了这些对象，这意味着如果我们有不同类型的对象，我们不需要改变Board类。我们只是创建实现Shape的对象，并以与其他类相同的方式将其传递到集合中。


### 里氏替换原则


由 Barbara Liskov 在 1987 年创建，它指出对象应该可以被它们的子类型替换而不改变程序的工作方式。换句话说，派生类必须可以替代它们的基类而不会导致错误。


下面的代码定义了一个Rectangle类，我们可以用它来创建和计算矩形的面积。

class Rectangle():
def __init__(self, width, height):
self._width = width
self._height = height

def get\_width(self):
    return self._width

def set\_width(self, width):
    self._width = width

def get\_height(self):
    return self._height

def set\_height(self, height):
    self._height = height

def area(self):
    return self.get\_width() \* self.get\_height()

使用它，我们可以将其扩展为Square类。因为正方形与矩形略有不同，我们需要重写一些代码以允许正方形正确存在。

class Square(Rectangle):
def __init__(self, width):
self._width = width
self._height = width

def get\_width(self):
    return self._width

def set\_width(self, width):
    self._width = width
    self._height = width

def get\_height(self):
    return self._height

def set\_height(self, height):
    self._height = height
    self._width = height

这看起来不错，但最终正方形不是矩形，因此我们添加了代码来强制这种情况起作用。


我读过的一个很好的类比是考虑类代表的鸭子和橡皮鸭。尽管可以将 Duck 类扩展为 Rubber Duck 类，但我们需要重写许多 Duck 功能以适应 Rubber Duck。例如，鸭子嘎嘎叫，但橡皮鸭不叫（好吧，也许它会吱吱叫），鸭子是活的，但橡皮鸭不是。


覆盖类中的大量代码以适应特定情况可能会导致维护问题。您为覆盖特定条件而添加的代码越多，您的代码就会变得越脆弱。


矩形与正方形情况的一种解决方案是创建一个名为Quadrilateral的接口，并在单独的Rectangle和Square 类中实现它。在这种情况下，我们允许类负责它们自己的数据，但强制要求某些方法足迹可用。

class QuadrilateralMeta(type):
def __instancecheck__(self, instance):
return self.subclasscheck(type(instance))

def \_\_subclasscheck\_\_(self, subclass):
    return (hasattr(subclass, 'area') and callable(subclass.area)) \
      and (hasattr(subclass, 'get\_height') and callable(subclass.get_height)) \
      and (hasattr(subclass, 'get\_width') and callable(subclass.get_width)) \

class QuadrilateralInterface(metaclass=QuadrilateralMeta):
pass

class Rectangle(QuadrilateralInterface):
pass

class Square(QuadrilateralInterface):
pass

这里的底线是，如果你发现你覆盖了很多代码，那么你的架构可能是错误的，你应该考虑 Liskov 替换原则。


### 接口隔离原则


这表明许多特定于客户端的接口优于一个通用接口。换句话说，不应强制类实现它们不使用的接口。


让我们以Worker接口为例。这定义了几种不同的方法，可以应用于典型开发机构的工作人员。

class WorkerMeta(type):
def __instancecheck__(self, instance):
return self.subclasscheck(type(instance))

def \_\_subclasscheck\_\_(self, subclass):
    return (hasattr(subclass, 'take\_break') and callable(subclass.take_break)) \
      and (hasattr(subclass, 'write\_code') and callable(subclass.write_code)) \
      and (hasattr(subclass, 'call\_client') and callable(subclass.call_client)) \
      and (hasattr(subclass, 'get\_paid') and callable(subclass.get_paid))

class WorkerInterface(metaclass=WorkerMeta):
pass

问题是因为这个接口太通用了，我们不得不在实现这个接口的类中创建方法来适应这个接口。


例如，如果我们创建一个Manager类，那么我们将被迫实现一个 write\_code() 方法，因为这是接口所需要的。因为经理通常不编写代码，所以我们实际上无法在此方法中执行任何操作，因此我们只返回 false。

class Manager(WorkerInterface):
def write_code(self):
pass

此外，如果我们有一个实现Worker的Developer类，那么我们将被迫实现一个 call\_client() 方法，因为这是接口所需要的。

class Developer(WorkerInterface):
def call_client(self):
pass

拥有一个臃肿的接口意味着必须实现什么都不做的方法。


正确的解决方案是将我们的界面拆分成单独的部分，每个部分处理特定的功能。在这里，我们从我们的通用Worker接口中分离出Coder和ClientFacer接口。

class WorkerMeta(type):
def __instancecheck__(self, instance):
return self.subclasscheck(type(instance))

def \_\_subclasscheck\_\_(self, subclass):
    return (hasattr(subclass, 'take\_break') and callable(subclass.take_break)) \
      and (hasattr(subclass, 'get\_paid') and callable(subclass.get_paid))

class WorkerInterface(metaclass=WorkerMeta):
pass

class ClientFacerMeta(type):
def __instancecheck__(self, instance):
return self.subclasscheck(type(instance))

def \_\_subclasscheck\_\_(self, subclass):
    return (hasattr(subclass, 'call\_client') and callable(subclass.call_client))

class ClientFacerInterface(metaclass=ClientFacerMeta):
pass

class CoderMeta(type):
def __instancecheck__(self, instance):
return self.subclasscheck(type(instance))

def \_\_subclasscheck\_\_(self, subclass):
    return (hasattr(subclass, 'write\_code') and callable(subclass.write_code))

class CoderInterface(metaclass=CoderMeta):
pass

有了这个，我们就可以实现我们的子类，而不必编写我们不需要的代码。所以我们的Developer和Manager类看起来像这样。

class Manager(WorkerInterface, ClientFacerInterface):
pass

class Developer(WorkerInterface, CoderInterface):
pass

拥有许多特定接口意味着我们不必编写代码来支持接口。


### 依赖倒置原则


也许是最简单的原则，它指出类应该依赖于抽象，而不是具体化。本质上，不依赖于具体类，依赖于接口。


以使用MySqlConnection类从数据库加载页面的PageLoader类为例，我们可以创建这些类，以便将连接类传递给PageLoader类的构造函数。

class MySqlConnection():
def connect(self):
pass

class PageLoader():
def __init__(self, mysql_connection: MySqlConnection):
self._mysql_connection = mysql_connection

这种结构意味着我们基本上只能在数据库层使用 MySQL。如果我们想将其换成不同的数据库适配器会怎样？我们可以扩展MySqlConnection类以创建到 Memcache 或其他东西的连接，但这会违反 Liskov 替换原则。可能会使用备用数据库管理器来加载页面，因此我们需要找到一种方法来执行此操作。


这里的解决方案是创建一个名为DbConnectionInterface的接口，然后在MySqlConnection类中实现这个接口。然后，我们不再依赖传递给PageLoader类的MySqlConnection对象，而是依赖任何实现DbConnectionInterface接口的类。

class DbConnectionMeta(type):
def __instancecheck__(self, instance):
return self.subclasscheck(type(instance))

def \_\_subclasscheck\_\_(self, subclass):
    return (hasattr(subclass, 'connect') and callable(subclass.connect))

class DbConnectionInterface(metaclass=DbConnectionMeta):
pass

class MySqlConnection(DbConnectionInterface):
def connect(self):
pass

class PageLoader():
def __init__(self, db_connection: DbConnectionInterface):
self._db_connection = db_connection

有了这个，我们现在可以创建一个MemcacheConnection类，只要它实现了DbConnectionInterface，我们就可以在PageLoader类中使用它来加载页面。


这种方法还迫使我们以这样一种方式编写代码，以防止不关心它的类中的特定实现细节。因为我们已经将MySqlConnection类传递给了PageLoader类，所以我们不应该在PageLoader类 中编写 SQL 查询。这意味着当我们传入MemcacheConnection对象时，它的行为方式与任何其他类型的连接类相同。


当考虑接口而不是类时，它迫使我们将特定域代码移出我们的PageLoader类并移入MySqlConnection类。


### 如何发现它？


一个更大的问题可能是，如果您需要将 SOLID 原则应用于您的代码，或者您正在编写的代码不是 SOLID，您如何才能发现。


了解这些原则只是成功的一半，您还需要知道什么时候应该退后一步并考虑应用 SOLID 原则。我想出了一个快速列表，列出了您需要关注的“告诉”，表明您的代码可能需要重新编写。


您正在编写大量“if”语句来处理目标代码中的不同情况。  
 你写了很多代码，实际上并没有做任何事情只是为了满足界面设计。  
 你一直打开同一个类来更改代码。  
 您在与该类没有任何关系的类中编写代码。例如，将 SQL 查询放在数据库连接类之外的类中。


### 结论


SOLID 不是一种完美的方法，它可能会导致包含许多移动部件的复杂应用程序，并且偶尔会导致编写代码以备不时之需。使用 SOLID 意味着编写更多类并创建更多接口，但许多现代 IDE 将通过自动代码完成来解决该问题。


也就是说，它确实会迫使您分离关注点、考虑继承、防止重复代码并谨慎编写应用程序。毕竟，考虑对象如何在应用程序中组合在一起是面向对象代码的全部内容。


### ⭐️ 好书推荐


**《自学Python ——编程基础、科学计算及数据分析 第2版》**


![在这里插入图片描述](https://img-blog.csdnimg.cn/c67778f268d44ee2af97ea5b3b6bf27c.png)


**【内容简介】**



> 
> **本书是面向Python学习者和使用者的一本实用学习笔记，在前一版的基础之上进行了全面修订。适合刚接触Python的初学者以及希望使用Python处理和分析数据的读者阅读，也可作为学习和使用Python的工具书或参考资料使用。**
> 
> 


![img](https://img-blog.csdnimg.cn/img_convert/975501b565f2622aa7c3e63e0fb7ebda.png)
![img](https://img-blog.csdnimg.cn/img_convert/f53394c8c4962d6e5a146d5564f6907d.png)

**网上学习资料一大堆，但如果学到的知识不成体系，遇到问题时只是浅尝辄止，不再深入研究，那么很难做到真正的技术提升。**

**[需要这份系统化的资料的朋友，可以添加戳这里获取](https://bbs.csdn.net/topics/618658159)**


**一个人可以走的很快，但一群人才能走的更远！不论你是正从事IT行业的老鸟或是对IT行业感兴趣的新人，都欢迎加入我们的的圈子（技术交流、学习资源、职场吐槽、大厂内推、面试辅导），让我们一起学习成长！**

或参考资料使用。**
> 
> 


[外链图片转存中...(img-XUToUos0-1715817977167)]
[外链图片转存中...(img-DlPV9CGl-1715817977168)]

**网上学习资料一大堆，但如果学到的知识不成体系，遇到问题时只是浅尝辄止，不再深入研究，那么很难做到真正的技术提升。**

**[需要这份系统化的资料的朋友，可以添加戳这里获取](https://bbs.csdn.net/topics/618658159)**


**一个人可以走的很快，但一群人才能走的更远！不论你是正从事IT行业的老鸟或是对IT行业感兴趣的新人，都欢迎加入我们的的圈子（技术交流、学习资源、职场吐槽、大厂内推、面试辅导），让我们一起学习成长！**