Na edição de agosto da revista Byte, em 1981, David Robson abre seu artigo, que se tornou a introdução de 'Sistemas de Software Orientados a Objetos' para muitos, admitindo na frente que é uma partida do que muitos familiarizados com a programação imperativa e de cima para baixo estão acostumados.

"Muitas pessoas que não têm ideia de como funciona um computador acham a ideia de programação orientada a objetos bastante natural. Em contraste, muitas pessoas que têm experiência com computadores inicialmente pensam que há algo estranho em sistemas orientados a objetos."

É justo dizer que, gerações depois, a ideia de organizar seu código em objetos significativos maiores que modelam as partes do seu problema continua a confundir programadores. Se eles estão acostumados a programação de cima para baixo ou programação funcional, que trata elementos de código como funções matemáticas precisas, leva algum tempo para se acostumar. Após um período inicial de hype ter prometido melhorias para modular e organizar grandes bases de código, a ideia foi super aplicada. Com o OOP sendo seguido por OOA (análise orientada a objetos) e OOD (design orientado a objetos) logo senti que tudo o que você fez no software tinha que ser dividido em objetos e suas relações entre si. Então os críticos chegaram ao local, alguns deles bastante decepcionados.

Alguns alegaram que, sob testes de escrita da OOP, é mais difícil e requer cuidados extras para refatorar. Há a sobrecarga ao reutilizar o código que o criador de Erlang famosamente descreveu como um caso quando você queria uma banana, mas você tem um gorila segurando a banana. Tudo vem com um ambiente implícito e inevitável.

Outras formas de descrever essa nova maneira de resolver problemas incluem a analogia entre um programador imperativo como "um cozinheiro ou um químico, seguindo receitas e fórmulas para alcançar um resultado desejado" e o programador orientado a objetos como "um filósofo grego ou naturalista do século 19 preocupado com a taxonomia adequada e descrição das criaturas e lugares do mundo da programação".

O sucesso foi apenas uma coincidência?

O OOP ainda é um dos paradigmas dominantes no momento. Mas isso pode ser devido ao sucesso de línguas que por acaso são OOP. Java, C++ e Kotlin regra móvel para Android e Swift e Objective-C para iOS para que você não possa desenvolver software para celular a menos que você entenda a abordagem orientada para o objeto. Para a web, é JavaScript, Python, PHP e Ruby.

Perguntar por que tantas línguas amplamente utilizadas são OOP pode estar misturando causa e efeito. Richard Feldman argumenta em sua palestra que pode ser apenas coincidência. O C++ foi desenvolvido no início da década de 1980 por Bjarne Stroustrup, inicialmente como um conjunto de extensões para a linguagem de programação C. Baseando-se em C , C++ adicionada orientação de objeto, mas Feldman argumenta que tornou-se popular para a atualização geral de C, incluindo tipo de segurança e suporte adicional para gerenciamento automático de recursos, programação genérica e manuseio de exceções, entre outros recursos.

Em seguida, Java queria apelar para os programadores C++ e dobrou na parte OOP. Em última análise, a Sun Microsystems queria repetir o truque C++, visando maior familiaridade para desenvolvedores que adotam Java.

Milhões de desenvolvedores rapidamente se mudaram para Java devido à sua integração exclusiva em navegadores da Web na época. Visto assim, o OOP parece estar apenas pegando carona, em vez de conduzir o sucesso.

O que o OOP pode fazer que seja único para ele?

Existem alguns aspectos valiosos para o OOP, alguns dos quais o mantêm onipresente mesmo quando tem suas desvantagens. Vamos ver os pilares da OOP.

Encapsulamento. Isso significa que os dados são geralmente escondidos de outras partes de uma língua — colocados em uma cápsula, se preferir. O OOP encapsula dados por padrão; os objetos contêm tanto os dados quanto os métodos que afetam esses dados, e uma boa prática OOP significa que você fornece métodos de getter e setter para controlar o acesso a esses dados. Isso protege os dados mutáveis de serem alterados sem querer e torna os dados do aplicativo mais seguros.

Supostamente, é um dos maiores benefícios da OOP. Embora seja mais comumente associado à programação orientada a objetos, o conceito em si é de fato separado dele e pode ser implementado sem o uso de objetos. A abstração é um conceito complementar ao encapsulamento aqui; onde o encapsulamento oculta informações internas, a abstração fornece uma interface pública mais fácil de usar aos dados. De qualquer forma, não é exclusivamente um recurso OOP e pode ser feito com módulos isolando uma função do sistema ou um conjunto de dados e operações sobre esses dados dentro de um módulo.

Herança. Como os objetos podem ser criados como subtipos de outros objetos, eles podem herdar variáveis e métodos desses objetos. Isso permite que os objetos apoiem operações definidas por tipos anteriores sem ter que fornecer sua própria definição. O objetivo é não se repetir — vários usos do mesmo código são difíceis de manter. Mas a programação funcional também pode alcançar DRY através de funções reutilizáveis. O mesmo vale para a eficiência da memória. Embora a herança contribua para isso, o mesmo acontece com o conceito de fechamentos em FP.

Embora a herança seja uma ideia específica do OOP, alguns argumentam que seus benefícios podem ser melhor alcançados pela composição. Se você perder a herança,objetos e métodos se dissolvem rapidamente como o açúcar sintático para estruturas e procedimentos que são. Note-se que: A herança também é necessária para permitir o polimorfismo, que discutimos abaixo.

Polimorfismo. Literalmente, que muda de forma, esse conceito permite que um objeto ou método, seja um genérico, uma interface ou um objeto regular, sirva de modelo para outros objetos e métodos. Existem muitas formas de polimorfismo. Uma única função pode ser sobrecarregada, mudar de forma e adaptar-se a qualquer classe em que esteja. A programação orientada a objetos tende a usar muito policmorfismo subtipo e polimorfismo ad-hoc, mas, novamente, este não é um conceito limitado ao OOP.

Parece que em 2020, não há tanto que a OOP possa fazer que outros paradigmas de programação não possam, e um bom programador usará estratégias de múltiplos paradigmas juntos na batalha contra a complexidade. Por exemplo, se você olhar para as tags mais frequentemente aparecendo em relação a uma pergunta marcada em OOP vs programação funcional,JavaScript aparece em ambos.

O que está por vir?

O OOP, no entanto, foi extremamente bem sucedido. Pode ser que esse sucesso seja uma consequência de uma indústria massiva que apoia e é apoiada pela OOP.

E os próprios desenvolvedores? Nossa Pesquisa de Desenvolvedores deste ano mostra que eles estão ganhando cada vez mais influência de compra. Bem, se também olharmos para o que os desenvolvedores preferem trabalhar com, Haskell e Scala estão entre as linguagens de programação mais amadas. Scala lhe dá o segundo saláriomais alto. Então, talvez com mais evangelismo FP, eles vão subir a lista das línguas mais populares, também.

Há algum movimento, porém, grandes empresas como o Twitter estão executando seu backend quase inteiramente no código Scala. O Facebook, que recentemente aplicou Haskell e muitos dos principais idiomas OOP, também está adotando recursos funcionais. .NET tem LINQ e Java 8 introduzido Lambdas. JavaScript está cada vez mais funcional apesar da introdução de classes no ES6. Swift pode ser o meio feliz entre uma linguagem orientada a objetos e uma linguagem funcional. Então talvez não haja necessidade de escolher: você pode ter sua class Cake e EatCake() também.

O Avance Network é uma comunidade fácil de usar que fornece segurança de primeira e não requer muito conhecimento técnico. Com uma conta, você pode proteger sua comunicação e seus dispositivos. O Avance Network não mantém registros de seus dados; portanto, você pode ter certeza de que tudo o que sai do seu dispositivo chega ao outro lado sem inspeção.