Có thể (được khuyến nghị) để có một dự án api thuần túy được tách biệt khỏi việc triển khai thực tế không?

Question

Tôi được yêu cầu tạo bố cục dự án cho ứng dụng sắp tới của chúng tôi bằng Maven. Vật phẩm đầu tiên chúng ta sẽ làm việc trên sẽ là kiến ​​trúc. Để làm cho nó dễ dàng nhất có thể cho các nhà phát triển để làm việc tôi đã có ý tưởng để tách thực hiện thực tế từ các API (như bạn sẽ làm trong một môi trường OSGi).

Các phụ thuộc sẽ liệt kê dự án API là phụ thuộc cho phạm vi biên dịch và việc triển khai chỉ được cung cấp khi chạy.

Với cách tiếp cận này, tôi hy vọng sẽ giảm sự phức tạp cho các nhà phát triển và cũng hạn chế họ sử dụng các lớp nội bộ thường xuyên thay đổi. Hơn nữa, có thể ẩn phụ thuộc transitive (ví dụ: Tôi không muốn các nhà phát triển gọi lớp DAO từ giao diện người dùng ... điều này chỉ nên hiển thị từ lớp dịch vụ).

Có ai đó đưa điều này vào thực tế và nó đã hoạt động như thế nào? Bạn nghĩ gì về nó nói chung?

Answer 1

UML cho phép bạn lập mô hình theo cách này và một số công cụ UML sẽ tạo mã dựa trên mô hình, theo lý thuyết sẽ giúp thu hẹp khoảng cách từ UML thành mã, khi đến lúc.

Kiến trúc sư doanh nghiệp là một công cụ như vậy. Nhưng điều này đòi hỏi nhóm của bạn phải hiểu biết về UML cũng như hiểu biết về một số công cụ UML.

Answer 2

Tôi nghĩ rằng đó là một cách tiếp cận tốt và sử dụng nó mọi lúc. Tôi đã trải qua không có bất lợi thực sự để làm điều đó theo cách này.

Ví dụ về việc sử dụng của tôi giống như thư viện cạo màn hình.

tôi sẽ có một dự án Maven:

data-source-api 

đó có một dịch vụ như:

package my.datasource.api; 

public interface DataSource { 
    public GetDataResponse getData(GetDataRequest request); 
} 

đâu GetDataRequest và GetDataResponse (và các lớp API khác) cũng nằm trong dự án api.

Và cũng có dự án Maven gọi:

data-source-urlfetch-impl // for appengine 
data-source-http-client-impl // for Apache HTTP client 
data-source-urlconnection-impl // for appengine/vanilla Java 

Đối với mỗi hiện thực của tôi. Ví dụ:

package my.datasource.urlfetch; 

public class UrlFetchDataSource implements DataSource { 
    ... 
} 

Answer 3

Thiết kế âm thanh để tách giao diện (hợp đồng) và triển khai. Nhưng như với tất cả mọi thứ, sử dụng với kiểm duyệt. Bạn không muốn hạn chế và làm phức tạp thiết kế đến mức chi phí cao hơn chi phí. Hãy nhớ rằng, nó được cho là để thêm lợi ích (hoặc rủi ro thấp hơn), nó không phải là một mục tiêu trong chính nó. Hãy tự hỏi tại sao bạn làm những việc này, chi phí và lợi ích là gì và rủi ro và/hoặc chi phí KHÔNG làm việc đó là gì.

Answer 4

Tôi đã thấy nó rất nhiều, và có những ưu và nhược điểm của cách tiếp cận rằng:

• Ưu
  • rõ ràng tách API và thực hiện
• Nhược
  • More khó hiểu, bởi vì không có bối cảnh thực tế, ví dụ, kiểm tra đơn vị để xem xét để hiểu API.
  • Khó khăn hơn để cấu trúc lại và hiểu các hậu quả của định nghĩa và thay đổi API. Tôi nghèo để tưởng tượng những gì có thể là một API tốt cho đến khi tôi đã sử dụng nó (và thấy rằng nó không hoạt động tốt).
  • Nếu có triển khai (chạy) phía sau API của bạn mà người dùng không thể truy cập, rất khó hoặc thậm chí không thể thực hiện thử nghiệm thực sự cho ứng dụng thực.

Vì vậy, tôi nghĩ rằng đó là tốt đẹp để xuất bản một API như chỉ API, nhưng rất khó để phát triển các API mà không cần mã nguồn sản, và đôi khi để thực hiện so với API thực mà không cần chạy mã mà cho thấy cách nó hoạt động.

cách tiếp cận khác nhau có thể là:

• Phát triển với các API một thực hiện mặc định như giới thiệu.
• Phát triển với API một triển khai ví dụ cho thấy cách sử dụng API.
• Phát triển một loạt các bài kiểm tra đơn vị và các đối tượng mô phỏng để cho biết cách sử dụng API của bạn trong các bài kiểm tra đơn vị.