Interação e Substituição de Objetos

Ter uma visão clara de como os objetos interagem é um fator fundamental no desenvolvimento de software orientado a objetos. É até mais importante do que saber como cada objeto funciona isoladamente.

Pensando que um software O. O. é uma espécie de teia de objetos que se interconectam, fazendo de sua interação o fator gerador do comportamento do software, mudar seu comportamento será como plugar novos objetos no lugar dos que estavam, bastando para isso que o plug esteja no formato esperado.

Simular este tipo de comportamento no software requer que tomemos algumas medidas de análise bem pensadas, estudadas, para que tudo se encaixe da maneira apropriada.

Tipos de Substituição

A substituição dos objetos pode não servir apenas para mudar o comportamento do software. Ela pode servir, principalmente, para analisar o comportamento do mesmo.

Se ao invés de plugar um objeto que precise desempenhar determinada tarefa você plugar outro que registre ou exponha como se deu a interação dos outros objetos com ele, você terá uma excelente ferramenta para análise comportamental.

Caso o objeto precise desempenhar tarefas necessitando da colaboração de outros, sendo requerida a passagem de mensagens para os mesmos, seu objeto pode simulá-la sem que seja necessário qualquer esforço adicional.

Você pode substituir o comportamento do objeto (plug) real pelo comportamento que você deseja, apenas para investigar o comportamento dos objetos (plugues) em que ele estará conectado.

Objeto Substituto

Como disse, para que o objeto substituto possa ocupar o espaço do original, basta que ele apresente o mesmo formato. Este formato do objeto pode ser descrito também como a interface do objeto, ou seja, a maneira com a qual é feita a interação com ele.

Mantendo a mesma interface, os objetos interconectados a ele não precisam ser modificados, podendo lhe referir sempre da mesma maneira.

Mock Object, Proxy e outros nomes

Ao objeto substituto são dados diversos nomes, como Mock Object (geralmente como é referenciado em TDD), Proxy (Padrão GoF), Surrogate, etc. Apesar de haverem diversas variações na maneira como são usados (por exemplo, como virtual proxies, remote proxies, smart references, etc.), todos se baseiam no sentido da substituição do objeto original.

Em suma

A substituição dos objetos para análise, teste ou mudança do comportamento é um dos conceitos mais significativos para o entendimento da criação de software testável e de objetos reutilizáveis. Entender as variações possíveis e os benefícios e problemas trazidos por cada implementação traz uma grande maturidade ao desenvolvedor e potencializa o crescimento e a manutenção de software, levando à um custo de alteração mais baixo e a melhoria da "testabilidade" do mesmo.

Glossário Rápido

Eu não espero reinventar a roda e ter que explicar todos os conceitos, metodologias, processos, siglas, etc. que surgirem neste blog. Diversos outros autores já reservaram seu tempo fazendo isso. Meu intuito aqui é prover uma definição suscinta para quem não quer ler todo o conteúdo encontrado no Wikipedia ou no site mais próximo, encontrado talvez numa pesquisa no Google.

Metologias Ágeis

É o nome dado ao conjunto de metologias dissidentes do Manifesto Ágil. Exemplos: Extreme Programming, Scrum, Crystal, Feature-Driven Development, etc.

Manifesto Ágil

Um conjunto de princípios que visa potencializar o relacionamento das pessoas envolvidas no projeto do software (desenvolvedores, gerentes, clientes, etc.) , de forma a trazer benefícios para o mesmo, através de suas relações e práticas.

Práticas Ágeis

Práticas comumente adotadas pelas metodologias ágeis, como Desenvolvimento Incremental, Liberação Frequente, etc.

eXtreme Programming (XP)

Apesar de não parecer, não é nada de novo. Juntou-se práticas antigas de uma forma que pudesse melhorar o desenvolvimento de software, enxugando ao máximo as tarefas burocráticas e que não estavam ligadas diretamente à programação. As práticas foram unidas de forma que uma sustentasse a outra, cobrindo eventuais problemas relacionados à prática isolada das mesmas. O nome "extrema" vem do sentido de que a adoção das práticas é um tanto radical em relação ao desenvolvimento de software tradicional.

Scrum

Outro dissidente do Manifesto Ágil, o Scrum possui uma série de regras, papéis e documentos bem definidos, a serem seguidos pela equipe participante do projeto. Possui terminologia própria (apesar das práticas e papéis não serem novos) que ajudam no entendimento do processo e em sua adoção. Tem foco mais na parte administrativa que na de implementação.

Test-Driven Development (TDD)

Prática em que se escreve código para testar uma funcionalidade no software, antes que o código que implementa esta funcionalidade tenha sido escrito. Envolve diversos outros fatores como design, refactoring, integração, automação de tarefas e diversos tipos de teste, se tornando muito mais abrangente de que a simples definição de sua prática. O TDD é utilizado pela maioria das metodologias ágeis.

Refactoring

Consiste em melhorar o código existente através de sua reorganização, sem que sua funcionalidade seja modificada. A cada tipo de reorganização foi dado um nome (ou frase) para expressar sua intensão e facilitar a comunicação entre os desenvolvedores.

Design Patterns

Os Padrões de Projeto são modelos de organização e interação de classes, percebidos por desenvolvedores de software ao longo do tempo, que foram catalogados e nomeados para facilitar sua indentificação.

Gang of Four (GoF)

Apelido dado ao grupo de autores do livro "Design Patterns - Elements of Reusable Object Oriented Software", composto por Erich Gamma, Richard Helm, Ralph Johnson e John Vlissides. O livro é uma espécie de catálogo de padrões de projeto de software (Design Patterns) , sendo uma ferramenta indispensável aos bons analistas de sistemas e arquitetos de software.

Acoplamento

Nível de inter-dependência entre módulos (ou outras partes) do software. Quanto menor, melhor (mais reutilização).

Coesão

Grau de "singularidade" de um módulo (ou outras partes) do software. Se um módulo desempenha uma única função ou tem um único propósito, ele é altamente coeso.

KISS

Princípio que tem como objeto sempre manter as coisas bem simples. Sua abreviação possui variações, como Keep It Small and Simple ("mantenha as coisas pequenas e simples"), ou - a minha preferida - Keep It Simple, Stupid. ;)

YAGNI

Princípio cujo objetivo é que não se crie coisas das quais você não tem certeza absoluta se vai precisar. Sua abreviação se refere You Ain't Gonna Need It (algo como "você não vai precisar disto").

DRY

Princípio que visa reduzir a repetição, a duplicação, de trabalho. Vem de Don't Repeat Yourself (algo como "não se repita").

Fixture

Conjunto de dados de teste que são compartilhados entre diversos testes.

Outros termos serão incluídos aqui à medida em que forem sendo referenciados pelos artigos do blog.