Orientação sob outro Aspecto

Em um passado um tanto recente, imensos sistemas vagavam pelos computadores primitivos. Sua forma, classificada pelos historiadores como estruturada (ou procedural), permitia inúmeras horas de lazer aos desbravadores da época que seguiam seu mapa do tesouro incluindo famigerados GoTo's.

Cansados da aventura, era necessário organizar internamente esses sistemas. Uma organização que representasse melhor a realidade. A separação de entidades. Absolutas e independentes. Inicia-se a era da Orientação a Objetos (OO).

Um mundo perfeito onde cada objeto (ou classe) tem responsabilidades específicas, como os diversos departamentos de uma empresa. Cada qual responsável por executar um conjunto de atividades, o verdadeiro 'core-business' do departamento.

Com o passar do tempo, a empresa começa a crescer. Aqueles simples "departamentos", sempre perfeitos nos exemplos OO, começam a receber atividades adicionais. Controle, monitoramento, segurança, auditoria. E no mais novo emaranhado de atividades fica difícil distinguir quais as atividades core do departamento, as únicas necessárias para o desempenhar correto de sua função. Fora da analogia, começamos a perder de vista qual o único código necessário para cumprir com as responsabilidades daquela classe.

A idéia inicial da Orientação a Objetos começa a ser manchada.

Agora, se o objetivo é mantermos classes responsáveis apenas por suas atividades, por que não separarmos as responsabilidades adicionais impostas à classe por circunstâncias externas?

É disto que trata a Orientação a Aspectos.

E com ela, a metodologia de implementação denominada Programação Orientada a Aspectos (do inglês, Aspect-Oriented Programming, AOP).

Como para minimizar sua primeira reação, a AOP não tem o objetivo de substituir a OOP (Programação Orientada a Objetos). Não será necessário esquecer os conceitos anteriores.

Uma vez que a roda foi inventada, a AOP tem por objetivo melhorar o projeto e "implementação" visando uma melhor produtividade, qualidade e flexibilidade no uso da roda.

E isto é possível com a separação das responsabilidades das classes do sistema. Cada uma cumprindo com suas funções. Integradas, mas absolutas. E todas as atividades adicionais, definidas como responsabilidade de todas as classes de um sistema ou pelo menos parte delas, separadas em aspectos.

Algumas classes têm responsabilidades muito simples, como se fossem o Departamento do Café. O objetivo? Fornecer café.

Mas você pode olhar na sua implementação e descobrir que o Departamento do Café ganhou algumas responsabilidades extras. É responsável por registrar o nome de cada pessoa que pegou um café. Precisa garantir que quem está no departamento é mesmo funcionário da empresa. Precisa informar que o fornecimento de café está ativo. O tempo gasto por fornecimento de café.

Não seria difícil vermos em uma reestruturação, ou refactoring, do Departamento do Café a necessidade de se eliminar uma atividade, considerada menos prioritária frente ao caráter administrativo e corporativo das outras atividades: fornecer café.