Código de Processo vs código OOP

Eu terminei um projeto em PHP de mais de 13000 linhas no Estilo de Procedimento [porque estou muito familiarizado com isso, embora conheça OOP], e o projeto está funcionando perfeitamente.

Mas devo convertê-lo para OOP? [ porque o mundo está ocupado com OOP ]

Meu código não precisa de nenhum recurso do OOP [encapsulamento, herança basicamente ...]!

Então, o que eu deveria fazer?

E que tipo de ajuda receberei se convertê-lo em OOP?

Meu código não precisa de nenhum recurso do OOP

Você respondeu sua própria pergunta - se você não precisar de OOP nesse caso e seu projeto estiver funcionando, não o converta.

No entanto, você deve usar o OOP para o seu próximo projeto - mas apenas se for apropriado.

Não há nada intrinsecamente errado com a programação procedural - desde que seja usada no local apropriado.

Não e não apenas porque você não precisa de POO.

Se o seu programa já estiver concluído e funcionando satisfatoriamente, em mais de 90% do tempo, é uma perda de tempo reescrever o código finalizado por qualquer motivo.

OOP não é tão poderoso; há muitos lugares onde o OOP não deve ser usado; portanto, não o use apenas porque OOP é a tendência.

Minha opinião geral sobre paradigmas (e por que nenhum dos três principais paradigmas é o caminho certo ou o caminho errado para programar):

A programação de procedimentos é boa quando você tem um problema simples em um nível alto (embora possa ser complexo em um nível baixo) e deseja escrever um código linear simples correspondente. É sem dúvida mais fácil escrever e entender do que OO e funcional se o problema não precisar de forte dissociação em qualquer lugar. Exemplos: código numérico, a maioria dos scripts pequenos e a maioria dos subproblemas pequenos, depois de dividir as coisas usando OO ou funcional.

O código orientado a objetos é bom quando você precisa desacoplar fortemente as preocupações, porque você pode ter mais de uma implementação de algumas preocupações. Exemplo: a maioria dos softwares corporativos. Você pode, por exemplo, querer desacoplar fortemente a lógica de negócios da lógica de apresentação, porque eles provavelmente precisarão mudar de forma independente.

A programação no estilo funcional é boa quando você precisa de uma forte separação entre mecanismo e política. Ter uma função de mecanismo que aceite uma função de política é um bom padrão. (Aprendi sobre isso examinando o módulo std.algorithm da linguagem de programação D ). Abstrair um estado mutável na fronteira entre código de política e mecanismo geralmente torna a API mais fácil de raciocinar. Se o estado mutável for usado privadamente em qualquer um, esse é um detalhe da implementação. A outra força da programação funcional é a simultaneidade, por razões evidentes.

O código nunca "precisa de POO". São os programadores, na medida em que conseguem pensar em diferentes modos, que imaginam que esse ou aquele problema em particular "precisa" de $ PARADIGM ou é melhor resolvido dessa maneira.

Geralmente, os programadores que conhecem apenas um paradigma acham que seu paradigma é o maior. Um tamanho serve para todos, e todos devemos dormir na cama de Procrustes, se isso ou aquilo está na moda.

Você só deve converter seu projeto em OOP se houver uma indicação clara da necessidade de OOP. Os cenários possíveis em que isso pode ocorrer são (entre outros):

• ampliando o projeto
• adicionando mais desenvolvedores à equipe

e mesmo nesses cenários, talvez ainda não seja necessário converter seu projeto em OOP.

Ambos podem ser bons, ambos podem ser ruins. Mas adaptar um para se parecer com o outro nunca é uma boa ideia.

Se você pensar por que o OO foi inventado, verá que não precisa de OOP, mas às vezes isso facilita muito a sua vida.

Nos dias de codificação C, um programa muito grande poderia se tornar bastante confuso e difícil de continuar trabalhando. Então eles inventaram maneiras de dividi-lo em pedaços modulares. OOP adota essa abordagem e a torna ainda mais modular, colocando os dados com esses blocos da lógica do programa para que eles fiquem ainda mais separados do restante do código.

Isso permite que você escreva programas cada vez maiores, seguros de que você transformou seu enorme elefante de uma tarefa em uma centena de tarefas do tamanho de ratos. O bônus adicional é que você pode pegar alguns desses 'mouses' e reutilizá-los em outros programas!

É claro que o mundo real não é bem assim, e a reutilização de objetos nunca é tão bem-intencionada quanto foi planejada, mas isso não significa que seja um paradigma inútil.

O que é inútil é uma dependência excessiva de qualquer estilo de codificação. Qualquer pessoa que faça OO com milhares de classes pequenas e insignificantes não está realmente fazendo o certo - está criando um pesadelo de manutenção para si (ou para outra pessoa). Qualquer pessoa que escreva um aplicativo de procedimento com apenas três funções também está dificultando a vida. A melhor maneira é os objetos grandes e médios (às vezes chamados de componentes que parecíamos estar indo uma vez) que podem fornecer uma quantidade razoável de código e dados independentes com maior probabilidade de serem reutilizados isoladamente do resto do seu aplicativo.

Meu conselho para a próxima vez: tente escrever seu código de procedimento usual, mas crie um único objeto da sua estrutura de dados principal. Veja como você acha que trabalhar com isso é mais fácil do que passar dados de uma função para outra.

Meu código não precisa de nenhum recurso do OOP [encapsulamento, herança basicamente ...]!

Como você sabe disso?

Você precisa manter este projeto? Existem novos recursos planejados? Haverá outras pessoas que estarão desenvolvendo com você? Você se repetiu? O código é difícil de entender?

Se a resposta for "sim", talvez você deva começar a pensar em montar um esqueleto OOP e seguir esse caminho.