OO: Responsabilidades, Modelagem e Dependências

Ao projetar um software orientado por objetos, é possível usar três abordagens complementares:

Responsabilidade

Criar classes focadas (coesas) e com responsabilidades definidas é um dos objetivos das técnicas de Orientação por Objetos.

No clássico Applying UML and Patterns, Craig Larman descreve os princípios GRASP (General Responsibility Assignment Principle), que indicam várias maneiras de distribuir responsabilidades às classes que estão sendo projetadas.

Larman também aponta para a técnica Responsibility Driven Design (RDD), de Rebecca Wirfs-Brock. Ele cita:

Pense em objetos como pessoas com responsabilidades que colaboram com outras pessoas para fazer coisas. RDD enxerga projeto OO como uma comunidade de objetos colaborativos e responsáveis.

Uncle Bob fala sobre Single Responsibility Principle (SRP). De acordo com o SRP, um objeto deve ter uma, e apenas uma, responsabilidade.

A técnica CRC usa cartões para ajudar a descobrimos as Classes do nosso software, Responsabilidades de cada uma e as Colaborações entre essas classes. É uma prática recomendada no XP.

Modelagem

Modelar o domínio do problema que estamos resolvendo é um dos objetivos principais da Orientação por Objetos.

Na verdade, quando estamos pensando em termos de distribuição de responsabilidades, estamos modelando o nosso software. A sopa de letrinhas GRASP, RDD, SRP e CRC tem foco em responsabilidades, mas são técnicas de modelagem.

Criar um bom Domain Model, um modelo de alto nível do problema que queremos resolver, é uma das técnicas recomendadas por metodologias como FDD, DDD e RUP. O Domain Model ajuda na comunicação com os clientes, que são os especialistas no domínio.

Domain Driven Design (DDD) parte do Domain Model mas foca na importância de uma linguagem única na comunicação entre desenvolvedores e os clientes.

Gerenciamento de Dependências

Uncle Bob foca sua interpretação dos fundamentos de Orientação por Objetos em uma abordagem um pouco diferente. Além de modelagem (e responsabilidades), muita atenção deve ser dada às dependências entre as classes.

Os princípios SOLID descrevem algumas pontos importantes para um bom gerenciamento de dependências. O Single Responsibility Principle, mencionado acima, faz parte desses princípios.

Outro princípio SOLID, o Dependency Inversion Principle, recomenda que a dependência de objetos de módulos de alto nível em relação a módulos de nível mais baixo não deve ser direta. Essa dependência deve ser invertida, fazendo com que os módulos de alto nível dependam de abstrações.

A técnica de Injeção de Dependências é uma maneira elegante de atingir o princípio de Inversão de Dependências. Um efeito colateral interessante dessa técnica é a simplificação de testes unitários.

A abordagem de gerenciamento de dependências faz muito mais sentido quando evitamos criar softwares monolíticos e utilizamos módulos. A modularização facilita a manutenção, isola dependências e, se bem projetados, habilita o reuso. Alguns Padrões de Modularização foram documentados e estão altamente relacionados com Orientação por Objetos.

Anúncios