Coesão de Componentes
Este tópico procura falar sobre "quais classes pertencem a quais componentes", Robert busca explorar três princípios, sendo:
- REP - Princípio da Equivalência do Reúso/Release (Reuse/Release Equivalence Principle) - coesão dos itens, versionamento e propósito;
- CCP - Princípio do Fechamento Comum (Common Closure Principle) - SRP e classes relacionadas juntas;
- CRP - Princípio do Reúso Comum (Common Reuse Principle) - ISP e critérios sobre itens do componente.
REP
A granularidade do reúso é a granularidade do release.
Os gerenciadores de dependência (como maven) surgiram e cresceram em um contexto onde inúmeros componentes também surgiram. Hoje, existe o reúso do software. Martin sugere que o REP parece óbvio, dizendo que as pessoas só devem utilizar componentes que tenham um processo de versionamento e release. Ademais, todo componente deve ter um propósito geral, de forma que seus módulos compartilhem e persigam ele, logo, este princípio sugere a coesão dos items de um componente.
CCP
Reúna em componentes as classes que mudam pelas mesmas razões e nos mesmos momentos. Separe em componentes diferentes as classes que mudam em momentos diferentes e por diferentes razões.
Esse princípio lembra o SRP do SOLID, mas para componentes. De forma geral, um componente não deve ter várias razões para mudar. Sempre que uma classe mudar fazer com que outra classe mude, esses classes devem estar dentro do mesmo componente.
CRP
Não force os usuários de um componente a dependerem de coisas que eles não precisam.
Esse princípio busca definir quais classes e módulos devem ser colocados em um componente. É normal conter em um componente classes que tenham dependências entre si.
Também busca definir quais classes não devem estar em um componente. Se um componente usa outro componente, e esse outro componente muda, é provável que o componente inicial também tenha que mudar. Portanto, um componente só deve depender de outro caso precise de diversas funções de outro componente. Em casos onde o componente inicial dependa de poucas coisas, é preferível que essas coisas sejam do próprio componente, pois o custo de depender completamente de algo grande que só precisa oferecer algo pequeno não vale a pena. Esse princípio lembra do ISP.
Não dependa de coisas que você não precisa.
O diagrama de tensão para coesão de componentes
Considerando a figura abaixo, caso você foque em REP e CCP, muitos releases desnecessários serão gerados. Caso você foque em REP e CRP, haverá muitas mudanças de componentes. O arquiteto deve entrar no centro desse triângulo, equilibrando os pesos para cada princípio.
Conclusão
É importante notar que há sempre uma força oposta no uso de um componente. É uma escolha de trade offs e que depende da maturidade e do momento de um projeto/componente.
Top comments (0)