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

10 comentários sobre “OO: Responsabilidades, Modelagem e Dependências

  1. Excelente post, Alexandre.

    Pegando ganho no último paragrafo, é possível ter código modularizado e bem isolado em um sistema monolitico. Talvez por ser algo mais sútil e de fácil acesso tende-se a não ligar muito para isso, mas frameworks de IoC/DI como Spring e CDI ajudam a diminuir o acoplamento incentivando a programar orientado a interfaces e abstrações.

    Faz sentido?

    • Faz sentido, Rafael!

      Usar IoC/DI tende a tornar o seu código potencialmente modularizável, mesmo se for uma base de código só.

      Mas um problema que vejo em uma base de código monolítica é que, mesmo usando IoC/DI, é muito fácil injetar algo que não devia, ainda que escondido atrás de uma interface. Injetar uma DAO de estoque em um Controller de vendas não deveria ser possível.

      Aqui não penso em monólitos contra micro-serviços, mas contra módulos (jars) em uma mesma JVM.

      Mesmo modularizando com jars, é possível injetar uma dependência da minha dependência (transitiva) que deveria estar apartada. Aí que entram soluções como OSGi, que sofisticam a modularização para a JVM.

      Claro, essas preocupações valem para bases de código um pouco maiores. Além disso, um monólito é mais rápido de evoluir, algo importante no começo de um projeto.

  2. Sabe, acho que não deveríamos investir grandes esforços em blindar tecnologias e frameworks para evitar más práticas como estas, mas sim investir tempo capacitando e compartilhando conhecimento com a equipe sobre princípios de OO, encapsulamento, coesão, SOLID, padrões de projeto, testes automatizados etc. Isso já diminuiria muito problemas desse tipo.

    O que acha?

  3. Acho que conhecer de boas práticas é importantíssimo. O mais importante!

    Mas acho que ferramentas que nos ajudam a evitar erros, gambiarras e atalhos são importantes também.

    A própria técnica de OO e a plataforma Java são ferramentas que nos blindam de variáveis globais e alocação de memória, por exemplo…

    Acho que OSGi, por exemplo, é uma boa maneira de reforçar restrições arquiteturais. E isso acaba nos ajudando!

  4. Faz todo sentido o que você diz. Mas observe que mesmo usando estas ferramentas ainda caimos nos mesmos problemas. Creio a conscientização e informação sejam as melhores armas que temos – se tiver o apoio das ferramentas e tecnologias melhor ainda.

    • É verdade… Sempre damos aquele jeitinho… E acabamos xingando as ferramentas!

      O mais importante é entender o porquê das técnicas e ferramentas, né?

      • Por aí mesmo. Investir na base sólida dos iniciantes pode não ter um retorno imediato, mas vale a pena no médio-longo prazo.

Deixe um comentário

Preencha os seus dados abaixo ou clique em um ícone para log in:

Logotipo do WordPress.com

Você está comentando utilizando sua conta WordPress.com. Sair / Alterar )

Imagem do Twitter

Você está comentando utilizando sua conta Twitter. Sair / Alterar )

Foto do Facebook

Você está comentando utilizando sua conta Facebook. Sair / Alterar )

Foto do Google+

Você está comentando utilizando sua conta Google+. Sair / Alterar )

Conectando a %s