Orientação a Aspectos x Padrões de Projeto

Programação Arquitetura
#1

Galera,

Defendi meu TCC ontem a tarde(passei uhuuu) sobre Padrões de Projeto(Agradeço as discussões fervorosas a respeito do assunto, refatoração, projetos em alguns post :wink: ), em duas oportunidades, uma durante o desenvolvimento e uma na apresentação, foi me indagado e sugerido sobre aspectos, não consegui chegar até essa linha de pensamento no meu TCC, mas me foi passado que Aspectos tem uma certa relação com Padrões.

Minha dúvida é que relação é essa?
Aspectos veio para resolver o que Padrões não resolvem?
Existe mesmo essa relação?

E se não for pedir muito, links a respeito dessa relação ou provável relação.

enfim qualquer informação relevante será bem vinda.

OBS: Não li ainda os artigos e posts a respeito de AOP aqui do GUJ, só pra constar, não sei se neles há algo a respeito.

#2

Parabéns cara :smiley:

Sei bem-pouco-quase-nada sobre AOP, mas, para mim, o lance básico é: AOP serve para resolver … hum … aspectos de um sistema hehe.

O exemplo dado em qualquer lugar: logging. Não faz parte da lógica do sistema, não faz parte de nenhum domain object, não faz parte das regras de negócio, … n …, e também não tem amigos. Ele é um aspecto. Ele não deveria estar no meio do seu código. As linhas de código próximas ao logging se tranformam nas almôndegas da macarronada, e não gostam disso.

Sendo o homem das cavernas que sou, fico com um pé atrás para usar AOP em qualquer outro problema que já enfrentei além de logging. Poder demais hehe, vide Genesis.

#3

[quote=LIPE]Parabéns cara :smiley:

Sei bem-pouco-quase-nada sobre AOP, mas, para mim, o lance básico é: AOP serve para resolver … hum … aspectos de um sistema hehe.

O exemplo dado em qualquer lugar: logging. Não faz parte da lógica do sistema, não faz parte de nenhum domain object, não faz parte das regras de negócio, … n …, e também não tem amigos. Ele é um aspecto. Ele não deveria estar no meio do seu código. As linhas de código próximas ao logging se tranformam nas almôndegas da macarronada, e não gostam disso.

Sendo o homem das cavernas que sou, fico com um pé atrás para usar AOP em qualquer outro problema que já enfrentei além de logging. Poder demais hehe, vide Genesis.[/quote]

Grande camarada sabe-quase-tudo hehe

Então essa parte eu até sei, logs e tal a aspectos, o que foi me indagado é realmente isso, há como padrões englobarem coisas do tipo (logs e etc) que são relacionadoa a aspectos? ou na maturidade atual dos patterns isso realmente é impossivel?

Poderia eu atualizar ou criar novos padrões que dessem conta desses tipos de coisa?
Foi me sugerido justamente pesquisas nesse sentido de integrar padrões e estes aspectos. Talves um mestrado : )

#4

oxe, não sei de nada cara, vide assinatura :smiley:

Não sei se já encontrou, mas olha aqui:
http://www.cs.ubc.ca/~jan/AODPs/
O cara diz ter implementado 17 das 23 patterns do GoF utilizando AOP (AspectJ).

Fiquei curioso, pois na minha cabeça patterns resolvem problemas comuns utilizando os objetos do domínio, então não saquei se as soluções utilizando AOP se encaixam realmente numa utopia arquitetônica a la Shoes ou são “apenas” facilitadores nas questões de desenvolvimento e manutenção.

Confesso que, ao olhar alguns exemplos, fiquei tentado em alguns aspectos (ha-ha) relacionados às factories, mas ainda nada que IoC não resolva bem.

Mister_m? Shoes?

#5

[quote=LIPE]oxe, não sei de nada cara, vide assinatura :smiley:

Mister_m? Shoes?[/quote]

Muito legal mesmo o link, vo dar uma olhada em casa, valeu

O tema já está realmente me parecendo polêmico e digno de uma pesquisa mais aprofundada a respeito, talvez começa a cair pra esses lados :slight_smile:

Se tu chama eu grito tbm… cv, shoes, Mister_m? :lol:

#6

E ai Skill!!

Também estou pingando para estes lados!!!
Se o shoes, o mister_m ou o cv escutarem nosso grito, quero aproveitar e pedir a opiniões deles quanto à

META OBJETOS!!!
Isso é realmente interessante???

Abraços!!!
Thiago

#7

[quote=Thiago Senna][quote=skill_ufmt]
O tema já está realmente me parecendo polêmico e digno de uma pesquisa mais aprofundada a respeito, talvez começa a cair pra esses lados :slight_smile:
[/quote]

E ai Skill!!

Também estou pingando para estes lados!!!
Se o shoes, o mister_m ou o cv escutarem nosso grito, quero aproveitar e pedir a opiniões deles quanto à

META OBJETOS!!!
Isso é realmente interessante???

Abraços!!!
Thiago[/quote]

é isso ae.

O legal é quando você chega num ponto, e ve que existem mais pontos a serem explorados a partir daquele.
Buscas continuas de conhecimento e aprovação :slight_smile:

#8

Parabéns :slight_smile:

É como o lipe falou. Aspectos são utilizados para evitar que coisas "externas"como logging, injeção de depdendências, segurança e outras coisas tenham que ser implementadas pelo objeto, cuja obrigação é cuidar de outras coisas (coisinhas bestas como regras de negócio :slight_smile: ) e não se preocupar com isso.

O caso de log é clássico e superutilizado como exemplo, mas quando você tem sistemas administrados de verdade e precisa gerar arquivos de log descentes, você vê a droga que é entupir seu código de

logger.debug("blabla");

Design patterns são soluções para problemas comuns, envolvem estruturar suas classes de uma maneira específica para resolver um problema definido. Os problemas atendidos por ambas podem ser os mesmos (como mostra o artigo que o lipe linkou), mas são resolvidos de maneira diferente.

Muitas vezes (leia-se: J2EE Core Patterns) padrões são utilizados em lugares onde aspectos seriam mais próprios, mas os padrões (pelo menos a classificação pattern em si) foi criada bem antes de termos tanto dinamismo que permitiu o surgimento de AOP.

#9

valeu

[quote]
É como o lipe falou. Aspectos são utilizados para evitar que coisas "externas"como logging, injeção de depdendências, segurança e outras coisas tenham que ser implementadas pelo objeto, cuja obrigação é cuidar de outras coisas (coisinhas bestas como regras de negócio :slight_smile: ) e não se preocupar com isso.[/quote]

Pergunta idiota, por que não é interessante que um objeto cuide de seu próprio log? não seria responsabilidade dele cuidar de tudo que é dele (algo meio filosofico) :slight_smile:

[quote]
Muitas vezes (leia-se: J2EE Core Patterns) padrões são utilizados em lugares onde aspectos seriam mais próprios, mas os padrões (pelo menos a classificação pattern em si) foi criada bem antes de termos tanto dinamismo que permitiu o surgimento de AOP.[/quote]
Então padrões e aspectos são a mesma porcaira? :slight_smile:

Ponto legal este seu.
Não seria a hora então de rever os padrões?
Propor atualizações para que atendam o dinamismo atual?
Em vez de criar mais um conceito, englobá-los?

#10

Secamente falando, este tipo de coisa produz código ilegível ao longo do tempo, e provoca um aumento monstruoso nas dependências e acoplamento.

Molhadamente falando, se você pensar assim vai querer que seu objeto gerencie sua própria tabela no SGBD, sua própria interface…

Não!

Padrões são soluções consagradas para problemas, aspectos são um meio de resolver problemas (não receitas de bolo).

os padrões que citei, em especial, vivem mudando de nome ou conceito. Eles foram feitos para suprir gambiarras na plataforma e conforme as cosias vão avançando e esses buracos deixam de existir, os padrões ficam sem sentido :wink:

#11

[quote=pcalcado]
Secamente falando, este tipo de coisa produz código ilegível ao longo do tempo, e provoca um aumento monstruoso nas dependências e acoplamento.
Molhadamente falando, se você pensar assim vai querer que seu objeto gerencie sua própria tabela no SGBD, sua própria interface… [/quote]

tava zoando nessa parte :slight_smile:

Nesse meio tempo fui ler, e realmente aspectos veio para arrumar o que nada arrumava ainda :slight_smile:

[quote]
os padrões que citei, em especial, vivem mudando de nome ou conceito. Eles foram feitos para suprir gambiarras na plataforma e conforme as cosias vão avançando e esses buracos deixam de existir, os padrões ficam sem sentido ;)[/quote]
Gambiarras hehe, massa…

A analogia que você é na questão de atualizar os sistemas? refactoring? e ai não haveria necessidade de ter os padrões porque estaria arrumando de outra forma é isso? essa parte realemtne não entendi.

#12

A primeira frase eu não entendi nada :slight_smile:

Você quer saber como se livrar dos padrões quando forem desnecessários? Se o sistema aidna está em manutenção, “vivo”, refactoring é uma boa.

#13

Na prática, oque eu vi sendo feito com AOP envolve adicionar comportamento e estado que fogem das responsabilidades e preocupações dos objetos, coisas como ACLs, dados de performance, anexos, preferencias do usuario; ou então colocar decorators em qualquer objeto sem necessidade de factories ou wrapping explicitos.

Via de regra, AOP torna os padrões Decorator e Open Type mais transparentes, práticos e flexiveis.

Isso ignorando os pointcuts mais complexos que , eu pelo menos, acho que tem muito pouco uso.

#14

acho que AOP é um paradigma novo para conseguir modularizar comportamentos que com orientação a objetos não conseguem resolver. Ex: log

Mas caso voce queira mudar seu sistema de log, tera que mudar em todos os objetos.
Agora nao sei a relacao com padroes.

#15

[quote=pcalcado]
A primeira frase eu não entendi nada :slight_smile:
Você quer saber como se livrar dos padrões quando forem desnecessários? Se o sistema aidna está em manutenção, “vivo”, refactoring é uma boa.[/quote]

hehe, foi no sentido do que vc falou de retirar os padrões, queria saber se você retira os padrões de uma arquitetura já pronta?
Ou falou no sentido de não usar padrões durante a projeção?

é que engoli algumas palavras lá na frase heheh

#16

[quote=louds]
Via de regra, AOP torna os padrões Decorator e Open Type mais transparentes, práticos e flexiveis.[/quote]

Mas ai continuam sendo padrões então, só que implementados de outra forma :slight_smile: correto?

#17

essa parte foi só pra zoar :slight_smile:

#18

skill_ufmt,

Meu TCC também é sobre padroes de projeto, no entanto ainda não fechei o escopo do meu projeto, pois estou tendo dificuldades e gostaria quem sabe de uma ajuda. Sobre qual tema especifico foi o seu TCC? Ele é só sobre o uso dos padroes para desen
volvimento ou cuida de um problema especifico? No meu, gostaria de falar sobre o uso de padroes em todo processo de software, focando porém no desenvolvimento e reuso.
Caso vc tenha uma dica, seria de muita ajuda.

Desde já agradeço.

#19

É importante lembrar que AOP deve ser utlizado mais para coisas de “infra-estrutura”, como logs, caches, segurança. Modelar suas regras de negócio em aspectos não é uma boa prática, visto que elas devem interagir com seu modelo de objetos, e não ficarem isoladas em aspectos.

Se houver necessidade de adicionar/remover comportamentos a objetos de negócio em runtime, considere o uso do pattern Decorator. Os decorators podem ser aplicados for fábricas, container de IoC ou mesmo aspectos. :smiley:

#20

Bem…
A programação orientada a aspectos (POA) é uma extensão da programação orientada a objetos (POO). A programação orientada a aspectos surgiu com o intuito de suprir as necessidades de se modularizar os sistemas que apresentam interesses transversais (crosscutting concerns), tais como logging, segurança, tratamento de exceções, etc. Esta melhoria na modularização dos interesses da aplicação é possível pelo fato de existir novos mecanismos de abstração e composição que facilitam a modularização destes interesses transversais, tais como: aspectos, conjuntos de junção (pointcuts), declarações inter-tipos e adendos (advices).

Embora o uso de aspectos possa auxiliar na modularização de interesses transversais, seu uso pode ocasionar alguns problemas específicos, Alguns exemplos de uso de aspectos que não são aconselháveis são: muitos advices que se referenciam a um mesmo pointcut, pointcuts duplicados, muitas definições de pointcuts anônimos, pointcut de um aspecto ser usados por outro aspecto, etc.

Estes problemas normalmente dificultam o entendimento e o reuso em todas as fases de um processo de desenvolvimento, além de aumentar o custo do desenvolvimento e da evolução do software. Pode-se minimizar esses problemas através da identificação de seus sintomas e da remoção das causas destes problemas. Também chamados como bad smells, os sintomas identificados no sistema podem ser vistos como sinais de alerta para os problemas existentes, e, preferencialmente, devem ser corrigidos através da aplicação de refatorações definidas para cada bad smell.
Os bad smells em orientação a aspectos pode ser considerada como defeitos específicos em um projeto deste paradigma está relacionada com defeitos específicos de projeto deste paradigma, talvez estes sejam de acordo com as novas noções e as maneiras diferentes de pensar em desenvolver o software.

Em um sistema orientado a aspectos, além de ter bad smells do próprio paradigma, também contêm bad smells da linguagem nativa. Como por exemplo, um projeto escrito em AspectJ [Kiczales et al., 1997], uma extensão da linguagem de programação Java, que pode conter tanto bad smells de orientação a aspectos como de Java (Orientação a Objetos).

Logo, esses bad smells como disse, são técnicas que devemos evitar, e já existem vários padrões documentados sobre essas técnicas e a solução de cada.

:roll: