Faz-paradigma único OOP levar a inversão abstração?

Question

Para aqueles de vocês que não estão familiarizados com o conceito, abstração inversão é a implementação de construções de baixo nível em cima de construções de alto nível, e é geralmente considerado uma coisa ruim, porque acrescenta tanto complexidade desnecessária e sobrecarga desnecessária . Claro, esta é uma definição um tanto imprecisa, subjetiva.

Na sua opinião, se a programação em uma linguagem OOP single-paradigma, onde tudo deve ser parte de uma classe e coisas como ponteiros não estão expostos, como Java ou C #, inevitavelmente a inversão abstração? Se assim for, em que casos?

Answer 1

Single-paradigma qualquer viola o primeiro mandamento de abstrações, que poucas pessoas parecem conhecer e ainda menos se preocupam.

Tu não te fazer qualquer abstração que não pode ser substituído, se necessário, para que o teu código de estar livre de inversões de abstração feias.

Não importa o seu paradigma, uma vez que você começar a escrever código não-trivial para resolver problemas do mundo real, você vai acabar com algumas coisas que simplesmente não se encaixam no paradigma muito bem. Se você declarar que que um paradigma é tudo que existe, isto é, quando as coisas ficam feias.

Para misturar algumas metáforas, quando tudo que você tem é um martelo, tudo começa a parecer uma estaca, e se todos os seus buracos são redondos e de repente você acabar com alguns pinos quadrados e você não tem nenhum serras, (apenas malhos,) você tem-se um problema.

Não há almoço grátis. Tudo é um trade-off. O código mais fácil se torna para escrever, mais difícil se torna para alguém de ler e manter, ou para você ou qualquer outra pessoa para depuração quando problemas ocorrem abaixo do nível de abstração que você está trabalhando. (E eles acabará, porque nenhuma abstração é perfeito .

Esta é a falha fundamental com tecnologias de "votos" e paradigmas, tais como código gerenciado, coleta de lixo, compilação JIT e do "tudo é um objeto" fiat. Eles impõem um nível básico de abstração que você não tem permissão para chegar embaixo, e quando algo dá errado abaixo desse nível, não há nada que você possa fazer sobre isso. Você está trabalhando preso em torno de um mau abstração porque você não pode corrigi-lo.

Answer 2

Os programadores reais pode escrever Fortran em qualquer idioma

Em outras palavras, não é a língua, é o programador

Answer 3

Java e C # possuem métodos estáticos que são equivalentes às funções, de modo que a língua não é forçar nada em você.

Dito isto, Uma vez que eu realmente tenho OO, eu não tive qualquer desejo que seja para ir para outro estilo de programação.

Se a sua camada OO simples está cobrindo algo complexo, sugiro que é provavelmente seu código que é um problema. Se OO é bem feito deve ser simples todo o caminho até o metal.

Answer 4

Eu não acho que um idioma como Java ou C # sofre com esta de alguma forma tangível, simplesmente porque as bibliotecas que acompanham o quadro são tão ricos que a necessidade de quebrar em outro paradigma não é realmente necessário para a programação geral.

Dito isto, os bibliotecas ricas si mesmos podem sofrer de inversão abstração no entanto, porque as implementações internas são muitas vezes escondidos, ou classes chave são selados, os desenvolvedores tentam estender essas bibliotecas são muitas vezes forçados a re- implementação / replicar a funcionalidade para fazer com sucesso uso de pontos de extensão fornecidos pelo biblioteca de classes base - esta não é tanto uma questão da língua, como uma escolha consciente feita pelo desenvolvedor das bibliotecas de classe base, para evitar a funcionalidade de expor o que pode ser frágil ou mudar muitas vezes com novas versões do .Net Framework / JDK.

Também porque o Java Runtime .Net Framework / ambos permitem interoperabilidade com outras linguagens sentado em cima do tempo de execução comum, a capacidade de direcionar outros paradigmas (como programação funcional, linguagens dinâmicas etc.) também pode fornecer uma outra rota para romper das restrições de paradigmas individuais.