怎么实现接口解耦_将接口与实现解耦-使用分离的接口

怎么实现接口解耦

If you’ve ever faced the same dilemma, surely you’ll grasp the sense of the following description: Cohesion and Decoupling, two seemingly naïve yet fundamental OOP cornerstones responsible for the incessant drumming that crushes the minds of most software developers, often crossing the boundary of what’s a tangible goal into utopia, away from the pragmatism and reality.

如果您曾经遇到过同样的难题，那么您肯定会掌握以下描述的含义： 凝聚力和解耦性 ，这两个看似幼稚却基本的OOP基石，不断的敲击打动了大多数软件开发人员的头脑，经常跨越乌托邦的切实目标的边界，脱离了实用主义和现实。

I don’t want to sound excessively ominous, but it’s fair to admit that designing cohesive, loosely-coupled systems is anything but a simple experience. In most cases, achieving such pristine features requires a lot of planning at the initial stages and going through the proper refactoring cycles later on as the system evolve and grow over time. Despite this, the OOP paradigm per se provides a set of well-trusted methodologies and principles right out of the box that together facilitate the implementation of cohesive, highly-decoupled components, even if they do have to be eventually refactored during their respective life cycles.

我不想听起来过于不祥，但可以公平地承认，设计具有凝聚力的，松耦合的系统绝非简单的体验。 在大多数情况下，要实现这种原始功能，就需要在初始阶段进行大量规划，并在以后随着系统的发展和发展而经历适当的重构周期。 尽管如此，OOP范本本身就提供了一组值得信赖的方法和原理，即使它们确实必须在各自的生命周期中最终进行重构，也可以共同促进内聚的，高度分离的组件的实现。 。

Consider, for instance, the use of a few segregated interfaces along with namespaced classes. When put to work in sync, they help wire up together components that are semantically related to each other, therefore increasing the overall level of cohesion exposed by a system. On the flip side, the definition of the interfaces themselves, either in the form of interface constructs or virtual/abstract classes, makes concrete implementations dependent upon abstractions, hence promoting the decoupling of components in such a way that they can be “rewired” differently at runtime, usually by means of Dependency Injection. When analyzed from a bird’s eye view, it becomes clear that the combined forces of good OOP practices and the proper mixture of design patterns are in most cases an effective solution that allows us to achieve a decent level of Cohesion and Decoupling.

例如，考虑使用几个分离的接口以及命名空间类。 当它们同步工作时，它们有助于将彼此在语义上相关的组件连接在一起，从而提高了系统所展现的整体凝聚力。 另一方面，接口本身的定义(以接口构造形式或虚拟/抽象类的形式)使具体实现依赖于抽象，因此促进了组件的解耦，从而可以以不同的方式“重新连接”组件在运行时，通常是通过依赖注入 。 从鸟瞰的角度来看，很明显，良好的面向对象操作规范和设计模式的适当结合在大多数情况下是一种有效的解决方案，可以使我们达到不错的凝聚力和去耦性。

Still, issues may arise when it’s necessary to “redefine” explicitly the way that one component, or even an entire layer, in a multi-tiered design must interplay with others. In a traditional system design, the dependencies between its decoupled components is defined through the respective interfaces, which are usually placed in the same component housing the concrete implementations. There might be a few particular situations where the dependencies must be reversed, in response to specific requirements. In such a case, the inversion in question can be easily accomplished by dropping the interface into one component and the corresponding implementations into a different one.

但是，当有必要明确“重新定义”多层设计中的一个组件甚至整个层必须与其他组件相互作用的方式时，可能会出现问题。 在传统的系统设计中，其解耦组件之间的依赖关系是通过相应的接口定义的，这些接口通常放置在容纳具体实现的同一组件中。 在某些特定情况下，必须根据特定要求反转依赖关系。 在这种情况下，可以通过将接口放到一个组件中，并将相应的实现放到另一个组件中来轻松实现所讨论的转换。

Considering that the concept may sound rather tangled and twisted at first, this shifting of protocols between components lives and breaths under the umbrella of a basic design pattern known as Separated Interface, which at least to some extent, goes hand in hand with the commandments of the Dependency Inversion Principle. Moreover, because of the pattern’s easy-going nature, it’s feasible to implement it in PHP without much fuss, so in this article I’ll show you how to exploit the benefits that separated interfaces bring to the table in a fairly approachable fashion.

考虑到概念一开始听起来可能很纠结和扭曲，所以在组件分离和生活之间的协议转移是在一种称为分离接口的基本设计模式的保护下进行的，该设计模式至少在某种程度上与依赖反转原理 。 此外，由于该模式易于使用，因此可以在PHP中实现而无需大惊小怪，因此，在本文中，我将向您展示如何利用分离的接口以相当容易的方式带