Lembrando que esse "blog" contém o meu entendimento sobre o tema que, naturalmente, pode conter erros e que serão resolvidos com a noção dos mesmos.

O que é um componente?

Acho válido começar o blog por essa pergunta, apesar de ser um tanto vaga e genérica, mas restringindo ao escopo do livro pode fazer mais sentido. No capítulo 12 do livro, Bob diserta sobre o que é um componente e contextualiza o porquê deles. Nos dois capítulos seguintes, 13 e 14, há explicações sobre como os componentes são construídos, como devem se comportar uns com os outros e a maneira recomendada para a estruturação destes, num projeto de "software".

O que é um componente?

Uncle Bob define como:

Components are the units of deployment. They are the smallest entities that can be deployed as part of a system. In Java, they are jar files. In Ruby, they are gem files. In .Net, they are DLLs. In compiled languages, they are aggregations of binary files. In interpreted languages, they are aggregations of source files. In all languages, they are the granule of deployment.

Já Fielding, em sua tese de doutorado, que eu estava lendo em simultâneo e não tem muito a ver com o livro citado, autor tão famoso REST, define componente como:

A component is an abstract unit of software instructions and internal state that provides a transformation of data via its interface.

E completa com:

A component is defined by its interface and the services it provides to other components, rather than by its implementation behind the interface.

Essa frase é importante para entender o conceito principal: um componente é um interface simplificada para um comportamento maior e mais complexo.

Quando Bob escreve a frase a seguir, ele deixar essa questão mais clara. **

Well-designed components always retain the ability to be independently deployable and, therefore, independently developable.

Fielding adiciona outros elementos aos componentes como conectores, que fazem a transferência de informações entre componentes e datum, que são essas informações transferidas.

Na seção de "software architecture", há mais questões relacionadas que ainda não são do meu intendimento total, devido, penso eu, a pouca vivência com a questão de "componetização".

Já tendo o conceito de componente em mente, agora é necessário conhecer como organizar as classes dum projeto de “software” conforme os princípios de coesão dos componentes. Esses princípios aplicados corretamente trazem a vantagem de manter o sistema mais "saudável", contudo, sua aplicação incorreta ou exagerada mais focada num dos princípios, podem fazer justamente o oposto que uma boa arquitetura de software propõe.

O restante do capítulo o autor conta um pouco da história dos componentes, como eram pensados e usados, problemas enfrentados e como o grande aumento do poder de processamento resolveu um dos grandes citados.

Como li uns capítulos e não escrevi no "blog", um detalhe deve ficar subentendido: o "jeito" de desenvolver "software" proposto pelo "Clean Architecture" é através de componentes independentes, com versões estáveis e vir a ser utilizada por componentes clientes. Essa abordagem é chamada de "Acyclic Dependencies Principle" e "top-down design" e será comentada em blogs futuros.

Em resumo é isso; um capítulo curto, porém muito importante em minha visão por oferecer um conceito que julgo ser bem importante para o entendimento do restante dessa obra tão referenciada.

Nos dois próximos capítulos, que já li 😉, há um maior detalhamento do porquê os componentes são importantes, como deve ser feita a interligação entre eles, princípios que o autor acredita que os norteiam, etc. Logo irei escrever resumo sobre os dois.

Agradeço por ler esse meu pequeno resumo, mesmo sendo algo até um pouco egoísta, alguém pode aproveitar esse conteúdo mais "crú" para ter um insigh sobre o tema lido ou decidir ser a hora de engajar nessa leitura.

Fique a vontade para curtir, compartilhar, comentar, criticar e dar dicas sobre o tema ou o blog, ambas são muito bem-vindas.