Trong hầu hết các ví dụ về kiến trúc sạch (mặc dù hầu hết là các dự án Android) tôi đã nhận thấy rằng các lớp trường hợp sử dụng / tương tác (các đơn vị đóng gói một tính năng) thường chia sẻ lớp / giao diện cơ sở, như ở đây hoặc ở đây . Những người khác thì không ( như ở đây hoặc ở đây ), thay vào đó cho phép người tương tác chấp nhận một số tham số sau đó được sử dụng để thực thi một số logic.

Là một trong những cách tiếp cận tốt hơn so với phương pháp khác? Tôi đặc biệt quan tâm đến cách tiếp cận không tham số xử lý các trường hợp sử dụng cho một cái gì đó yêu cầu đầu vào của người dùng chẳng hạn - giả sử chúng tôi muốn cho phép người dùng chỉnh sửa một thực thể và chuyển nó đến máy chủ. Chúng ta có thể đưa cùng một thực thể vào trường hợp sử dụng và bất kỳ ai gọi nó, nhưng sau đó nó sẽ phải có thể thay đổi, để những thay đổi được phản ánh ở cả hai nơi. Nhưng sau đó, chúng tôi không thể tạo các mô hình bất biến, điều mà chúng tôi có thể không muốn (vì các vấn đề luồng, v.v.). Làm thế nào để xử lý trường hợp như vậy?

Xin lỗi nếu tôi sử dụng thuật ngữ usecase / tương tác không chính xác, nhưng đây là cách chúng được sử dụng trên đất Android, điều này có thể thừa nhận một chút về các mẫu thiết kế

Hãy để tôi nhắc lại những gì bạn đang nói để chắc chắn rằng chúng ta đang ở trên cùng một trang.

Trong kiến ​​trúc sạch

Trường hợp A

các lớp use-case / tương tác thường chia sẻ lớp / giao diện cơ sở, như ở đây

  public abstract class UseCase {

  private final ThreadExecutor threadExecutor;
  private final PostExecutionThread postExecutionThread;

  private Subscription subscription = Subscriptions.empty();

  protected UseCase(ThreadExecutor threadExecutor,
      PostExecutionThread postExecutionThread) {
    this.threadExecutor = threadExecutor;
    this.postExecutionThread = postExecutionThread;
  }

  /**
   * Builds an {@link rx.Observable} which will be used when executing the current {@link UseCase}.
   */
  protected abstract Observable buildUseCaseObservable();

  /**
   * Executes the current use case.
   *
   * @param UseCaseSubscriber The guy who will be listen to the observable build
   * with {@link #buildUseCaseObservable()}.
   */
  @SuppressWarnings("unchecked")
  public void execute(Subscriber UseCaseSubscriber) {
    this.subscription = this.buildUseCaseObservable()
        .subscribeOn(Schedulers.from(threadExecutor))
        .observeOn(postExecutionThread.getScheduler())
        .subscribe(UseCaseSubscriber);
  }

  /**
   * Unsubscribes from current {@link rx.Subscription}.
   */
  public void unsubscribe() {
    if (!subscription.isUnsubscribed()) {
      subscription.unsubscribe();
    }
  }
}

và ở đây

package cat.ppicas.framework.task;

public interface Task<R, E extends Exception> {

    TaskResult<R, E> execute();

}

Trường hợp B

Những người khác thì không, và thay vào đó cho phép người tương tác chấp nhận một số tham số sau đó được sử dụng để thực thi một số logic.

thích ở đây

package pl.charmas.shoppinglist.domain.usecase;

public interface UseCase<Result, Argument> {
  Result execute(Argument arg) throws Exception;
}

hoặc ở đây

AbstractInteractor.java
GetMarvelCharactersLimit.java
GetMarvelCharactersLimitImp.java
GetMarvelCharactersPaginated.java
GetMarvelCharactersPaginatedImp.java

Dừng lại

Cả hai đều đúng.

Chia sẻ một giao diện hoặc lớp cơ sở là một phần của kế thừa.

Chấp nhận các tham số để bạn có thể thực thi logic thông qua chúng là một phần của thành phần.

Là một trong những cách tiếp cận tốt hơn so với phương pháp khác?

Cả hai đều giỏi hơn những gì họ giỏi. Mặc dù một nguyên tắc thiết kế phổ biến nêu rõ, "ủng hộ thành phần hơn thừa kế" .

Nếu tôi hiểu, bạn đang thấy cách bố cục và kế thừa có thể cho phép đa hình và bây giờ bạn đã thấy nó, bạn đang vật lộn để lựa chọn giữa chúng. Nói điều này bằng ngôn ngữ mẫu: bạn có thể sử dụng mẫu mẫu hoặc mẫu chiến lược để có được tính đa hình.

Kế thừa cung cấp cho bạn đa hình trên chính nó. Do đó, ít gõ bàn phím. Thành phần yêu cầu bạn thêm ủy quyền để hiển thị và kết nối giao diện với tham số. Điều đó có nghĩa là gõ nhiều hơn. Nhưng thành phần không bị ràng buộc tĩnh nên nó rất linh hoạt và có thể kiểm tra được.

Có nên sử dụng executephương thức case / tương tác chấp nhận tham số?

Hãy nhớ rằng phương pháp này x.y()và chức năng y(x)này về cơ bản là giống nhau. Một execute() phương thức luôn nhận được ít nhất một tham số.

Tôi đặc biệt quan tâm đến cách tiếp cận không tham số xử lý các trường hợp sử dụng cho một cái gì đó yêu cầu đầu vào của người dùng chẳng hạn - giả sử chúng tôi muốn cho phép người dùng chỉnh sửa một thực thể và chuyển nó đến máy chủ. Chúng ta có thể đưa cùng một thực thể vào trường hợp sử dụng và bất kỳ ai gọi nó, nhưng sau đó nó sẽ phải có thể thay đổi, để những thay đổi được phản ánh ở cả hai nơi. Nhưng sau đó, chúng tôi không thể tạo các mô hình bất biến, điều mà chúng tôi có thể không muốn (vì các vấn đề luồng, v.v.). Làm thế nào để xử lý trường hợp như vậy?

Chà, bây giờ chúng ta đang nói về các thực thể, không sử dụng các trường hợp, cũng không phải đa hình.

Một thực thể có ID. Thật tốt khi làm cho một thực thể bất biến. Tại sao bạn muốn một người dùng chỉnh sửa một cái gì đó bất biến? Tại sao bạn muốn thông tin đó tồn tại ở hai nơi? Nếu có, nơi nào biết rõ nhất?

Không, tốt hơn để cho người dùng xây dựng một cái gì đó mới. Nếu nó phải có ID thì nó sẽ có một ID duy nhất mới. Nếu không, nó là một đối tượng giá trị. Nếu có một cái gì đó khác với ID có sẵn mà thông tin này phải được liên kết với sau đó xây dựng một hiệp hội mới. Đừng chọc vào những thực thể bất biến.

Hoàn toàn có thể mô hình hóa một thế giới đang thay đổi mà không cần cập nhật các thực thể của bạn, miễn là bạn có không gian để tiếp tục tạo ra những thứ đại diện cho những gì mới.