面向协议的Swift是否比面向对象的Swift更好？

面向协议的编程是什么意思，为什么它比OOP更好？

“像我五岁一样解释”-洗衣服务示例

首先，提供的示例非常容易理解。 我强烈建议您跳过阅读评论者写的内容。

主题是“洗衣服务”。 假设有一个Laundry对象，其中封装了某些与洗衣相关的功能……“请给我洗衣服”-“好，这是您的衣服！”。 您作为客户只需说“请洗钱！”即可与Laundry互动。 Laundry对象开始工作并执行其工作，其范围可能从简单到令人难以置信的复杂–美丽之处在于，作为客户，就像需要洗衣服的人一样，您不在乎。 只要洗完衣服就可以退回衣服，生活就很棒！

面向对象的“问题”

在构建软件时，我们是在使用其他人构建的代码，还是创建供他人使用的代码，不是吗？ 我们正在使用的代码“挂钩”到其他开发人员设计并提供给我们的东西，或者我们正在创建其他代码将“挂钩”并与之交互的代码，即使“其他代码”是由我们在自己的应用程序中。

在成为代码的客户和创建者时，我们会同时戴上两顶帽子。

但是，如果我们将Laundry对象作为开发人员/创建者 ，而不是作为客户端 （即需要洗衣服的人）来工作，该怎么办？ 如果我们作为开发人员将一个Laundry对象交给了一个库，并且想要自定义它的行为，那么……可能会提高launderClothes()的性能，或者重写它的实现以使用一些令人惊奇的新洗衣服务。

我们这样做的方法是创建一个子类 。 评论者说，这是具有对象定向的牛肉：

[Object Orientation]通过继承来公开状态和内部，从而鼓励“封装复杂性”。

解说：软件具有天生的复杂性。 对象是封装这种复杂性的“事物”。 但是，他们以某种方式做到这一点：他们公开了某些状态和功能。 这些关于复杂性的抽象通过系统传播和定制的方式就是通过称为继承的机制。

但是评论者称这种方法是“麻烦的”。 为什么？ 好…

“我可能不想知道我的干洗是如何完成的，但是如果我想设计一条从脏衣服到干净衣服的更好方法，我就必须知道所执行步骤的每一个最后细节，这样我才能尝试在我的子类中完善它们。”

因此，评论者从开发人员/创建者的角度出发。 需要指出的是，要真正能够改善子类中的性能或优化算法，我们必须要知道在超类中执行的步骤的每个细节。 我们并非总是可以发现超类实现来改进它的情况。

转向协议方向

那么…协议方向？ 如果更好，那会更好吗？

我喜欢评论者以洗衣服务的面向对象示例为例，并从协议而非对象的角度出发细化了细微差别。 真。 看一看。

我们看到的主要区别是，与其拥有一个Laundry对象而不是一个以自己的特定方式进行Laundry对象，而是发生了转变：我们开始着手描述完成洗衣的方式 。

如果我想由一个特定的人以一种特定的方式来完成洗衣， 那么我会去面向对象的，而不再关心事情如何完成。 但是，如果我想概括一下洗衣服的方法 ，则需要以协议为导向，并不再关心其他所有事情。

在协议定向中，唯一重要的是接口 ……客户端将与之交互的事物。 尽最大可能通过一个协议来描述它，然后让其他事情出现并担心该如何做 。

最后，需要洗衣服的人唯一需要知道的是他们可以使用哪些界面来完成他们需要完成的洗涤。

能够坐下来思考一下，如果您从图片中删除了状态和继承，并且只考虑了与该特定任务的最低要求接口，将会看起来如何，这是一种更强大，更简单的编程方法，使重用比OO曾经做到过。

外卖

对我来说，这个关于Protocol Orientation的要点是：Protocols是泛化的 。 它们是关于界面的 。 它是关于思维方式和焦点（ 方向 ）的思考方式，以思考做某些事情的方式 ，并以Swift中的Type形式清楚地描述它们。

一旦描述了做某事的方法 ，其他事物（具体的Types ）就会出现并以无限多种方式实现它们。