Các đối tượng mô hình có giao diện không?

Question

Tôi đang tạo mô hình miền trong hệ thống của mình. Khi thiết kế các đối tượng mô hình của tôi, tôi có nên tạo giao diện cho từng đối tượng thực thể không? Mọi người đã nói với tôi rằng tầng web của chúng tôi không nên quan tâm đến việc thực hiện một thực thể và chúng tôi có thể trao đổi các triển khai, nhưng tôi không chắc chắn điều đó sẽ xảy ra.

Ví dụ, nếu chúng ta có một lớp giáo viên duy trì một danh sách của sinh viên, phương pháp getStudents có thể thể là:

public List<Student> getStudents() { 
     return this.students; 
} 

hay này:

public List<Student> getStudents() { 
    return someExternalService.retrieveStudents(); 
} 

Tôi hiểu lợi ích này, nhưng thực hành chung là gì?

Answer 1

Trừ khi bạn có lý do chính đáng để nghĩ rằng bạn sẽ cần phải hoán đổi mô hình, tôi sẽ không lo lắng về nó. Dựa trên nguyên tắc YAGNI (You ain't gonna need it)

Answer 2

Không có dự án nào tôi từng thấy hoặc tham gia có giao diện cho thực thể tên miền.

Nhưng trong một trong những dự án của tôi, tôi có giao diện NamedEntity:

public interface NamedEntity { 
    int getId(); 
    String getName(); 
} 

Tất cả các đơn vị miền thực hiện giao diện này. Nó đã cho tôi một khả năng không tạo ra các trình biến đổi jsf khác nhau cho các thực thể khác nhau nhưng tạo ra một trình biến đổi sử dụng giao diện này thay vì các lớp miền cụ thể.

Answer 3

Tôi không thể nói đến thực tiễn chung, nhưng khó có thể che giấu việc triển khai.

Đó là về việc chính thức hóa giao diện làm cơ sở cho tài liệu và hợp đồng.

Khi trừu tượng hóa mô hình của bạn thành các giao diện, bạn đang tạo tài liệu cho các nhà phát triển ứng dụng khách dịch vụ. Tùy thuộc vào phong cách phát triển của bạn, bạn có thể hoặc chưa có mô tả chính thức về dịch vụ của mình (ví dụ: mô tả dựa trên WSDL). Giao diện có thể lấp đầy nhu cầu đó.

Answer 4

Quan điểm chung của tôi là tôi sẽ không tạo bộ giao diện một-một cho các mô hình miền, vì điều này không có gì khác ngoài cấu trúc lớp của mô hình miền của bạn. Nó không thêm bất cứ điều gì hữu ích.

Hai trường hợp tôi có thể nghĩ đến ngay nơi tôi sẽ xem xét giao diện giới thiệu là:

1. một giao diện mô tả hợp đồng/hành vi của một số tập các lớp trong mô hình miền, nơi nó rất hữu ích để mô hình hành vi đó independantly của các lớp mà thực hiện nó
2. bạn cần để lộ mô hình tên miền của bạn cho các khách hàng bên ngoài và muốn ẩn chi tiết thực hiện từ họ

Nói cách khác, thêm giao diện nếu chúng giúp bạn mô tả hành vi hoặc giúp bạn ẩn chi tiết triển khai từ khách hàng. Các lý do khác có thể hợp lệ, nhưng đó là hai lý do khiến bạn bận tâm.

Answer 5

Tôi nghĩ có sự khác biệt quan trọng giữa việc có giao diện cho dịch vụ để truy xuất đối tượng và chính đối tượng mô hình đó.

Khi chạy dịch vụ để tải một đối tượng mô hình có thể khác nhau tùy theo nơi bạn đang yêu cầu dữ liệu. Nhưng định dạng và loại đối tượng dữ liệu được mong đợi sẽ không thay đổi, bất kể bạn tạo đối tượng này như thế nào. Do đó, các đối tượng mô hình mang trạng thái sẽ không cần một giao diện, nhưng các lớp dịch vụ để tạo và tải các đối tượng mô hình này cần giao diện.

Lý do duy nhất cho các đối tượng mô hình có giao diện sẽ có ý nghĩa nếu đối tượng mô hình không chỉ là một loại bean đơn giản của đối tượng mà còn thể hiện một số loại hành vi.

Answer 6

Trích xuất một giao diện là một trong các phép tái cấu trúc đơn giản nhất; trường hợp xấu nhất đó là một tên lớp -> di chuyển phương pháp. Nỗ lực thay đổi tâm trí của bạn, một khi bạn đã tìm được lý do để làm như vậy, là tối thiểu. Tôi đã luôn thấy rằng nếu một quyết định dễ thay đổi, nó củng cố YAGNI và KISS nhiều hơn nữa. Đối số phản đối là không có nhiều nỗ lực để tạo ra một giao diện ban đầu, điều đó đúng, nhưng việc bảo trì tăng lên theo thời gian nếu quyết định được thực hiện nhiều lần - thường không được sử dụng.