Já ouvi muitas vezes sobre a programação orientada a aspectos, principalmente que é a tecnologia de "próxima geração" em programação e vai "matar" o OOP.
Está certo? OOP vai morrer ou o que pode ser a razão disso?
Morte da tecnologia OOP [fechada]
Respostas:
Sempre que alguém lhe disser que uma tecnologia de software matará outra ou dominará todo o mercado / uso / público, lembre-se:
Um ecossistema sadio (dinâmico, mas estável) é constituído por uma variedade de espécies amplamente diferentes.
Isso significa que qualquer nova tecnologia sensacionalista passará pela curva do hype e, no final, descobrirá seu (s) objetivo (s) específico (s) através do tempo e da experiência com ela.
Isso também significa que um conceito tão extremo como a programação orientada a aspectos é útil se necessário, ou seja, nem sempre e não com muita frequência, por causa dos custos implícitos.
Mas ele já tem seu lugar, como OOProgramming, como programação genérica, como programação funcional, como programação procedural, etc.
Você percebeu que os idiomas mais usados (e controversamente populares) e amplamente difundidos na vida real "não são puros"? Isso porque permitir vários paradigmas os torna mais flexíveis à mudança de contexto ao longo do tempo e preenchem mais nichos de uso.
11
+1 para 'não puro'. Linguagens OOP puros são notavelmente morto, exceto para muito nicho utilizações / acadêmicos.
—
Jv42
O que consideraríamos uma linguagem OO pura? Conversa fiada?
—
Zhehao Mao
OOP não vai morrer por causa do AOP. AOP agrega algum valor, mas vive em perfeita coexistência com OOP. Não acho que a programação funcional acabe com o OOP. OOP é bom demais para muitos tipos de domínios problemáticos, não faria sentido substituí-lo pelo paradigma funcional.
Isso é altamente subjetivo. Eu não acho que a OOP seja uma boa opção para um domínio de problemas específico, é uma boa maneira de como um desenvolvedor específico faz uma solução. OOP não vai morrer porque os desenvolvedores não podem fazer mudanças de paradigma.
—
Raynos
O exemplo clássico em que a OOP é uma boa opção são as GUIs. É difícil imaginar uma API para um kit de ferramentas da GUI que não seja OO, mesmo que a linguagem não seja. (É verdade que não é assim que o termo domínio do problema geralmente é usado) Para dar um exemplo de um domínio do problema real em que a OOP é uma boa opção: automação de armazém. Modelar os veículos de armazenamento e recuperação e suas atividades é onde o OOP parece um ajuste natural.
—
user281377
@ammoQ, as GUIs são horríveis quando expressas em OO. Essa é a razão pela qual todas as APIs estão mudando para DSLs (WPF e similares). Não é difícil imaginar, digamos, Tk - nenhum rastro de OOP lá, mas ainda é ótimo (para programação, não para a aparência), muito melhor do que qualquer um dos kits de ferramentas Java OO sobrecarregados. OOP se encaixa muito bem em qualquer simulação baseada em agente (como as que você listou), mas é uma pequena proporção dos problemas existentes.
—
SK-logic
Olhando para os primeiros exemplos de tk que eu pude encontrar, como isso não é OO? No tutorial: "Widgets são objetos, instâncias de classes que representam botões, quadros e assim por diante". tkdocs.com/tutorial/concepts.html Ainda mais, as DSLs são muito dependentes da programação OO. Então, eu realmente não estou entendendo o que você está tentando dizer?
—
Inca
@ Sk-logic, @ammoQ, @Raynos, @jkocking, promovi-o para uma questão própria: programmers.stackexchange.com/questions/88385/… Eu ficaria muito interessado em ter mais explicações sobre isso, estou muito interessado em aprender.
—
Inca
Resposta curta: Não, acho que não.
Resposta mais longa: Pelo que entendi da AOP, não é um paradigma de programação em si (por exemplo, não substitui a OOP), mas mais do que isso, um kit de ferramentas que ajuda você a escrever métodos mais curtos, classes mais simples e de responsabilidade única , etc. Mas não substitui OOP.
O que substitui (pelo menos em parte) ou adiciona ao OOP é a programação funcional, que na verdade é um paradigma de programação diferente (embora possa ser misturado ao OOP, por exemplo, na linguagem de programação Scala ). Ele prefere estruturas de dados imutáveis e todos os tipos de recursos sofisticados que tendem a frustrar os desenvolvedores de OOP, principalmente quando se trata de concorrência.
Funcional <-> Imperativo é a linha. OOP é paralelo a ele. Eu acho que o procedimento está do outro lado do POO, mas não tenho certeza. Claro que é divertido que paradigma funcional é mais velho, então o paradigma OOP :)
—
Raynos
@ Raynos, não há linha reta. OOP é apenas uma pequena abstração metalingüística dentro de um conjunto enorme (infinito) de possíveis linguagens abstratas. E é claro que é extremamente estúpido limitar-se a qualquer um deles.
—
SK-logic
Hoje em dia se fala menos em POO, uma vez que se supõe ser a abordagem de fato em muitas situações. AOP nunca decolou como qualquer tipo de movimento de massa.
Lembro-me de ouvir sobre Programação Orientada a Aspectos pela primeira vez em um Tutorial do OOPSLA '97. Eles disseram que ia matar OO naquela época. Desde então, o OO cresceu apenas além das expectativas mais loucas. AOP, ainda é pouco conhecido, essencialmente sem impacto na indústria de computação. Eu acho que a resposta é óbvia que a AOP não é um assassino de OO.
Veja alguns sistemas AOP existentes. Eles dependem de você ter algum código escrito de alguma forma - por exemplo, o Spring AOP depende de você ter seus métodos definidos em uma classe. O Castle Windsor o suporta em C #, que é uma linguagem orientada a objetos.
Teoricamente, você poderia mudar do OOP para a programação estruturada e ainda manter o AOP, mas na prática isso seria difícil. É fácil subclassificar algo, substituir o método relevante para chamar os filtros antes / depois apropriados e repassá-lo no processo de injeção de dependência.
É muito difícil, em comparação, reescrever chamadas de método estático para rotear para um método de trampolim projetado para chamar os filtros definidos pelo usuário.
Portanto, do ponto de vista da implementação comum, o AOP exige OOP.
Enquanto OOP certamente não é uma bala de prata, o mesmo pode ser dito para AOP. Ele suporta o design baseado em componentes, no entanto, no esquema mais amplo, seus componentes são os novos objetos e as interfaces dos componentes são basicamente uma lista transacional de métodos, o que NÃO é verdadeiro OOP.
AOP adicional e design baseado em componentes suportam um Anemic Data Model, que pessoas mais inteligentes do que eu são criticadas.
http://martinfowler.com/bliki/AnemicDomainModel.html
(Eu sei que o artigo acima é antigo, mas surpreendentemente relevante)
A conclusão é que os sistemas AOP estão aqui para ficar, mas também estão longe de serem perfeitos. Nenhum sistema é perfeito.