ISP Interface-Segregation Principle

“No client should be forced to depend on methods it does not use.”

—R. Martin

This principle states that it’s preferable―following also the SRP―to create a set of little interfaces (types) highly cohesive, than fat interfaces with multiple functions in disparate domains or concerns. The client software should depend exclusively of the interface that help to achieve its goals, and no more. With bloated interfaces, covering too many domains, any change will break the whole application, or a major part of it. It will oblige the re-compilation and re-deployment of components, whenever there is a change in a non-supported functionality by a client application. This notion and the SRP is easily implemented programming components as filters.

ISP

In the above example the second solution is best. You can reuse any of the interfaces for new types that require them, and only will compromise a client with the tiny interface it needs. Although the example seems a drastic remedy, and creates a lot of objects, it is a very common solution in object-oriented designs to improve flexibility and reuse. A package with such high-usable interfaces might be included with all solutions to provide standard behavior at a very little cost.

The ISP also has its implication about concrete implementations. Again, the presence of abstract variables in modules and arguments is mandatory. Also, it’s the separation of the concrete modules from abstracts modules to achieve the most flexibility and polymorphism.

Anuncios

Responder

Por favor, inicia sesión con uno de estos métodos para publicar tu comentario:

Logo de WordPress.com

Estás comentando usando tu cuenta de WordPress.com. Cerrar sesión /  Cambiar )

Google+ photo

Estás comentando usando tu cuenta de Google+. Cerrar sesión /  Cambiar )

Imagen de Twitter

Estás comentando usando tu cuenta de Twitter. Cerrar sesión /  Cambiar )

Foto de Facebook

Estás comentando usando tu cuenta de Facebook. Cerrar sesión /  Cambiar )

Conectando a %s