SOLID (4/5)
Um dos conceitos mais solicitados hoje no mundo do desenvolvimento é o conhecimento de SOLID. Nesse post, vamos explorar o ISP - Interface Segregation Principle.
O ISP (Interface Segregation Principle) ou Princípio da Segregação de Interfaces se baseia na ideia de evitar a criação de interfaces grandes, que forçam os clientes implementar métodos que não serão utilizados. O ISP propõe que as interfaces sejam pequenas e específicas, permitindo que os clientes implementem apenas os métodos que realmente necessitam.
Um exemplo prático é o seguinte: Imagine uma interface para um repositório de Logs. Se tivermos uma interface baseda em CRUD, ela poderia ser assim:
public interface ILogRepository
{
void Create(Log log);
Log Read(int id);
void Update(Log log);
void Delete(int id);
}
Outro caso muito comum é ver interfaces genéricas, sendo mal empregadas e ferindo os princípios de SOLID, principalmente o ISP. Por exemplo, uma interface que define métodos para manipulação de dados, mas que não são relevantes para todos os tipos de dados. Isso pode levar a implementações desnecessárias e complexidade no código.
public interface IDataRepository<T>
{
void Add(T item);
T Get(int id);
void Update(T item);
void Delete(int id);
}
Nesse caso, a interface IDataRepository<T> é genérica demais e não é aplicavel para todos os casos, como no exemplo do repositório de Logs, isso porque implementar os métodos de Update e Delete não faz sentido para esse repositório.
Então, podemos criar uma interface específica para ele:
public interface ILogRepository
{
void Create(Log log);
Log Read(int id);
}
Dessa forma, evitamos que os clientes sejam obrigados a implementar métodos que não são necessários para a construção do registro de Logs.
O ISP nos ensina que “clientes não devem ser forçados a depender de interfaces que não usam”. Ao criar interfaces menores e mais específicas, tornamos nosso código mais flexível, testável e fácil de manter.
No próximo post da série SOLID, abordaremos o DIP (Dependency Inversion Principle)!