NET Framework to mix and match interfaces to give a program access to all and only the members it needs is an incentive to create interfaces with very few members. If it turns out that the credit-checking program needs more members in the ICustomerCreditSummary interface, then you have two options: Either the ICustomerCreditCheck interface can be expanded to include the additional members, or the credit checking program can take advantage of some other interface on the Customer object that includes the members.
You can change the definitions of those other members (modify their parameter lists, change their return type, even rename or delete the member) without having to recompile the credit-checking program. The benefit here is that changes to Customer members outside of the ones listed in ICustomerCreditCheck interface have no effect on the credit-checking program. The program that performs credit checks would now declare any variable that uses the Customer object using the ICustomerCreditCheck interface, thereby limiting the program's access (and exposure) to just the members of the Customer object it requires:Ĭust = CustomerRepository.GetCustomerForCreditCheck("A123")ĬreditRating = cust.SummarizeCreditHistory() actual methods/properties/events that support the interfaces' members The Customer class would use that interface, along with the other interfaces, like this to expose different interfaces for different programs: The interface for credit checking (which I've cleverly called ICustomerCreditCheck) might look like this:įunction SummarizeCreditHistory() As CreditEnum To implement ISP, you'd design a separate interface for each task.
Principle of segregation update#
The programs that update Customer information need access to the Customer's properties (name, address, preferences and so on) but don't need any of the Customer object's methods the program that creates sales orders only needs access to those properties required by a sales order a program that does credit checks only needs Customer object's CustomerId property and SummarizeCreditHistory method. Each of these programs has different needs. This means that a useful object that's used by multiple programs will implement a number of interfaces, with each of the interfaces exposing only the members necessary for, potentially, one of those programs.įor example, there are probably lots of programs that use the Customer object: some programs use the Customer object as a way to update customer information others use the object as part of creating a sales order still, others use the Customer object as part of running a credit check on the customer. To solve this problem, ISP mandates that the list of members (methods/properties/events) exposed to any particular program by some object should be limited to only the members that the program actually uses. ISP says that's dumb: It should only be necessary to recompile a program if a method that the program actually uses changes. When it becomes necessary to change the interface for one of those useful objects (for example, by adding a new parameter to an existing method), all the classes that use that object have to be recompiled even if they don't use that method.
/Mendel-s-Law-of-Segregation-58a46d333df78c4758531411.jpg "principle of segregation")
The Interface Segregation Principle (ISP) addresses a problem common to objects that are used in multiple ways in multiple places - that is to say, a problem that occurs with objects that are so useful that they're used in many places. Taken together, interface segregation and dependency inversion suggest that the best process for designing applications is the reverse of the process that developers have traditionally followed. While all of these principles are valuable, the last two form the greatest challenge to developers.
The current "best practices" for application development is to follow the five principles summarized in the SOLID acronym: Separation of concerns, Open to extension but not modification, the Liskov substitutability principle, Interface segregation and Dependency inversion.
0 kommentar(er)
