接口注入实现编码设计模式

问题描述 投票:0回答:1

我正在使用接口依赖注入,但正在考虑如果一个接口发生任何变化,我如何使其可扩展。例如:

function updateStatistics(Interface myInterface)
{ 
    myInterface->prepareStatistics;
    myInterface->syncStatistics;
    myInterface->doSomething;
    myInterface->doSomething2;
    ...
}

假设只有一个接口需要实现像这样的中间函数

 function updateStatistics(Interface myInterface)
 { 
     myInterface->prepareStatistics;
     // Do function for only certain implementations
     myInterface->syncStatistics;
    myInterface->doSomething;
    myInterface->doSomething2;
    ...
 }

继续这件事的正确方法是什么?我遇到过很多解决方案

  1. 在接口中创建并调用一个新的抽象方法,但在不需要的地方将主体留空。然而,这打破了 OOP 中的抽象概念,因为如果我有 10 个实现,新工程师将不知道方法体在某些地方留空。
  2. 创建另一个接口,需要它的人应该实现它。我可以检查注入的接口是否包含额外的接口,然后调用这些函数。这是我最喜欢的解决方案,但它可能会因为 if 语句而使我的函数变得臃肿。
    function updateStatistics(Interface myInterface)
    { 
        myInterface->prepareStatistics;

        if (myInterface instanceof extensionInterface) {
            // Do function for only certain implementations
        }
        myInterface->syncStatistics;
        ...
    }
  1. updateStatistics
    函数分解为它自己的接口方法。但这段代码的主要部分将主要重复,我更喜欢一个事实来源。

我想知道正确的 OOP 方法是什么,而不是一个 hacky 解决方案。

oop design-patterns dependency-injection interface
1个回答
0
投票

假设只有一个接口需要实现像这样的中间函数

为什么会这样呢?接口永远“不需要”来实现任何东西。 接口不实现行为; 通过实现接口来实现。 这可能会让您觉得语义挑剔,但我强调它是因为这是 OP 中的几个短语之一,这些短语似乎暗示接口是由实现细节驱动的。

但是,如果接口仅反映其实现类的实现细节,那么为什么还要有接口呢?事实上,这意味着当您更改实现时,您可能需要更改接口,从而破坏客户端代码。

相反,

依赖倒置原则

提出了相反的建议:

抽象不应依赖于细节。细节应该取决于抽象。

- Robert C. Martin,

C# 中的敏捷原则、模式和实践

,第 1 章11

不要从实现细节中提取接口定义,而是反转设计的所有权,以便

客户端[...]拥有抽象接口

- Robert C. Martin,

C# 中的敏捷原则、模式和实践

,第 1 章11

找出客户端代码
需要

,并围绕这些需求设计界面。

我可以检查注入的接口是否包含额外的接口,然后调用这些函数。这是我最喜欢的解决方案,但它可能会因为 if 语句而使我的函数变得臃肿。

如果执行运行时类型测试,就破坏了多态性,而这正是接口的全部要点。这可能会导致“霰弹枪手术”,因为您必须在使用相关接口的每个地方重复相同的流量控制结构。
重构

认为这是一种代码味道。 不幸的是,我不能告诉你该怎么做,因为这样一个SOLID练习的重点是从客户端代码需要什么开始,而OP没有描述这一点。

© www.soinside.com 2019 - 2024. All rights reserved.