Quando eu, por assim dizer, andei na Internet, notei um recurso interessante. Todos os paradigmas de programação discutidos em outros lugares são percebidos pelas pessoas com bastante calma. Se, por exemplo, eles falam sobre programação procedural, falam absolutamente com calma. O mesmo acontece com a programação modular. Programação declarativa - sem tempestades, agitações ou holivarov. A programação funcional é a mesma.
E apenas em torno do POO não se acalmam as tempestades.
Alguns gritam dele com deleite, outros, ao contrário, encontram falhas no que a luz é baseada. E, para ser sincero, é completamente incompreensível para mim o motivo pelo qual o mundo inteiro se uniu no OOP.
Você pode ter pensado que eu sou mais um adversário do que um defensor da OOP. Este não é absolutamente o caso (no entanto, você pode entender isso no título). Não. Sou antes um oponente de balas de prata, hype, entronização de uma determinada metodologia ou pessoa e todo tipo de dança redonda. Você não dirige danças circulares, digamos, com uma chave inglesa ou um cortador de grama. E não escrevo, espero, publicações por que uma broca ou martelo é péssimo.
Hoje, porém, a Internet inteira está repleta de artigos pomposos, hiperemocionais e radicais sobre OOP - se alguém diz que OOP é "zer gut" e, em geral, para todos os intestinos, então o outro transmite necessariamente que o OOP precisa ser jogado no lixo com urgência (se apenas ele não compartilha as opiniões do primeiro). Não há terceiro.
Eu só quero trazer o terceiro elemento. É calmo, sem exageros e abusos, dizer por que OOP não é um elixir de todas as doenças, mas também, como PP, AF ou PL, tem o direito de existir.
Então, um artigo calmo em defesa do POO. Nele, tentarei considerar os principais argumentos dos oponentes da OLP e justificar seu fracasso.
1. Tudo o que existe no OOP está em outros paradigmas há muito tempo
Quase todas as linguagens de programação são completas, com exceção das linguagens de marcação, como HTML, XML, CSS etc. Falando em um idioma camponês, Turing é um idioma completo - um idioma no qual você pode escrever absolutamente qualquer programa concebível. Disso segue uma tese bastante geral: o que está em qualquer idioma aleatório escolhido está em todos os outros idiomas. O mesmo pode ser dito sobre paradigmas. Todas as diferenças de linguagens (e paradigmas) são formas diferentes de implementar certos comandos, sem contar os recursos lexicais individuais.
A propósito, essa mesma tese (tudo o que está em N, está em M, e em K, e em R, etc.) pode ser formulada da seguinte maneira: o martelo já é composto de ferro e madeira, por que também precisamos de um alicate? Mas ninguém vai dizer isso.
2. OOP combina dados e ações neles. Ta ruim
O argumento é sugado para fora do dedo. Primeiro, onde o OOP combina dados e funções? Em segundo lugar, a afirmação de que isso é ruim também é tirada de uma lanterna, de um barril "um homem de verdade não faz isso" e por que - por causa do gladíolo. OOP de alguma maneira modela o mundo real onde os dados são inerentes ao objeto - ninguém argumentará que a cadeira está sem cor e não possui quatro pernas. E nenhuma mistura de dados e operações ocorre aqui, o objeto não é uma função ou um operador.
Isso é uma abstração.3. A herança escraviza o programa, dificulta as alterações
Aqui você pode desacelerar um pouco. A herança não implica em nada a construção de árvores de quilômetro, a fim de retardar o desenvolvimento. A herança foi inventada para distinguir propriedades e métodos comuns em uma superclasse, e isso deve ser feito com classes que representam objetos do mesmo tipo. Será um erro criar, por exemplo, duas classes, uma das quais é a herdeira da outra, porque não há alocação de um código comum para uma superclasse simplesmente porque
não há nada em comum .
Se não se pretende estender a classe pai para uma terceira classe, essa herança é simplesmente sem sentido. Se você estiver criando uma loja de bebidas, as classes Beer, Vodka e Vine podem ser herdadas da classe Alcohol, mas você não precisa criar a classe Drinks, a menos que queira vender, por exemplo, chá paraguaio.
Além disso, será um erro criar hierarquias nas quais as classes não se relacionam. Bem, por que, diga-me, para fazer uma torre onde as classes Fly e Cutlet são herdadas da superclasse Cheese, que por sua vez é herdada da superclasse sexta-feira ?! Mas isso não é mais um defeito do OOP, mas as mãos tortas de quem o compõe.
4. Encapsulamento não faz sentido
Aqui eu concordo parcialmente. Do ponto de vista do programa, o encapsulamento realmente não afeta nada. Se eu fechar a variável usando private - e daí? Ainda posso abri-la simplesmente removendo private e alterando tudo o que eu gosto.
Mas isso é verdade apenas tecnicamente. A filosofia da OOP é que uma classe devidamente organizada e encapsulada pode ser vista como uma caixa preta. Imagine uma caixa de um lado da qual existem vários botões, slots para fornecer dados e, por outro lado - um slot de saída que retorna informações. Pegue, por exemplo, uma pilha. Imagine uma caixa de um lado da qual haja um slot para inserir dados e um botão ao lado. Na parte de trás está o botão pop. Você envia uma nota com o número 8 e pressiona o botão. Depois, dê outro pedaço de papel e pressione push pela segunda vez. E então N vezes, e pressione pop. Um pedaço de papel sai da gaveta com o número 76 (ou outro, em geral, o que você enviou). Precisa de outro número? Pressione pop uma segunda vez. E assim por diante até a
conspiração da cenoura até a caixa ficar vazia. E se você continuar pressionando o pop, o mecanismo da caixa conquistará: a pilha está vazia! É exatamente assim que o objeto se parece.
Mas depois que você criou e configurou a classe, já é violeta para você como funciona lá - funciona corretamente, mas você não precisa mais. E encapsulando todas essas estruturas, você não mantém tudo na memória. Eles (muitas caixas) apenas falam um com o outro da maneira que você configura.
O encapsulamento é um tipo de muleta que suporta centenas de pilares do seu programa enquanto você constrói cento e primeiro. Em grandes projetos (a saber, para criá-los, o OOP foi inventado) sem isso, infelizmente, nada.
Embora, dificilmente seja "infelizmente" geralmente apropriado aqui.
5. Não há hierarquias de relacionamento no mundo real, apenas hierarquias de inclusão em todos os lugares
É mesmo assim? Mas ninguém se preocupa em criar, por exemplo, uma hierarquia em que todos os rios do mundo (Congo, Sena, Tamisa, Amazonas, Kolyma etc.) sejam objetos de um "rio" abrangente, que possui propriedades inerentes (por exemplo, água) e ações (por exemplo, fluxos), e já será herdada da "Lagoa", que também consiste em água, e da "Lagoa" você também pode herdar o "Lago", cujos objetos serão lagos separados (Baikal, Mar Cáspio, Titicaca, etc.) .d.). O esquema é bem difícil. Mas as hierarquias de relacionamento também são uma
abstração . Algo à la platônico, se você quiser. No mundo real, eles não estão lá, eles existem apenas na mente, isso é uma generalização e nada mais. Mas é exatamente assim que uma pessoa pensa com muita frequência. Podemos dizer “meia” sem especificar de que cor é, de que material é tecido etc. etc., mas essa “meia” realmente existe?
No entanto, não devemos ter vergonha de não haver "objeto" ou "meia".
6. A metodologia OOP é inicialmente incorreta
Um argumento absolutamente infundado. OOP foi criado para simular um tipo de mundo virtual que consiste em objetos, como o nosso mundo. Por exemplo: uma pessoa é um objeto do mundo real. Ele pode andar, correr, comer,
cagar , jogar futebol, assistir futebol, mas, infelizmente, não consigo listar tudo aqui e, sinceramente, seria nojento listar tudo. Essa mesma pessoa tem as seguintes propriedades: presença / ausência de cabelo, cor do cabelo, se houver, cor dos olhos, cor da pele, número de dedos, etc. Se você construir corretamente todos os campos e métodos, como escrevi acima, o objeto do programa poderá modelar certas propriedades de um objeto real. Uma pessoa pensa muito bem em tais categorias - é por isso que a OOP se tornou generalizada. Ajuda muito ao escrever projetos grandes, pois introduz modularidade e permite que você divida um pacote de software em componentes separados que interagem entre si.
7. Mas mesmo milhões de moscas não nos convencem de que o esterco é delicioso.
O argumento mais popular contra o POO. Assim, as massas são na maioria idiotas (ainda assim, acho que isso não se aplica aos programadores), andam pelas "roupas da moda" e as admiram.
Mas pense bem, e se não a OLP, mas, digamos, LP, entrou no pedestal? Você acha que seria diferente? Nada disso! Teria havido fãs e oponentes maliciosos, e eles teriam olhado a OLP como um instrumento (para isso, eu realmente peço), e não como uma pílula criada pelo próprio Deus e, portanto, insubstituível.
Por que este artigo é uma defesa da OLP?
Toda a conversa moderna sobre paradigmas de programação, a meu ver, se resume a duas premissas diamétricas: saia da OOP e jogue fora o resto, ou jogue fora da OOP e ... bem, você me entende.
Não quero que um paradigma completamente adequado seja considerado um lixão digno, mas não quero uma dança ao redor, mas esqueci todo o resto. Eu acho que o segundo é mais fácil de fazer, mas este artigo é direcionado contra o primeiro.
Se você não gosta de OOP
A quem - OOP, a quem - FP, a quem - PP. E para alguém, talvez, em geral, a cartilagem de porco é acima de tudo doce. Se você não gosta de gatos, provavelmente não sabe como cozinhá-los.