Khai báo giao diện trong cùng một tệp với lớp cơ sở, đó có phải là một thực hành tốt?

Để có thể hoán đổi và kiểm tra được, thông thường các dịch vụ có logic cần phải có giao diện, ví dụ:

public class FooService: IFooService 
{ ... }

Thiết kế khôn ngoan, tôi đồng ý với điều này, nhưng một trong những điều làm phiền tôi với cách tiếp cận này là đối với một dịch vụ, bạn sẽ cần khai báo hai điều (lớp và giao diện), và trong nhóm của chúng tôi, thông thường là hai tệp (một cho lớp và một cho giao diện). Một khó chịu khác là khó khăn trong việc điều hướng vì sử dụng "Chuyển đến định nghĩa" trong IDE (VS2010) sẽ trỏ đến giao diện (vì các lớp khác tham chiếu đến giao diện), chứ không phải lớp thực tế.

Tôi đã nghĩ rằng viết IFooService trong cùng một tệp với FooService sẽ làm giảm sự kỳ lạ ở trên. Xét cho cùng, IFooService và FooService rất liên quan. Đây có phải là một thực hành tốt? Có lý do chính đáng nào để IFooService phải nằm trong tệp riêng của mình không?

Nó không phải ở trong tệp riêng của nó, nhưng nhóm của bạn nên quyết định một tiêu chuẩn và tuân theo nó.

Ngoài ra, bạn đúng rằng "Chuyển đến định nghĩa" sẽ đưa bạn đến giao diện, nhưng nếu bạn đã cài đặt Resharper , chỉ cần một cú nhấp chuột để mở danh sách các lớp / giao diện dẫn xuất từ ​​giao diện đó, vì vậy đó không phải là vấn đề lớn. Đó là lý do tại sao tôi giữ giao diện trong một tệp riêng biệt.

Tôi nghĩ bạn nên giữ chúng riêng biệt. Như bạn đã nói, ý tưởng là vẫn có thể kiểm tra và hoán đổi cho nhau. Bằng cách đặt giao diện trong cùng một tệp với triển khai của bạn, bạn đang liên kết giao diện với việc triển khai cụ thể. Nếu bạn quyết định tạo một đối tượng giả hoặc triển khai khác, giao diện sẽ không tách biệt về mặt logic với FooService.

Theo RẮN, không chỉ bạn nên tạo giao diện, và không chỉ nên ở trong một tệp khác, nó phải ở trong một cụm khác.

Tại sao? Bởi vì bất kỳ thay đổi nào đối với tệp nguồn biên dịch thành tập hợp đều yêu cầu biên dịch lại tập hợp và bất kỳ thay đổi nào đối với tập hợp đều yêu cầu biên dịch lại bất kỳ tập hợp phụ thuộc nào. Vì vậy, nếu mục tiêu của bạn, dựa trên RẮN, là có thể thay thế triển khai A bằng triển khai B, trong khi lớp C phụ thuộc vào giao diện tôi không phải biết sự khác biệt, bạn phải đảm bảo lắp ráp với I trong đó không thay đổi, do đó bảo vệ tập quán.

"Nhưng nó chỉ là một biên dịch lại" Tôi nghe bạn phản đối. Cũng có thể, nhưng trong ứng dụng điện thoại thông minh của bạn, băng thông dữ liệu của người dùng sẽ dễ dàng hơn; tải xuống một nhị phân đã thay đổi, hoặc tải xuống nhị phân đó và năm mã khác có mã phụ thuộc vào nó? Không phải mọi chương trình được viết để được sử dụng bởi các máy tính để bàn trên mạng LAN. Ngay cả trong trường hợp đó, nơi băng thông và bộ nhớ rẻ, các bản phát hành bản vá nhỏ hơn có thể có giá trị vì chúng không đáng kể để đẩy ra toàn bộ mạng LAN thông qua Active Directory hoặc các lớp quản lý miền tương tự; Người dùng của bạn sẽ đợi chỉ vài giây để nó được áp dụng vào lần tiếp theo họ đăng nhập thay vì vài phút để toàn bộ nội dung được cài đặt lại. Chưa kể rằng, càng ít các hội đồng phải được biên dịch lại khi xây dựng một dự án, nó sẽ xây dựng càng nhanh,

Bây giờ, từ chối trách nhiệm: Điều này không phải lúc nào cũng có thể hoặc khả thi để làm. Cách dễ nhất để làm điều này là tạo một dự án "giao diện" tập trung. Điều này có nhược điểm riêng của nó; mã trở nên ít sử dụng lại vì dự án giao diện VÀ dự án triển khai phải được tham chiếu trong các ứng dụng khác sử dụng lại lớp kiên trì hoặc các thành phần chính khác trong ứng dụng của bạn. Bạn có thể khắc phục vấn đề đó bằng cách chia các giao diện thành các cụm được ghép chặt chẽ hơn, nhưng sau đó bạn có nhiều dự án hơn trong ứng dụng của mình, điều này khiến việc xây dựng đầy đủ trở nên rất đau đớn. Chìa khóa là sự cân bằng và duy trì thiết kế lỏng lẻo; bạn thường có thể di chuyển các tệp xung quanh khi cần thiết, vì vậy khi bạn thấy rằng một lớp sẽ cần nhiều thay đổi hoặc việc triển khai giao diện mới sẽ cần thường xuyên (có lẽ để giao tiếp với các phiên bản mới được hỗ trợ của phần mềm khác,

Tại sao có các tập tin riêng biệt là một khó chịu? Đối với tôi, nó gọn gàng và sạch sẽ hơn nhiều. Việc tạo một thư mục con có tên "Giao diện" và dán các tệp IFooServer.cs của bạn ở đó là điều phổ biến, nếu bạn muốn xem ít tệp hơn trong Solution Explorer.

Lý do giao diện được định nghĩa trong tệp riêng của nó là vì lý do tương tự rằng các lớp thường được định nghĩa trong tệp riêng của chúng: quản lý dự án đơn giản hơn khi cấu trúc logic và cấu trúc tệp của bạn giống hệt nhau, vì vậy bạn luôn biết tệp nào được xác định lớp nào trong. Điều này có thể làm cho cuộc sống của bạn dễ dàng hơn khi gỡ lỗi (dấu vết ngăn xếp ngoại lệ thường cung cấp cho bạn số tệp và số dòng) hoặc khi hợp nhất mã nguồn trong kho lưu trữ kiểm soát nguồn.

Nó thường là một thực hành tốt để cho các tệp mã của bạn chỉ chứa một lớp hoặc một giao diện duy nhất. Nhưng các thực tiễn mã hóa này là một phương tiện để kết thúc - để cấu trúc tốt hơn mã của bạn làm cho nó dễ làm việc hơn. Nếu bạn và nhóm của bạn, thấy dễ dàng làm việc hơn nếu các lớp được giữ cùng với giao diện của chúng, bằng mọi cách hãy làm như vậy.

Cá nhân tôi thích có giao diện và lớp trong cùng một tệp khi chỉ có một lớp thực hiện giao diện, chẳng hạn như trong trường hợp của bạn.

Liên quan đến các vấn đề bạn gặp phải khi điều hướng, tôi rất có thể khuyên dùng ReSharper . Nó chứa một số phím tắt rất hữu ích để chuyển trực tiếp đến phương thức thực hiện một phương thức giao diện cụ thể.

Có nhiều lúc bạn muốn giao diện của mình không chỉ trong một tệp riêng biệt với lớp, mà ngay cả trong một cụm riêng biệt hoàn toàn.

Ví dụ: giao diện Hợp đồng dịch vụ WCF có thể được chia sẻ bởi cả khách hàng và dịch vụ nếu bạn có quyền kiểm soát cả hai đầu dây. Bằng cách di chuyển giao diện vào lắp ráp riêng, nó sẽ có ít phụ thuộc lắp ráp hơn. Điều này giúp khách hàng dễ dàng tiêu thụ hơn, nới lỏng khớp nối với việc thực hiện.

Rất hiếm khi có một cách thực hiện giao diện ¹ . Nếu bạn đặt một giao diện chung và một lớp công khai triển khai giao diện đó vào cùng một tệp, rất có thể là bạn không cần giao diện.

Khi lớp mà bạn cùng định vị với giao diện là trừu tượng và bạn biết rằng tất cả các cài đặt của giao diện của bạn sẽ kế thừa lớp trừu tượng đó, định vị hai trong cùng một tệp có ý nghĩa. Bạn vẫn nên xem xét kỹ quyết định của mình để sử dụng một giao diện: hãy tự hỏi liệu một lớp trừu tượng có ổn không, và bỏ giao diện nếu câu trả lời là khẳng định.

Tuy nhiên, nói chung, bạn nên tuân theo chiến lược "một lớp công khai / giao diện tương ứng với một tệp": nó rất dễ thực hiện và nó làm cho cây nguồn của bạn dễ điều hướng hơn.

Các giao diện thuộc về khách hàng của họ không thuộc về việc triển khai của họ, như được định nghĩa trong Nguyên tắc, Thực tiễn và Mô hình Agile của Robert C. Martin. Vì vậy, kết hợp giao diện và thực hiện ở cùng một nơi là trái với nguyên tắc của nó.

Mã khách hàng phụ thuộc vào giao diện. Điều này cho phép khả năng biên dịch và triển khai mã máy khách và giao diện mà không cần thực hiện. Hơn bạn có thể có các triển khai khác nhau hoạt động như các plugin cho mã máy khách.

CẬP NHẬT: Đây không phải là một nguyên tắc chỉ nhanh nhẹn ở đây. Gang of Four trong các mẫu thiết kế, trở lại năm 94, đã nói về các khách hàng tuân thủ các giao diện và lập trình với các giao diện. Quan điểm của họ là tương tự nhau.

Cá nhân tôi không thích "tôi" trước giao diện. Là người dùng như vậy, tôi không muốn biết đây có phải là giao diện hay không. Loại là điều thú vị. Về mặt phụ thuộc, FooService của bạn là MỘT triển khai IFooService có thể. Giao diện nên ở gần nơi sử dụng. Mặt khác, việc thực hiện phải ở một nơi có thể dễ dàng thay đổi mà không ảnh hưởng đến khách hàng. Vì vậy, tôi muốn hai tập tin - bình thường.

Mã hóa cho các giao diện có thể là xấu, trên thực tế được coi là một mô hình chống đối với các bối cảnh nhất định và không phải là một luật. Thông thường một ví dụ điển hình về mã hóa giao diện chống mẫu là khi bạn có một giao diện chỉ có một triển khai trong ứng dụng của bạn. Một cách khác là nếu tệp giao diện trở nên khó chịu đến mức bạn phải ẩn khai báo của nó trong tệp của lớp đã triển khai.

Đặt một lớp và một giao diện vào cùng một tệp sẽ không có giới hạn về cách sử dụng. Một giao diện vẫn có thể được sử dụng cho giả, v.v ... theo cùng một cách, ngay cả khi nó nằm trong cùng một tệp với một lớp thực hiện nó. Câu hỏi có thể được coi hoàn toàn là một trong những tiện lợi của tổ chức, trong trường hợp đó tôi sẽ nói làm bất cứ điều gì làm cho cuộc sống của bạn dễ dàng hơn!

Tất nhiên, người ta có thể lập luận rằng việc có hai cái trong cùng một tệp có thể dẫn đến việc không muốn coi chúng được ghép nối theo chương trình nhiều hơn so với thực tế, đó là một rủi ro.

Cá nhân, nếu tôi bắt gặp một codebase sử dụng một quy ước khác, tôi sẽ không quá quan tâm.