- 个人网站:【海拥】【摸鱼游戏】【神级源码资源网】
- 前端学习课程:【28个案例趣学前端】【400个JS面试题】
- 想寻找共同学习交流、摸鱼划水的小伙伴,请点击【摸鱼学习交流群】
SOLID 是一组面向对象的设计原则,旨在使代码更易于维护和灵活。它们是由 Robert “Uncle Bob” Martin 于 2000 年在他的论文 设计原则和设计模式中创造的。SOLID 原则适用于任何面向对象的语言,但在本文中我将重点关注它们在 Python 应用程序中的含义。
我最初以 PHP 为基础撰写有关 SOLID 原则的文章,但由于此处的课程可以轻松应用于任何面向对象的语言,我认为我会考虑使用 Python 重新编写它。如果您只熟悉 PHP 或 Python,那么这将是学习另一面的一个很好的学习资源。
在这里我们还应该注意,Python 并没有真正的接口系统,所以我使用元类来创建所需的情况。有关元类的更多说明,请参阅Python 中面向对象编程入门文章的基础知识中的接口部分。
SOLID 是一个首字母缩写词,代表以下内容:
- 单一职责原则
- 开放/封闭原则
- Liskov替代原则
- 接口隔离原则
- 依赖倒置原则
我们将依次解析它们。
单一职责原则
这表明一个类应该有单一的责任,但更重要的是,一个类应该只有一个改变的理由。
以名为Page的(简单)类为例。
import jsonclass Page(): def __init__(self, title): self._title = title def get_title(self): return self._title def set_title(self, title): self._title = title def get_page(self): return [self._title] def format_json(self): return json.dumps(self.get_page())
此类知道 title 属性并允许通过 get() 方法检索此 title 属性。我们还可以使用此类中名为 format_json() 的方法将页面作为 JSON 字符串返回。这似乎是个好主意,因为类负责自己的格式。
但是,如果我们想要更改 JSON 字符串的输出,或者向类中添加另一种类型的输出,会发生什么情况呢?我们需要更改类以添加另一个方法或更改现有方法以适应。这对于像这样简单的类来说很好,但如果它包含更多属性,那么更改格式将更加复杂。
一个更好的方法是修改Page类,这样它只知道数据是句柄。然后我们创建一个名为JsonPageFormatter的辅助类,用于将Page对象格式化为 JSON。
import jsonclass Page(): def __init__(self, title): self._title = title def get_title(self): return self._title def set_title(self, title): self._title = title def get_page(self): return [self._title]class JsonPageFormatter(): def format_json(page: Page): return json.dumps(page.get_page())
这样做意味着如果我们想创建一个 XML 格式,我们只需添加一个名为XmlPageFormatter的类并编写一些简单的代码来输出 XML。我们现在只有一个理由来更改Page类。
开闭原则
在开闭原则中,类应该 对扩展开放,对修改关闭。本质上意味着类应该被扩展以改变功能,而不是被改变成其他东西。
以下面两个类为例。
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 = heightclass Board(): @property def rectangles(self): return self._rectangles @rectangles.setter def rectangles(self, value): self._rectangles = value def calculateArea(self): area = 0 for item in self.rectangles: area += item.get_height() * item.get_width() return area
我们有一个包含矩形数据的Rectangle类,以及一个用作Rectangle对象集合的Board类。使用此设置,我们可以通过循环遍历rectangles集合属性中的项目并计算它们的面积来轻松找出板的面积。
此设置的问题在于我们受到可以传递给Board类的对象类型的限制。例如,如果我们想将一个Circle对象传递给Board类,我们需要编写条件语句和代码来检测和计算Board的面积。
解决这个问题的正确方法是将面积计算代码移到形状类中,并让所有形状类都扩展一个Shape接口。我们现在可以创建一个Rectangle和Circle形状类,它们将在被要求时计算它们的面积。
import mathclass ShapeMeta(type): def __instancecheck__(self, instance): return self.__subclasscheck__(type(instance)) def __subclasscheck__(self, subclass): return (hasattr(subclass, 'area') and callable(subclass.area))class ShapeInterface(metaclass=ShapeMeta): passclass Rectangle(ShapeInterface): 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()class Circle(ShapeInterface): def __init__(self, radius): self._radius = radius def get_radius(self): return self._radius def set_radius(self, radius): self._radius = radius def area(self): return self.get_radius() * self.get_radius() * math.pi
现在 可以重新设计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): passclass Rectangle(QuadrilateralInterface): passclass 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): passclass 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): passclass 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): passclass Developer(WorkerInterface, CoderInterface): pass
拥有许多特定接口意味着我们不必编写代码来支持接口。
依赖倒置原则
也许是最简单的原则,它指出类应该依赖于抽象,而不是具体化。本质上,不依赖于具体类,依赖于接口。
以使用MySqlConnection类从数据库加载页面的PageLoader类为例,我们可以创建这些类,以便将连接类传递给PageLoader类的构造函数。
class MySqlConnection(): def connect(self): passclass 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): passclass MySqlConnection(DbConnectionInterface): def connect(self): passclass 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版》
【内容简介】
本书是面向Python学习者和使用者的一本实用学习笔记,在前一版的基础之上进行了全面修订。适合刚接触Python的初学者以及希望使用Python处理和分析数据的读者阅读,也可作为学习和使用Python的工具书或参考资料使用。
京东自营购买链接:《自学Python ——编程基础、科学计算及数据分析 第2版》