ios重用机制_iOS上的通用重用原则

ios重用机制

We as developers are usually advised to search in the Open Source Community before adding new functionality. The odds are that most likely some other engineer faced the same problem and, in a remarkable act of charity, published their solution so we can also reuse it. Or perhaps we are that caring developer, who content with their work, decided that more people should benefit from it.

通常建议我们作为开发人员在添加新功能之前在开源社区中进行搜索。 很有可能其他工程师也面临同样的问题，并以一种非凡的慈善行为发表了他们的解决方案，以便我们也可以重用它。 或者，也许我们就是那个对工作满意的开发人员，决定让更多的人从中受益。

In any case, we should make sure that the component will adhere to the Common Reuse Principle (CRP): Don’t force users of a component to depend on things they don’t need. Oh ok, could you elaborate on that? Yeah, sure.

无论如何，我们都应确保该组件遵守通用重用原则(CRP)： 不要强迫组件的用户依赖于他们不需要的东西。 哦，好，您能详细说明一下吗？ 当然可以。

深度CRP (The CRP in Depth)

Photo by Jack B on Unsplash

杰克B在 Unsplash上的 照片

Whenever we have a use case, some set of classes collaborate amongst themselves to achieve their goal. A very common case is a Factory class and the types it generates, they are tightly coupled. Being so dependant on each other, the CRP states that they belong together in the same component.

每当我们有一个用例时，一些类之间就会相互协作以实现其目标。 一个非常常见的情况是Factory类及其生成的类型，它们紧密耦合。 CRP相互依赖，因此声明它们在同一组件中属于同一类。

Classes and modules that tend to be reused together belong in the same component.

倾向于一起重用的类和模块属于同一组件 。

Until here everything is fine, if this is the case of our analysed component we should not worry. The issue arises when we flip the coin and state the principle inversely; it provides us even more valuable information. It tells us which classes should not be kept together in a component: those that are not reused together.

到这里为止一切都很好，如果是我们分析过的组件，那就不用担心。 当我们掷硬币并反陈述原理时，就会出现问题。 它为我们提供了更多有价值的信息。 它告诉我们哪些类不应在组件中保留在一起：哪些类不能一起重用。

为什么不？ (Why Not?)

Because once we are using another component, we have a dependency for the whole component, for all the classes. Yeah, maybe we are only using one class of it, but still we are going to suffer all the inconvenience of a big dependency:

因为一旦使用了另一个组件，就对整个组件，所有类都有了依赖。 是的，也许我们只使用其中的一类，但是仍然会遭受很大依赖的所有不便：

• Every time that component changes we will need corresponding changes.
  每次组件更改时，我们都需要进行相应的更改。

• Or maybe they keep a clean interface so no changes in our side are required, but for sure we are going to have to compile the whole component again and again.

  或者，也许他们保持界面整洁，因此不需要在我们这方面进行任何更改，但是可以肯定的是，我们将不得不一次又一次地编译整个组件 。

The latter was the major drawback for us at WELT, especially when compiling on a slower machine, as the virtual ones assigned in a remote based CI solution.

后者是WELT的主要缺点，尤其是在较慢的计算机上编译时，因为虚拟机是在基于远程CI的解决方案中分配的。

一个例子 (An Example)

In WELT News we convert the HTML text into NSAttributedString to be displayed in our Articles Views. At first we tried the built-in framework to carry out this operation, having something like this:

在WELT News中，我们将HTML文本转换为NSAttributedString，以显示在文章视图中。 首先，我们尝试使用内置框架来执行此操作，其内容如下：

And it worked fine, but unfortunately very slow. Moreover, since the execution should be performed on the main thread, the UI was blocked until it finished, which was not acceptable for our stakeholders.

它工作正常，但不幸的是非常缓慢。 此外，由于应该在主线程上执行，因此UI一直被阻塞直到完成为止，这对于我们的涉众来说是不可接受的。

Luckily we got to know DTCoreText, a project that duplicates the Apple method, only doing it 18x times faster. We were very happy with that approach, so we decided to integrate it in our library.

幸运的是，我们认识了DTCoreText ，它是一个复制Apple方法的项目，执行速度仅快18倍 。 我们对该方法感到非常满意，因此我们决定将其集成到我们的库中。

The dilemma popped up when realizing that DTCoreText uses DTFoundation behind the scenes, a collection of utility methods and category extensions that Cocoanetics is standardizing on.

当意识到DTCoreText在后台使用DTFoundation时，出现了两难境地，这是Cocoanetics 标准化 的实用程序方法和类别扩展的集合。

So DTFoundation includes a lot of classes that are not related to our use case. Just to render our text faster we have to compile classes related to a large variety of topics such as SQLite, ZIP files, AWS …

因此，DTFoundation包含许多与我们的用例无关的类。 为了更快地渲染文本，我们必须编译与各种主题(例如SQLite，ZIP文件，AWS等)相关的类。

We depend on tons of things we do not need

我们依靠大量我们不需要的东西

Even if these components might eventually be useful to us, we are currently not using them, and therefore shouldn’t have to include them. We should not compile them in our project, as it will slow build times.

即使这些组件最终可能对我们有用，我们目前也没有使用它们，因此不必包含它们。 我们不应该在我们的项目中编译它们，因为这会减慢构建时间。

We might argue that these frameworks will only be built once, since every dependency manager and CI will enable us to cache and reuse them. Even with that, it is worth to decrease the compilation times for that first time, or cut down the size of the cache. On top of that, if the component is updated because of an unrelated change and we are always up to date with our dependencies, it will compile every time it needs to update.

我们可能会争辩说，这些框架将只构建一次，因为每个依赖关系管理器和CI都将使我们能够缓存和重用它们。 即使这样，还是值得减少第一次的编译时间，或者减少缓存的大小。 最重要的是，如果组件是由于不相关的更改而更新的，并且我们始终保持最新状态，则每次需要更新时它将进行编译。

解决方案 (The Solution)

Photo by Olav Ahrens Røtne on Unsplash

Olav AhrensRøtne在 Unsplash上 拍摄的照片

The CRP tells us that when we depend on a component, we should aspire to depend on every class in that component. As Robert C Martin points in Clean Architecture, we want to make sure that the classes we put in a component are inseparable- that it is impossible to depend on some and not on the others.

CRP告诉我们，当我们依赖某个组件时，我们应该渴望依赖于该组件中的每个类。 正如Robert C Martin在Clean Architecture中指出的那样， 我们要确保放置在组件中的类是不可分割的-不可能依赖某些而不是其他。

In other words, classes that are not tightly bound to each other should not be in the same component. That goes against the Umbrella Toolset libraries that contains big collections of utilities applied to a big number of different topics.

换句话说，彼此之间没有紧密绑定的类不应位于同一组件中。 这与Umbrella Toolset库背道而驰，该库包含适用于大量不同主题的大量实用程序。

To avoid the caveats mentioned above, we plan to extract the classes reused together to achieve the use case of HTML conversion into NSAttributedString into their own component. This way we will only have to compile the necessary number of classes reused together to achieve our goal.

为了避免上述警告，我们计划提取一起重用的类，以实现将HTML转换为NSAttributedString到其自己的组件中的用例。 这样， 我们只需要编译必要数量的类就可以重用在一起，以实现我们的目标。

它的第一个堂兄，ISP (Its first cousin, the ISP)

This probably all sounds very familiar to you. Most likely it reminds you of the Interface Segregation Principle, the I from SOLID:

这听起来对您来说很熟悉。 最有可能使您想起接口隔离原则，即SOLID中的I ：

Clients should not be forced to depend upon interfaces that they do not use.

不应强迫客户端依赖于不使用的接口。

Indeed, the ISP advises us not to depend on classes that have methods we don’t use, the CRP advises us not to depend on components that have classes we don’t use. The foundation behind them is the same:

确实，ISP建议我们不要依赖具有未使用方法的类， CRP建议我们不要依赖具有未使用方法的组件 。 它们背后的基础是相同的：

不要依赖您不需要的东西！ (Don’t depend on things you don’t need!)

The Death of Socrates, Jacques-Louis David

苏格拉底之死，雅克·路易·大卫

We are usually told, don’t reinvent the wheel. And rightly so. If there is already a proven open source solution to our problem which is backed up by a large community of users, it would serve us well to use it.

通常被告知， 不要重蹈覆辙 。 是的。 如果已经有一个经过验证的开源解决方案，并且得到了广大用户的支持，那么使用它将会很好地为我们服务。

But before adding the dependency blindly to our codebase, we should stop and analyze the component, to make sure that we are not going to be dependant on things we do not need. This will give us time, and time is our most valuable asset.

但是在将依赖项盲目添加到我们的代码库之前，我们应该停止并分析该组件，以确保我们不会依赖于不需要的东西。 这将给我们时间，而时间是我们最宝贵的资产。

So, just as when Socrates strode through the city’s central marketplace and declared provocatively, “How many things I don’t need!”, we should, in our life as in our code, confidently assert:

因此，就像苏格拉底大步跨过城市的中央市场并挑衅地宣称：“我不需要多少东西！”时，我们应该像我们的守则中那样自信地断言：

Don’t depend on things you don’t need!

不要依赖您不需要的东西！

翻译自: https://medium.com/axel-springer-tech/the-common-reuse-principle-on-ios-f4b7b1b945a3

ios重用机制