2008-09-12 28 views

Trả lời

29

ISP khẳng định rằng:

Khách hàng không nên bị buộc phải phụ thuộc về phương pháp mà họ không sử dụng.

ISP liên quan đến các đặc điểm quan trọng - cohesioncoupling.
Lý tưởng nhất là các thành phần của bạn phải được điều chỉnh cao. Nó cải thiện độ mạnh mã và khả năng bảo trì.

Enforcing ISP cung cấp cho bạn tiền thưởng sau:

  • cao cohesion - dễ hiểu hơn, mạnh mẽ
  • thấp coupling - bảo trì tốt hơn, sức đề kháng cao với những thay đổi

Nếu bạn muốn tìm hiểu thêm về nguyên tắc thiết kế phần mềm, nhận bản sao của Agile Software Development, Principles, Patterns, and Practices cuốn sách.

+2

nếu bạn là C# junkie: cuốn sách này cũng có sẵn phù hợp với C#. Nó được gọi là Nguyên tắc Agile, Patterns và Practices trong C#. –

+0

Erik, tôi đã đọc nó :-) – aku

5

Nó đơn giản hóa giao diện mà bất kỳ ứng dụng khách nào sẽ sử dụng và loại bỏ các phụ thuộc mà chúng có thể phát triển trên các phần của giao diện mà chúng không cần.

3

Một lý do là có nhiều giao diện với số lượng phương pháp tối thiểu cho mỗi phương pháp giúp dễ dàng triển khai từng giao diện và thực hiện chúng một cách chính xác. Một giao diện lớn có thể không hợp lệ. Ngoài ra, việc sử dụng giao diện tập trung trong kịch bản làm cho mã có thể bảo trì được hơn vì bạn có thể xem khía cạnh nào của đối tượng đang được sử dụng (ví dụ: giao diện IComparable cho bạn biết rằng đối tượng chỉ được sử dụng để so sánh trong trường hợp đã cho).

7

Phân tách giao diện là "I" trên nguyên tắc SOLID, trước khi đào sâu quá mức với nguyên tắc đầu tiên, hãy giải thích ý nghĩa của từ sau.

RẮN có thể được coi là một tập hợp các phương pháp hay nhất và khuyến nghị của các chuyên gia (có nghĩa là chúng đã được chứng minh trước) để cung cấp nền tảng đáng tin cậy trong cách chúng tôi thiết kế ứng dụng. Những thực hành này cố gắng làm cho việc duy trì, mở rộng, thích ứng và mở rộng các ứng dụng của chúng tôi trở nên dễ dàng hơn.

Tại sao tôi nên quan tâm đến lập trình SOLID?

Trước hết, bạn phải nhận ra bạn sẽ không mãi mãi ở nơi bạn đang ở. Nếu chúng tôi sử dụng các tiêu chuẩn và kiến ​​trúc nổi tiếng, chúng tôi có thể chắc chắn rằng mã của chúng tôi sẽ dễ dàng duy trì bởi các nhà phát triển khác đến sau chúng tôi và tôi chắc chắn bạn sẽ không muốn giải quyết nhiệm vụ sửa mã không không áp dụng bất kỳ phương pháp được biết đến vì nó sẽ rất khó để hiểu nó.

Nguyên tắc phân tách giao diện.

Biết rằng chúng ta biết nguyên tắc SOLID là gì chúng ta có thể đi vào chi tiết hơn về nguyên tắc Phân đoạn giao diện, nhưng phân biệt giao diện chính xác nói gì?

“Khách hàng không nên bị buộc phải thực hiện phương pháp không cần thiết mà họ sẽ không sử dụng”

này có nghĩa là đôi khi chúng ta có xu hướng để làm cho giao diện với rất nhiều phương pháp, có thể đối xử tốt với một mức độ, tuy nhiên điều này có thể dễ dàng bị lạm dụng, và chúng tôi có thể kết thúc với các lớp học thực hiện các phương pháp trống hoặc vô dụng mà tất nhiên thêm mã thêm và gánh nặng cho các ứng dụng của chúng tôi. Hãy tưởng tượng bạn đang tuyên bố rất nhiều phương pháp trong giao diện duy nhất, nếu bạn thích công cụ trực quan một lớp học mà đang thực hiện một giao diện nhưng đó thực sự là cần một vài phương pháp của nó sẽ trông như thế này:

enter image description here

Mặt khác, nếu bạn đúng cách áp dụng sự phân biệt giao diện và chia giao diện của bạn trong tập con nhỏ hơn bạn có thể cho tôi chắc chắn để thực hiện những tác động chỉ cần thiết:

enter image description here

Xem! Là cách tốt hơn! Thực thi nguyên tắc này sẽ cho phép bạn có khớp nối thấp hỗ trợ khả năng bảo trì tốt hơn và khả năng chống thay đổi cao. Vì vậy, bạn thực sự có thể tận dụng việc sử dụng các giao diện và thực hiện các phương thức khi bạn thực sự cần. Bây giờ chúng ta hãy xem xét một ví dụ ít trừu tượng, nói rằng bạn tuyên bố một giao diện được gọi là báo cáo được

public interface Reportable { 

     void printPDF(); 
     void printWord(); 
     void printExcel(); 
     void printPPT(); 
     void printHTML(); 


} 

Và bạn có một khách hàng đó sẽ chỉ xuất khẩu một số dữ liệu ở định dạng Excel, bạn có thể thực hiện giao diện, nhưng bạn sẽ chỉ có để thực hiện phương pháp excel? Câu trả lời là không, bạn sẽ phải mã thực hiện cho tất cả các phương pháp ngay cả khi bạn sẽ không sử dụng chúng, điều này có thể gây ra rất nhiều mã rác do đó làm cho mã khó duy trì ..

Hãy nhớ giữ nó đơn giản và không lặp lại bản thân bạn và bạn sẽ thấy rằng bạn đã sử dụng nguyên tắc này mà không biết.

+0

Thật đáng giá để lưu ý rằng giao diện "bồn rửa nhà bếp" không hoàn toàn không có lợi thế, trong mã đó cần phải ví dụ lưu trữ một danh sách những thứ có 'Reportable' và sau đó cho chúng ăn vào một người tiêu dùng sẽ không phải lo lắng về những tính năng mà người tiêu dùng sẽ cần với bất kỳ trường hợp thực tế nào được cung cấp có thể xử lý các yêu cầu của người tiêu dùng. Không phải để nói các giao diện tập trung thường không phải là một điều tốt, nhưng có một số giao diện lớn hơn cũng có thể tốt. – supercat

3

Nguyên tắc này chủ yếu phục vụ mục đích sinh đôi

  • Để làm cho mã dễ đọc hơn và dễ quản lý.

  • Quảng bá trách nhiệm duy nhất cho các lớp học (sự gắn kết cao). Ofcourse lý do tại sao nên một lớp học có một phương pháp mà không có tác động hành vi? Tại sao không chỉ loại bỏ nó. Thats những gì ISP là về

Có vài câu hỏi mà một nhà thiết kế phải hỏi với mối quan tâm tới ISP

  • sao người ta đạt được gì với ISP
  • Làm thế nào để tôi phân tích một mã đã tồn tại đối với bất kỳ Vi phạm ISP

Để thảo luận thêm, tôi cũng phải thêm rằng nguyên tắc này không phải là 'nguyên tắc' theo nghĩa hẹp nhất, bởi vì trong một số trường hợp, áp dụng ISP để thiết kế, thay vì thúc đẩy khả năng đọc, có thể làm cho cấu trúc đối tượng không đọc được và lộn xộn với mã không cần thiết. Bạn cũng có thể quan sát điều này trong java.awt.sự kiện gói

thêm tại blog của tôi: http://design-principle-pattern.blogspot.in/2013/12/interface-segregation-principle.html

0

Để tránh những nỗ lực hồi quy, khi chỉ là một khách hàng cụ thể hoặc một sự thay đổi hành vi cụ thể. Nếu bạn đã kết hợp tất cả các phương thức hành vi của bạn tất cả trong một giao diện BIG, chỉ cần suy nghĩ về cách bạn sẽ kết thúc kiểm tra tất cả các đoạn mã mà tất cả những gì bạn đã gọi là giao diện đó, ngay cả khi chỉ có những thay đổi nhỏ xảy ra.

Đối với một lời giải thích chi tiết hơn, hãy tham khảo Interface segregation principle article

0

ISP là quan trọng.

Ý tưởng cơ bản về ISP: Khách hàng không nên bị buộc phải phụ thuộc vào các phương pháp mà nó không sử dụng.

Nguyên tắc này có vẻ logic hơn. Lý tưởng nhất là khách hàng không nên thực hiện các phương pháp, mà không được sử dụng bởi khách hàng.

Tham khảo dưới đây SE câu hỏi cho mã ví dụ:

Interface Segregation Principle- Program to an interface

Ưu điểm:

  1. linh hoạt: Trong sự vắng mặt của ISP, bạn có một giao diện Generic FAT và nhiều lớp thực hiện nó. Giả sử bạn có 1 giao diện và 50 lớp. Nếu có một sự thay đổi trong giao diện, tất cả 50 lớp học phải thay đổi việc thực hiện của chúng.

    Với ISP, bạn sẽ chia giao diện FAT chung thành các giao diện nhỏ dạng hạt mịn. Nếu có sự thay đổi trong giao diện chi tiết nhỏ, chỉ có các lớp thực hiện giao diện đó sẽ bị ảnh hưởng.

  2. Tính bảo trì và dễ sử dụng: Vì thay đổi được giới hạn ở giao diện chi tiết tốt thay vì giao diện FACT chung, bảo trì mã dễ dàng hơn. Mã không liên quan không còn là một phần của các lớp triển khai nữa.

Các vấn đề liên quan