将接口隔离原理应用于服务层接口

Question

以书作为类比，假设我有一个具有以下 API 的图书资源（还有更新和删除等，但为了简单起见，这里只显示两个）

GET /book/{id}
POST /book

这些 API 中的每一个都会调用其他 API 来获取结果，而不是典型的 CRUD数据库操作。并且基于需求/现有框架约束，有单独的两个控制器类GetBookController和CreateBookController。控制器负责处理请求和响应。所以实际的业务逻辑和检索/创建书籍都在服务层。

那么问题是，每个图书操作是否应该有一个单独的接口（GetBookService 和 CreateBookService），还是只有一个接口（BookService） >)?

基于接口隔离原则，该原则规定“客户端不应被迫依赖于他们不使用的接口”。这里的GetBookController类是客户端，它只需要查询书籍而不需要创建它，所以它只需要GetBookService。如果是使用BookService，则不使用createBook方法，这似乎违反了ISP原则。但是，如果使用单独的接口，则会导致创建许多接口和实现类。我是否误解了ISP的原理？

@Controller
public class GetBookController {
    
    @Autowired
    private GetBookService getBookService;
}

@Controller
public class CreateBookController {
    
    @Autowired
    private CreateBookService createBookService;
}

public interface GetBookService {
    Book getBook(long id);
}

public interface CreateBookService {
    Boolean createBook(Book request);
}

public interface BookService {
    Book getBook(long id);
    Boolean createBook(Book request);
}

Answer 1

因此，我通常对书籍这样的 CRUD 实体执行的操作是单个 BookControler。您不需要多个书籍控制器，因为它是一个控制器 - 它控制与书籍相关的事物。所以应该是一个类。

服务的逻辑又相同。一本图书服务接口就足够了。它处理书籍的需求并返回请求的结果。

所以，是的，如果为每个方法都制作一个接口，接口就会太多，随着项目规模的扩大，这并不容易处理。此外，它使得每个接口只做很少的事情（在某些情况下这是期望的，但不是这个）。

ISP 原理的一个很好的类比是：您不想让咖啡机需要实现如何打印纸张，而需要打印机来实现如何制作咖啡。但制作不同咖啡的咖啡机也在其范围之内。

 @Controller
 public class BookController {
     private final BookService bookService;

     @Autowired
      private BookController (BookService bookService) {
          this.bookService = bookService;
      }
  }
    
  public interface BookService {

       Book getBook(long id);
    
       Boolean createBook(Book request);
  }

例如，您可以使用构造函数中的自动装配，以便更轻松地进行模拟。

Answer 2

这将导致创建许多接口和实现类

是的，你是对的

接下来的问题是，每个图书操作是否应该有一个单独的接口（GetBookService 和 CreateBookService），还是只有一个接口（BookService）？

ISP 是如何使用接口的。因此，是否需要使用接口的其他方法或不依赖于超出您需要的内容。

使用 ISP 的 HDD 示例：

public interface IReadable
{
    string Read();
}

public interface IWriteable
{
    void Write();
}

public class HDD : IReadable, IWriteable
{
    public string Read() { }

    public void Write()  { }
}

通过为 Read() 和 Write() 方法创建一个接口，类将强制实现这两个方法。类中的方法。但有些类只想读取数据，其他类只想写入数据，有些类则两者兼而有之。例如，读卡器可能想要读取数据。因此在这种情况下最好创建单独的接口。

那么让我们看一下 CardReader 的另一个示例。 CardReader只读取数据，不写入数据。因此，如果我们继承一个带有 Read() 和 Write() 方法的接口，那么我们就会违反 ISP 原则。违反 ISP 的示例：

public interface IWriteReadable
{
    string Read();
    void Write();
}

public class CardReader : IWriteReadable
{
    // this is a necessary method
    public string Read() { }

    // here we are obligating to implement unnecessary method of interface
    public void Write() { }
}

因此，通过应用 ISP，您只将客户端类必需的方法放入接口中。如果您的类/客户端只想读取数据，那么您需要使用IReadable接口，而不是IReadableWriteable。

在我看来，就像回复建议的那样，最好为书籍创建一个控制器。如果这些方法有很多变体并且控制器变得非常大，那么为读取和创建操作使用单独的控制器可能是可以的。

Answer 3

您不应该设计bookService接口，就好像您知道它可能拥有的所有客户端一样。通常，应该只有一个BookService接口，其目的是提供对书籍的crud访问。

该规则的一个例外是，如果书籍服务支持不同的访问级别的不同客户端角色。如果这种情况，您可能会有一个仅提供R的BookReaderService，并且bookupdaterservice将其扩展并提供完整的crud。

现在，您可能需要编写您的客户端，以便它们不依赖他们不需要的操作（ISP）。在这种情况下，您将在客户端定义客户所需的接口，然后使用适配器根据适当的书籍服务来提供这些接口...但实际上在这种情况下是过分的。您的控制器已经已经适配器，因此添加另一个适配器层是多余的。

Answer 4

ISP 的原则目标是通过将软件拆分为多个独立的部分来减少所需更改的副作用和频率。

但问题是需要多小才能拆分软件组件。

在你的例子中，你过度应用了这个原则，例如假设你有一个类：

class Student {
String name;
Integer age;
ClassRoom classRoom;

.
.
.
setters ....
getters ....
}

并且一个开发人员认为最好将其分开，所以他最终为每个setter和getter创建单独的类（这显然是不必要的），

这里与根据您的情况，最好有一个 BookController 和一个 BookService 来涵盖所有必需的操作（创建、获取、更新、删除）。

除非您有不同类型的 BookService （例如 ElectronicBook 、 PaperBook ），否则您可以有不同的 BookService 接口实现。