时间戳

首页 > 解决方案 > 接口如何打破类的依赖关系？

java - 接口如何打破类的依赖关系？

问题描述

我正在阅读 Clean Architecture - Bob Martin。他谈到了通过接口打破依赖关系。例如。B类使用A类。因此，B类依赖于A类（B--->A）。我们可以添加一个接口，让 B 依赖于接口，也让 A 依赖于接口（A--->I<----B）。

我不明白的是，如果类 A 具有在 B 需要的函数中使用的私有成员变量。我不必在 B 中重写与 A 相同的代码吗？另外，这不只是重复的代码吗？

这是一个例子。

class Car {
    private String color;
    private Integer numberOfTires;
    [...]
    public void printCar()
    {
        System.out.print("Color: " + color);
        System.out.print("Number of tires: " + numberOfTires);
    }
}

class Inventory{
    private Car car;
    private Truck truck; // left out for brevity
    public void printCar()
    {
        car.printCar();
    }

    public void printTruck()
    {
        truck.printTruck();
    }
}

我看不出接口如何帮助解决这种依赖关系。

标签： javadesign-patternsinterface

解决方案

@Kaue Silveira 提供了一个很好的例子，但没有提到另一个重要方面。

一般来说，接口的重点不是减少类。我想您熟悉耦合和内聚这两个术语。您总是希望拥有松散耦合且高度内聚的代码。意思是，您不希望类相互依赖（耦合），而是以继承、多态等形式共享一些逻辑。这些概念是高质量面向对象设计的一些基本支柱。如果您不熟悉这些主题，绝对值得一读。

回到这个问题，如果你正在处理一个有很多特殊情况的复杂逻辑，你肯定通常会有一些重复。但是，此类问题与其他设计模式和原则更相关，这些设计模式和原则仅旨在遵守 DRY 原则并以概括解决方案的方式解决情况。

接口背后的主要思想是为有助于对象操作一致性的类设置逻辑结构。

想象一个证券交易所系统。此接口有一个名为 execute 的方法，它将执行一些应用程序逻辑。

public interface Order{
     void execute();
}

可能实现此接口的其他类可能是 Buy 和 Sell。它看起来像这样：

public class Buy implement Order{
     @Override
     public void execute(){
          //TODO: Some logic
     }
}

现在 Buy 和 Sell 都有相似的代码，甚至可能有一些重复，但更重要的是，当它们实现相同的接口时，您可以以统一的方式处理它们。您可以有一些 StockManager 类，将 Buy 订单和 Sell 订单放在 some 中Quee<Order>。由此您可以得出结论，如果使用这样的 Quee，您将能够在execute()Order 接口的任何实现上调用方法。

在前面的论点之上，通过使用接口和 Spring 等一些框架，您可以进行自动装配。这显着减少了对较低级别实现类的依赖，使您可以在不影响顶级处理程序的情况下更改低级别类。这种类型的应用程序设计是 SOA（面向服务的架构）中的常见做法。

推荐阅读