Tôi có nên viết API giao diện trước khi triển khai không?

Gần đây tôi đã đào sâu vào lập trình "có tổ chức" hơn và tôi đã học được rằng tôi nên lập trình lên một giao diện, chứ không phải là một triển khai. Với ý nghĩ đó, sẽ tốt hơn nếu "phác thảo" ra một dự án trong các giao diện trước khi viết triển khai cho nó khi có thể?

Và nếu đây là trường hợp, trong trường hợp sử dụng các thư viện của bên thứ 3 (ví dụ như Lidgren), tôi có nên gói chúng trong các giao diện không và giải quyết chúng thông qua các thùng chứa IOC, hoặc có thể tiếp xúc với các giao diện không?

Thật không may, bạn sẽ thấy điều này thường sôi theo sở thích cá nhân.

Những gì bạn đã mô tả cho đến nay, mặc dù, có vẻ tốt. Trong thực tế, nếu bạn muốn (và tôi khuyên bạn nên làm như vậy), bạn có thể sử dụng phương pháp sau:

1. Viết bộ xương ứng dụng của bạn dưới dạng Giao diện, các lớp trừu tượng (còn sơ khai) và các lớp (cũng còn sơ khai)
2. Viết bài kiểm tra của bạn đối với các giao diện và sơ khai đó (chúng sẽ thất bại ngay bây giờ)
3. Viết các triển khai của bạn (các bài kiểm tra của bạn sẽ bắt đầu vượt qua khi bạn hoàn thành việc triển khai của mình)

Bạn đang tập trung vào việc cố gắng viết mã "có tổ chức" hơn. Theo dõi TDD sẽ giúp bạn điều này.

Một số điểm bổ sung:

• IoC container thuận tiện. Sử dụng chúng và DI càng nhiều càng tốt.
• Đừng bọc thư viện bên thứ 3. Điều này sẽ nới lỏng sự ghép nối giữa mã của bạn (mã bạn kiểm soát) và mã bên thứ 3 (mã bạn không kiểm soát)

Có, bạn nên viết mã dựa trên các giao diện thay vì các triển khai đã biết và có, bạn nên xây dựng các giao diện trước thay vì chúng xuất hiện từ mã của riêng bạn.

Lý do cho cả hai khuyến nghị phần lớn giống nhau: lập trình máy tính chủ yếu là về các yếu tố con người. Nhiều người thấy điều này đáng ngạc nhiên, nhưng hãy xem xét: có một số lượng gần như vô tận các cách khác nhau để giải quyết cùng một vấn đề điện toán hoạt động tốt như nhau. Gần như tất cả chúng hoàn toàn không thể có ý nghĩa đối với bất kỳ ai không viết chúng (hoặc thực tế cho tác giả một thời gian ngắn sau đó).

Theo sau đó, công nghệ phần mềm tốt phần lớn là về cách đạt được hiệu quả mong muốn (tính toán chính xác với hiệu quả hợp lý) theo cách cho phép mã nguồn được làm việc sau này. Các giao diện và API là một phần quan trọng của môn học đó: chúng cho phép bạn suy nghĩ về một vấn đề ở một cấp độ mô tả tại một thời điểm. Điều này dễ dàng hơn nhiều so với suy nghĩ về các quy tắc nhất quán kinh doanh và về việc triển khai danh sách được liên kết cùng một lúc, và do đó áp đặt một mối quan tâm như vậy một cách ép buộc tốt hơn là cho phép lập trình viên khách hàng sử dụng mã của bạn theo bất kỳ cách nào anh ta thích.

Điều này thật khó tin đối với nhiều lập trình viên cao bồi, những người tin rằng họ hiểu mọi thứ họ viết, tốt hơn nhiều so với những người suy nghĩ trung bình và có thể xử lý tất cả sự phức tạp gây rắc rối cho các lập trình viên "ít" hơn. Không nhận thức được giới hạn nhận thức của chính mình là một hiện tượng cực kỳ phổ biến - đây là lý do tại sao các thực tiễn tốt nhất trong tổ chức mã rất quan trọng (và thường bị bỏ qua).

Nhắc lại, các giao diện và rào cản API phần lớn là tốt , ngay cả khi bạn chỉ hợp tác với chính mình. Đối với các thư viện bên ngoài, nếu họ mang theo API chu đáo, tôi sẽ không gặp vấn đề gì khi sử dụng nó miễn là bạn không lường trước việc phải trao đổi thư viện đó cho một thư viện khác. Mặt khác, một lớp bọc hoặc lớp chống tham nhũng có thể là một ý tưởng rất tốt.

Thay vì chỉ đơn giản là lập trình cho các giao diện, tại sao không xem xét Thiết kế / Phát triển hướng thử nghiệm (TDD)?

Nhiều người nghĩ về TDD như một cách thực hành thử nghiệm, nhưng thực ra đó là cách tiếp cận thiết kế nơi bạn để các thử nghiệm phơi bày cách mã của bạn sẽ được sử dụng thông qua các thử nghiệm (ban đầu thông qua các thử nghiệm đơn vị, nhưng cũng có thể thông qua các thử nghiệm tích hợp).

Lập trình cho các giao diện là một vũ khí quan trọng trong bộ công cụ của bạn, nhưng giống như hầu hết mọi thứ, nó không phải lúc nào cũng là giải pháp / kỹ thuật / thực hành phù hợp, vì không phải lúc nào cũng cần thiết. Bạn nên lập trình đến các giao diện mà bạn cần.

Sử dụng TDD sẽ buộc bạn khám phá nơi các giao diện như vậy là quan trọng và thực sự thì nó không quan trọng. Và vào cuối của nó, bạn sẽ có một bộ kiểm tra đơn vị khá tốt trên cơ sở mã của bạn.

Đối với việc sử dụng các thư viện của bên thứ 3, tôi rất khuyên bạn nên gói chúng trong các bản tóm tắt của riêng bạn khi thích hợp; và không để khách hàng API của bạn "biết" về họ.

Chúc may mắn!

[sửa: đã thấy câu trả lời của megaflight - hoàn toàn đồng ý]

Tôi nghĩ rằng nó là quá mức cần thiết. Nếu người dùng API của bạn không cần bị buộc phải thực hiện / sử dụng một cái gì đó theo một cách nhất định thì tôi sẽ loại bỏ nó. Giao diện là hợp đồng, nếu tôi không cần thì tại sao lại cho tôi?

Tôi nghĩ mọi người lạm dụng giao diện. Bạn đang thêm một lớp phức tạp không cần thiết trong hầu hết các trường hợp.

Lập trình chống lại một hợp đồng hầu như luôn luôn là một ý tưởng tốt. Hợp đồng đó không cần phải là một giao diện, nó có thể được thực hiện bởi một lớp thay thế. Theo tôi, các giao diện đã trở nên hơi bị lạm dụng cùng với DI do các mối quan tâm kiểm tra đơn vị và các khung mô phỏng.

Cá nhân tôi thích chỉ mang lại các giao diện khi tôi rất có thể có hoặc có nhiều hơn 1 lần thực hiện hợp đồng. Các giao diện rất tốt cho các kho lưu trữ nơi tôi muốn trừu tượng hóa việc truy cập dữ liệu, nhưng có lẽ ít hơn đối với logic kinh doanh tiêu chuẩn của tôi có khả năng tương đối không linh hoạt.

Bây giờ không có giao diện có thể gây ra vấn đề với thử nghiệm đơn vị, đặc biệt là đối với những người theo chủ nghĩa thuần túy. Nhưng tôi quan tâm đến việc chế nhạo các phụ thuộc bên ngoài của các chương trình của tôi chứ không phải các phụ thuộc bên trong của nó. Tôi muốn các thử nghiệm của mình thực hiện xác nhận mã, không lặp lại cấu trúc mã.