Khi nào cần giao diện?

Question

(Trong ngữ cảnh .NET cho giá trị của nó)

Tôi có xu hướng không sử dụng thừa kế và hiếm khi sử dụng giao diện. Tôi bắt gặp một người nghĩ rằng giao diện là điều tốt nhất kể từ khi nhổ. Anh ta sử dụng chúng ở mọi nơi. Tôi không hiểu điều này và do đó các câu hỏi tiếp theo. Tôi chỉ muốn kiểm tra sự hiểu biết của tôi về giao diện.

Nếu bạn đang sử dụng giao diện ở mọi nơi, tôi giả định bạn có thể dự đoán tương lai, yêu cầu ứng dụng của bạn sẽ được đóng đinh và không có gì thay đổi trong ứng dụng của bạn. Đối với tôi, đặc biệt trong quá trình phát triển ban đầu, giao diện trở thành một sự kéo. Các ứng dụng rất năng động thông qua cuộc sống của nó. Nếu bạn cần trừ hoặc thêm thành viên vào giao diện, nhiều thứ sẽ bị hỏng. Anh chàng ở trên nói rằng anh ta tạo một giao diện khác để xử lý (các) thành viên mới. Không có gì phá vỡ.

Đó không phải là thành phần đó phải không? Tại sao không sử dụng bố cục mà không có giao diện? Linh hoạt hơn.

Làm cách nào để xử lý trường hợp một thành viên phải được trừ khỏi giao diện? Về cơ bản anh ta không. Những điều chỉ cần phá vỡ và đó là tuyệt vời bởi vì bây giờ bạn có thể nhìn thấy tất cả các khu vực bị ảnh hưởng và sửa chữa chúng. Thay vì tìm ra một cách thanh lịch hơn, nơi tất cả các đường dẫn mã có liên quan, chúng ta chỉ cần tách ra các phần của lớp thông qua lực lượng vũ phu?

Tôi nghĩ về ứng dụng phần mềm dưới dạng biểu đồ. Một đồ thị hoàn chỉnh là trường hợp xấu nhất, có n (n-1)/2. Điều này có nghĩa là mọi lớp đều nói chuyện với mọi lớp. Một mạng nhện khó hiểu. n-1 là tốt nhất, trong đó họ là một hệ thống phân cấp chặt chẽ về giao tiếp. Việc thêm một giao diện khác chỉ để bù cho một thành viên mới cần thiết thêm một vertici vào đồ thị, có nghĩa là nhiều cạnh hơn và một sự thực hiện mạnh mẽ hơn của phương trình n (n-1)/2. Thành phần không có giao diện giống như mixin hơn. Chỉ chọn các lớp học sử dụng các phương thức cụ thể. Với giao diện, tất cả các lớp đều buộc phải sử dụng thành viên, ngay cả khi họ không cần chúng. Cách tiếp cận bố cục/mixin không thêm các cạnh không cần thiết mới.

Answer 1

Giao diện không buộc các lớp học phải sử dụng phương thức. Họ buộc triển khai các lớp học để triển khai tất cả các phương pháp, nhưng đó là một vấn đề khác.

Tôi thích cách giao diện tách biệt API khỏi triển khai. Phải thừa nhận rằng điều này cũng được thực hiện với các công cụ sửa đổi truy cập, nhưng các giao diện làm cho nó rõ ràng hơn. Quan trọng hơn, các giao diện cũng làm cho việc nhạo báng dễ dàng hơn - có nghĩa là bạn có thể kiểm tra các lớp phụ thuộc vào giao diện ngay cả trước khi bạn thực hiện nó.

Và có, điều này có nghĩa là tôi thường kết thúc bằng giao diện chỉ có một triển khai sản xuất duy nhất. Đó không phải là vấn đề trong quan điểm của tôi, bởi vì tôi đã đạt được khả năng kiểm tra.

Mặt khác, tôi không viết giao diện cho mỗi lớp. Tôi thích viết các giao diện trong đó đối tượng chủ yếu cung cấp dịch vụ - xác thực, truy cập dữ liệu, v.v. Các đối tượng dữ liệu đơn giản (ngay cả với hành vi quan trọng) không hữu ích về mặt giao diện, IME.

Answer 2

Theo wikipedia,

Việc sử dụng chính của đa hình trong ngành công nghiệp (hướng đối tượng lý thuyết lập trình) là khả năng của các đối tượng thuộc các loại khác nhau để đáp ứng với phương pháp, lĩnh vực, hoặc tài sản các cuộc gọi cùng tên , mỗi loại theo một hành vi cụ thể loại thích hợp. Lập trình viên (và chương trình) không phải biết chính xác loại đối tượng trước, và do đó hành vi chính xác được xác định tại thời gian chạy (điều này được gọi là ràng buộc trễ hoặc ràng buộc động).

Đó là điều làm cho giao diện trở nên hữu ích.

"Anh chàng ở trên nói rằng anh ấy tạo một giao diện khác để xử lý (các) thành viên mới. Không có gì xảy ra".

Tôi chỉ đoán ở đây, nhưng có vẻ như anh chàng này đến từ một trường học cũ COM nền (tôi có thể là sai, tất nhiên!). Làm cho tôi co rúm người lại để suy nghĩ về tất cả các mã tôi đã làm việc về nơi tôi đã nhìn thấy những thứ như thế này:

• IWidgetManager
• IWidgetManager2
• IWidgetManager3

Đó không phải là một cách tốt để làm việc với giao diện. Theo kinh nghiệm của tôi, tôi đã nhìn thấy cả hai thái độ: sợ thay đổi giao diện đến điểm mà giao diện mới được tạo ra bất cứ khi nào các thành viên mới được thêm vào hoặc không sử dụng giao diện và có một sản phẩm bị mức độ cao là coupling. Bạn cần phải tìm một sự cân bằng tốt. Nó không phải luôn luôn là kết thúc của thế giới để thay đổi một giao diện.

Kích thước của dự án bạn đang làm việc là gì? Có thể khó thấy lợi ích của giao diện nếu nó là một dự án có kích thước tương đối nhỏ. Nếu, mặt khác, đó là một dự án với hàng trăm nghìn dòng mã và bao gồm nhiều mô-đun, lợi ích trở nên rõ ràng hơn nhiều.

Answer 3

Giao diện có ý nghĩa nhất đối với tôi trong bối cảnh tiêm phụ thuộc và khung công tác IoC. Tôi thích ý tưởng rằng bạn có thể xác định một tập hợp các hành vi (phương pháp) và "đảm bảo" những hành vi đó thông qua việc thực hiện một giao diện. Bây giờ bạn có thể cắm toàn bộ các chức năng mới vào một hệ thống hiện có với một assembly đơn và cập nhật tập tin cấu hình.

Thiết kế hiệu quả các giao diện yêu cầu một thỏa thuận tốt về lập kế hoạch chuyển tiếp và tôi thấy chúng hữu ích nhất trong bối cảnh hệ thống và khung công tác lớn. Khi chúng hữu ích, chúng thực sự là thực sự là. Một vài trong số yêu thích của tôi: (? LINQ ai)

• IComparable (BẠN quyết định cách đối tượng của bạn so sánh với nhau)
• IQueryable
• IDisposable (giữ tuyên bố using của bạn tiện dụng)

Answer 4

Giao diện có nhiều tình huống hữu ích. Khi bạn cần thêm một hành vi cụ thể vào một lớp có thể được tìm thấy trên nhiều lớp khác nhau, đó là thời điểm hoàn hảo cho một giao diện. Một ví dụ tốt là giao diện IDisposable - bạn có một số tài nguyên mà khi bạn hoàn tất, cần phải biến mất một cách kịp thời. Nó là một kết nối cơ sở dữ liệu? Có một số cửa sổ xử lý? Không quan trọng.

Ví dụ khác là khi bạn thực sự không biết cách triển khai, chẳng hạn như giao diện cho đối tượng chưa tồn tại. Có lẽ đối tượng nên được cung cấp bởi một khách hàng của thư viện của bạn, hoặc phải được thực hiện bởi một mô-đun hoàn toàn khác nhau không thuộc quyền kiểm soát của bạn. Về cơ bản bạn có thể thiết kế một hợp đồng cho các phương thức có sẵn trên lớp.

Điều đó nói rằng, tôi chỉ sử dụng chúng khi cần.Nếu tôi có thể làm điều đó với một lớp học bình thường, hoặc nếu nó là một cái gì đó nội tại đối với một đối tượng cụ thể, tôi sẽ biến nó thành một lớp. Có một số lợi thế khi sử dụng Giao diện cho mọi lớp như những người khác đã nói, nhưng đó là quá nhiều chi phí phụ trội mà tôi không thấy được mức tăng thuần trên đó. Hầu hết thời gian, tôi đã thiết kế cấu trúc lớp học của mình để chúng phẳng và rộng, với ít phụ thuộc nhất có thể.

Tóm lại: Nếu bạn có chức năng chung yêu cầu được triển khai khác nhau một cách đáng kể, Giao diện chỉ là những gì bạn cần.

Answer 5

Tôi nghĩ rằng bạn mô tả phương pháp đó là top-down design.
Bạn không cần phải làm điều đó, nhưng đôi khi anh ấy thực sự giúp đỡ.

Answer 6

"Các anh chàng ở trên nói rằng ông sẽ tạo ra một giao diện để xử lý các thành viên mới (s). Không có gì phá vỡ.

Không phải là thành phần đó? Tại sao không sử dụng thành phần mà không cần giao diện? Linh hoạt hơn."

Bạn dường như đang nghĩ đến bố cục về thừa kế, như trong "Tôi sẽ kế thừa tất cả các khả năng này vào đối tượng này để thực hiện công việc này". Đó là một cách xấu để viết mã. Nó giống như nói rằng, "Tôi muốn xây dựng một tòa nhà chọc trời, vì vậy tôi sẽ tìm hiểu mọi công việc cần biết, từ cách tạo ra các bản thiết kế trên xuống để làm nền móng và lắp đặt ánh sáng ..."

Hãy suy nghĩ về thành phần thay vì về các đối tượng riêng biệt mà mỗi thực hiện một nhiệm vụ duy nhất. Để thực hiện một công việc phức tạp, bây giờ tôi có thể dựa vào các đối tượng riêng biệt này để thực hiện các nhiệm vụ riêng lẻ của họ. Nó giống như thuê các kiến ​​trúc sư và đội xây dựng để xây dựng tòa nhà chọc trời. Tôi không cần biết chi tiết về cách họ làm công việc của họ, chỉ để họ có thể làm được. Trong mã, điều này có nghĩa là tiêm phụ thuộc vào một đối tượng để thực hiện một nhiệm vụ phức tạp thay vì kế thừa.

Vậy giao diện phù hợp với đâu? Chúng là hợp đồng giữa các vật thể riêng biệt. Chúng cho phép bạn không quan tâm đến việc triển khai cá nhân, cụ thể. Chúng cho phép bạn nói một ngôn ngữ chung với một loạt các đối tượng có cùng trách nhiệm, nhưng thực tế có thể có sự triển khai khác nhau. Giao diện trở thành một trừu tượng đối với đối tượng thực hiện nhiệm vụ. Tôi không cần phải biết làm thế nào mỗi người đàn ông duy nhất với một cái búa hoạt động, chỉ là anh ta biết làm thế nào để HitNail().

Khi bạn bắt đầu soạn hệ thống mã phức tạp với nhiều lớp nhỏ có trách nhiệm duy nhất, bạn sẽ sớm biết rằng bạn có thể gặp phải các vấn đề nghiêm trọng nếu bạn dựa quá nhiều vào việc thực hiện cụ thể một lớp cụ thể lớp học bắt đầu thay đổi ... Vì vậy, thay vì dựa vào việc thực hiện cụ thể, chúng tôi tạo ra một giao diện - một trừu tượng. Và chúng tôi nói, "Tôi không quan tâm đến cách bạn làm JobX, chỉ khi bạn làm điều đó."

Có những lợi ích khác cho các giao diện như thử nghiệm, chế nhạo, v.v ... Nhưng đó không phải là lý do để mã hóa giao diện. Lý do là tạo ra một hệ thống mã không phụ thuộc vào các chi tiết cụ thể và do đó được kết hợp chặt chẽ với nhau. Đây là lý do tại sao, với bộ não suy nghĩ đồ thị của bạn, bạn nên sợ ghép nối một loạt các lớp bê tông với nhau. Bởi vì những thay đổi trong một trong các lớp đó sẽ gây ra hiệu ứng gợn sóng.

Khi bạn kết hợp với bản tóm tắt thay vì lớp bê tông, bạn giới hạn khớp nối. Bạn nói, tôi "m chỉ sẽ được kết hợp với hợp đồng mà cả hai chúng tôi đồng ý, và không có gì khác." Và nếu lớp thực hiện hợp đồng đó thay đổi cách thức hoàn thành nhiệm vụ nội bộ của nó, bạn không quan tâm, bởi vì bạn không dựa vào tài sản hoặc phương thức không hợp đồng. Bạn chỉ dựa vào hợp đồng đã thỏa thuận.

Answer 7

Nếu bạn muốn hiểu thời điểm sử dụng giao diện và việc sử dụng chúng là gì, tôi nghĩ bạn nên xem cuốn sách: Head First Desing Patterns.

Đây là cuốn sách thực sự giúp tôi hiểu những điều tuyệt vời về giao diện.

Trước khi đọc cuốn sách này, tôi biết giao diện là gì, nhưng tôi hoàn toàn không biết khi nào tôi nên sử dụng chúng.

Answer 8

Tôi muốn tham khảo các hướng dẫn thiết kế .net về điều này: http://msdn.microsoft.com/en-us/library/ms229013.aspx

Có rất nhiều lý do để sử dụng giao diện, nhưng tôi cũng thấy rằng họ thường đang bị lạm dụng vì những lý do sai lầm. Giao diện cung cấp sự linh hoạt hơn nhiều khi làm việc với các kiểu giá trị, và cực kỳ hữu ích khi làm việc với các bộ sưu tập, vv, nhưng khi thiết kế một hệ thống phân cấp lớp cho các dự án của riêng tôi, tôi luôn cố gắng suy nghĩ về sự đơn giản đầu tiên và các giao diện thường dẫn đến (không cần thiết) các tình huống phức tạp hơn.

Quy tắc chung của tôi là triển khai mọi giao diện BCL có ý nghĩa và chỉ thêm giao diện của riêng tôi vào thiết kế khi nó thực sự cung cấp một cái gì đó rất có giá trị. Thay vì có IWidgetManager, IWidgetManager2, ... tôi muốn có khá nhiều lớp WidgetManager trừu tượng và triển khai các phương thức cụ thể khi cần thiết.

Answer 9

Đó là về phụ thuộc. Bạn muốn mã của bạn phụ thuộc vào loại giao diện thay vì các loại cụ thể khi thích hợp. Ví dụ, bạn có thể có nhiều loại cụ thể mà tất cả đều thực hiện hành vi tương tự nhưng thực hiện nó một cách khác nhau. Bạn có muốn cơ sở mã của bạn có phụ thuộc vào nhiều loại cụ thể đó hay một giao diện không? Bạn cho rằng cơ sở mã của mình linh hoạt như thế nào khi bạn cần thực hiện thay đổi?

Quan điểm của bạn về việc không muốn sử dụng thành viên công khai bằng cách sử dụng bố cục, tôi sẽ nói bạn chỉ gói gọn các phụ thuộc không cần thiết. Nếu bạn muốn sử dụng bố cục, thì bạn giảm đáng kể sự phụ thuộc bằng cách soạn các loại giao diện thay vì các kiểu cụ thể.

Để có giải thích tốt hơn, hãy thử xem tài liệu trên inversion of control.

Answer 10

Người này có vẻ như anh đã hiểu lầm khái niệm lập trình đối với giao diện. Nó không đề cập đến lập trình chỉ sử dụng từ khóa interface trong .Net/Java hoặc lớp không có gì ngoài các hàm ảo thuần túy trong C++, Giao diện được đề cập trong nguyên tắc đó là một cấu trúc cấp cao đóng gói cấp thấp của một hệ thống. Giống như với phép nhân, nó gói gọn ý tưởng thêm một số vào chính nó một số lượng lặp lại cụ thể. Nhưng khi chúng tôi nói 3 * 2, chúng tôi không quan tâm nếu đó là 3 + 3, 2 + 2 + 2 hoặc (2 + 2) + 2 trong đó phần trong dấu ngoặc đơn được lưu trong bộ nhớ cache. Miễn là chúng tôi nhận được 6 từ nó.

Thực tế, khái niệm về giao diện có thể được điền bằng interface hoặc abstract class hoặc kết hợp các trường hợp này như trường hợp có nhiều mẫu GoF. Nó chỉ là loại từ khóa interface của những đám mây với nước mơ hồ.

Thật buồn cười. Kiểu suy nghĩ của anh chàng này có lẽ là những lời bình luận được tạo ra, chẳng hạn như những ý kiến ​​tập trung xung quanh tập phim StackOverflow # 38.

Answer 11

Giao diện giúp bạn duy trì sự phụ thuộc vào việc trừu tượng hóa.

Mã sử ​​dụng giao diện chỉ phụ thuộc vào giao diện, vì vậy bạn biết rằng không có phụ thuộc nhân tạo nào vào chi tiết. Điều này mang lại cho bạn rất nhiều tự do như xa như thay đổi mã trong tương lai, vì bạn biết chính xác những gì nên & không nên phá vỡ khi bạn 'sửa chữa' một lỗi hoặc refactor.

Theo tôi, đó là bản chất của thiết kế mã tốt.

Answer 12

Có vẻ như bạn bè của bạn đã sử dụng sai giao diện nghiêm trọng.

Tôi cũng đã thấy các ứng dụng web có giao diện khắp nơi. Một số người dường như có ý tưởng rằng một giao diện bằng cách nào đó tốt hơn chỉ là một chữ ký phương thức thông thường. Các thông số đơn giản đã cung cấp cho chúng tôi một hợp đồng - trong hầu hết các trường hợp, tôi tin rằng điều này là đủ và làm cho mã đơn giản hơn.

Dường như với tôi rằng giao diện là hữu ích nhất trong các trường hợp như IDisposable hoặc ICollection - nơi chúng trỏ đến một tập hợp chức năng nhất định mong đợi từ một đối tượng. Trong những trường hợp này, chúng dường như là công cụ thích hợp cho công việc.

Answer 13

Chúng tôi sử dụng rất nhiều giao diện trên các phần tử giao diện người dùng tùy chỉnh, nơi mỗi người mong đợi một phương thức nhất định tồn tại trên một giao diện khác (và giao diện buộc sự tồn tại đó).

Answer 14

Việc sử dụng chính giao diện là cho phép biến thể triển khai cho phép mã được chuyển vào thời gian chạy. Có một số lý do/lý do để thực hiện việc này.

Trong quá khứ, một số người đã lập luận rằng mọi lớp trong hệ thống phải có giao diện, nhưng điều này được thừa nhận rộng rãi là quá mức cần thiết. Các giao diện giờ đây được sử dụng trong trường hợp các lớp có thể thay đổi như là một phần của hoạt động hệ thống (để biểu diễn trạng thái): các mẫu GoF như Strategy và Command capture sử dụng này, và/hoặc các phần của hệ thống cần được thay thế để kiểm tra. chích thuốc). Nếu các nhà phát triển đang theo các thực hành phát triển theo hướng thử nghiệm, các đối tượng cơ sở hạ tầng quan trọng sẽ có các giao diện. Điều này cho phép các phép thử thực hiện "mocks" của các đối tượng này để kiểm tra luồng điều khiển của hệ thống. Có một mối quan hệ giữa việc sử dụng giao diện này và Nguyên tắc thay thế Liskov (một trong các nguyên tắc của thiết kế OO)

Việc sử dụng thêm cho các giao diện ít quan tâm đến những gì có sẵn cho người gọi, là giao diện điểm đánh dấu. Đó là cách kết hợp siêu dữ liệu với định nghĩa lớp. Điều này có thể ảnh hưởng đến cách hệ thống xem đối tượng (ví dụ như cho phép nó được tuần tự hóa) hoặc nó có thể chỉ là tài liệu.

Answer 15

Một trong những lý do quan trọng nhất để sử dụng giao diện là thực tế là chúng cho phép chúng tôi viết các bài kiểm tra đơn vị cho các lớp của chúng tôi và chuyển các phụ thuộc của riêng chúng tôi. Bằng cách đặt sự phụ thuộc đằng sau một giao diện, chúng tôi mở ra "Seams" trong mã ứng dụng của chúng tôi, nơi các bài kiểm tra đơn vị có thể dễ dàng được viết. Tôi không thấy góc kiểm tra này được đề cập trong nhiều câu trả lời, nhưng rất quan trọng để hiểu rằng nếu không có giao diện, các phụ thuộc (như dịch vụ web hoặc tham chiếu hệ thống tệp) có thể trở nên rất khó kiểm tra hoặc tốt nhất hoàn toàn có điều kiện. Tôi đã viết một bài đăng ở đây: http://jeffronay.com/why-use-an-interface/ đi vào chi tiết hơn với các ví dụ mã hiển thị lớp Dịch vụ không có giao diện và sau đó cùng một lớp được viết lại bằng giao diện để chứng minh tính linh hoạt của thử nghiệm khi sử dụng giao diện.