Os paradigmas que não pertencem à OOP suportam conceitos como encapsulamento?

Um dos conceitos importantes da programação orientada a objetos é o encapsulamento. Ultimamente, no entanto, o mundo do software parece estar se inclinando a favor de outros paradigmas como a programação funcional.

Isso me faz pensar, e o encapsulamento e outros princípios de POO? Eles estão errados?

É que OOP é aplicado errado? Por exemplo, Alan Kay é conhecido por dizer na palestra da OOPSLA'97: "Inventei o termo orientado a objetos e posso dizer que não tinha C ++ em mente".

Joe Armstrong - "Os objetos ligam funções e estruturas de dados em unidades indivisíveis. Acho que este é um erro fundamental, pois funções e estruturas de dados pertencem a mundos totalmente diferentes".

Eu acho que a armadilha em que você caiu aqui é pensar que existe uma definição rígida de qualquer paradigma de programação (estruturado, orientado a objetos, funcional etc.)

Se você perguntar a dois desenvolvedores diferentes o que significa OOP, você receberá duas respostas diferentes. Sim, como profissão, concordamos que existem alguns temas comuns, como encapsulamento, ocultação de dados etc. abrangidos por qualquer aula de engenharia de software OOP na faculdade.

No entanto , no mundo real, as coisas não são tão completas, e é por isso que dois desenvolvedores dão duas respostas diferentes. Talvez eles sejam especialistas em diferentes idiomas que expressam os conceitos de POO de maneira diferente. Os paradigmas de linguagem tendem a se sobrepor. A última novidade a partir de 2013 é incorporar a programação funcional em linguagens orientadas a objetos através de fechamentos ou lambdas. O Java 8 é orientado a objetos ou funcional? Eu chamaria isso de orientado a objetos com uma pitada de funcional. Outra pessoa pode descrevê-lo de maneira diferente.

É que OOP é aplicado errado?

Não, a questão é que várias linguagens expressam conceitos de programação de maneira diferente. Talvez um idioma exclua um conceito de POO e outro idioma o inclua, mas exclua um conceito diferente de POO. Os idiomas geralmente são projetados para uma finalidade: facilitar um certo tipo de tarefa, às custas de dificultar outras tarefas. Isso não é certo nem errado, é simplesmente uma troca no mundo real que é impossível evitar.

O mundo real não é a sala de aula. Precisamos discutir paradigmas conceituais de programação em nível abstrato ou discutir linguagens de programação reais que são forçadas a fazer trocas para serem úteis. Desde que uma linguagem de programação seja definida principalmente por uma definição abstrata de OOP, podemos incluí-la nesse intervalo.

Ultimamente, no entanto, o mundo do software parece estar se inclinando a favor de outros paradigmas como a programação funcional.

Isso é discutível. Primeiro, não vejo outros paradigmas além de OOP e programação funcional que são discutidos amplamente, então acho que podemos esquecer a frase "outros paradigmas como" , vamos falar sobre FP, nada mais.

As razões pelas quais a programação funcional se tornou tão popular nos últimos anos foram discutidas em outras questões aqui em profundidade, não vou repetir isso (veja aqui ou aqui , por exemplo). Mas, na minha opinião, isso não ocorre porque "OOP foi um grande erro" ou "Funcional vs. OOP são mutuamente exclusivos", é mais como as pessoas estendendo sua caixa de ferramentas e tentando obter o melhor dos dois mundos. Ok, certamente existem especialistas que são os mais exigentes entre si, mas você encontrará esses caras dos dois lados.

Isso me faz pensar, e o encapsulamento e outros princípios de POO? Eles estão errados?

O encapsulamento tem muitos sabores diferentes. Linguagens de programação funcional e construções de linguagem fornecem certas formas de encapsulamento, outras orientadas a objetos. Se você estiver procurando exemplos de encapsulamento com meios funcionais, comece com fechamentos .

No que diz respeito a "outros princípios": não, eles não estão errados, mas em certos cenários como paralelismo de alta escala, as abordagens funcionais provavelmente escalam melhor. Para outros cenários, como a criação de estruturas de interface do usuário bem projetadas, o OOP aborda a escala provavelmente melhor (YMMV, não tenho apenas um exemplo melhor à mão). Além disso, tenho certeza de que, para a maioria dos cenários do mundo real, isso depende do conhecimento e da experiência da equipe com seu paradigma de programação favorito de quão bem um determinado sistema será dimensionado.

É que OOP é aplicado errado? Por exemplo, Alan Kay é conhecido por dizer na palestra da OOPSLA'97: "Inventei o termo orientado a objetos e posso dizer que não tinha C ++ em mente".

Certamente OOP é frequentemente aplicado incorretamente por muitas pessoas, mas estou certo de que o mesmo se aplica ao FP. E eu ficaria surpreso se John Mc Carthy (designer da Lisp) tivesse algo como Javascript em mente quando estivesse pensando em programação funcional (tenha piedade de mim, não me chame demais por essa comparação ;-)

Joe Armstrong - "Os objetos ligam funções e estruturas de dados em unidades indivisíveis. Acho que este é um erro fundamental, pois funções e estruturas de dados pertencem a mundos totalmente diferentes".

Eu acho que o inventor de Erlang tem alguns bons argumentos, mas ele também tem seu próprio ponto de vista, então deixe sua opinião e construa a sua. Existem muitos outros especialistas que têm uma idéia diferente disso.

Claro:

struct Foo
{
    string bar;
    int bux;
}

Eu sei o que você vai dizer: "Mas isso também não resume o comportamento!" Bem, eu estou com Joe Armstrong nesta questão: você pode escrever programas ou sistemas operacionais inteiros sem precisar de objetos de primeira classe. O Linux prova isso.

Programadores Javascript rotineiramente encapsulam estado e comportamento em funções e fechamentos, não em classes.

A questão principal aqui é que o encapsulamento não é um conceito rigidamente definido nem por que é útil. Fazer uma pesquisa mostra que a maneira como as pessoas veem o encapsulamento é altamente opinativa e que muitas pessoas o confundem com Abstração.

A primeira definição que você vai encontrar é

Encapsulamento é um conceito que une os dados e funções que manipulam os dados ...

Se essa é sua definição, a maioria das linguagens tem como agrupar dados e funções que operam nesses dados em classes, módulos, bibliotecas, espaços para nome, etc.

Mas eu argumentaria que esse não é o principal objetivo do encapsulamento, pois essa definição continua:

... e isso mantém os dois protegidos contra interferências externas e uso indevido.

A Wikipedia também concorda com isso:

Um mecanismo de linguagem para restringir o acesso direto a alguns dos componentes do objeto.

Mas agora, precisamos perguntar o que se entende por "interferência e uso indevido" e por que o acesso direto aos dados deve ser restrito. Eu acredito que há duas razões.

Primeiro, o escopo limitador no qual os dados podem ser mutados é do melhor interesse do desenvolvedor. Com muita frequência, é necessário ter lógica antes / depois do valor ser definido. E ter apenas um número limitado de locais onde o valor pode ser definido é extremamente valioso. Nos idiomas OOP, isso pode ser feito usando classes. Em linguagens funcionais "mutáveis", os fechamentos servem ao mesmo propósito. E porque sabemos que classes = fechamentos , é até discutível que linguagens funcionais mutáveis ​​sejam um "paradigma" diferente do OOP.

Mas e as línguas imutáveis? Não tem problema de alterar variáveis. É aqui que entra a segunda questão: funções e dados de ligação permitem manter esses dados em um estado válido. Imagine que você tem uma estrutura imutável Email. Essa estrutura possui um único stringcampo. Temos requisitos para que, se você tiver um valor do tipo Email, esse campo contenha um endereço válido. No encapsulamento da OOP, isso é facilmente feito declarando esse campo private, fornecendo apenas Getmétodo e tendoconstructor methodque só será bem-sucedido se passado na cadeia de caracteres for um endereço válido. Coisa semelhante com fechamentos. Agora, para uma linguagem imutável, seria necessário dizer que a estrutura só pode ser inicializada através de uma função específica e essa função pode falhar. E não conheço nenhum idioma que se encaixe nesse critério (talvez alguém nos comentários possa me esclarecer).

Última edição é o que se entende por encapsulamento de "suporte" da linguagem. Por um lado, existem idiomas que permitem impor o encapsulamento, para que o código não seja compilado se o encapsulamento estiver quebrado. Por outro lado, o idioma pode fornecer uma maneira de encapsular, mas não o aplica, deixando o desenvolvedor aplicá-lo. Para o segundo caso, qualquer linguagem que possua estruturas e funções pode funcionar. Linguagens dinâmicas e Haskell vêm à mente. E eu diria que não há muitas línguas que caem do outro lado do espectro. Mesmo o C #, que é realmente bom em impor o encapsulamento para seus objetos, pode ser ignorado usando reflexão. Mas, vendo que em C # seria considerado um cheiro de código maciço e nenhum desenvolvedor de C # sano faria isso de bom grado.