Quando realmente usamos a programação orientada a objetos? [fechadas]

Estou escrevendo um programa em Python, que basicamente manipula seqüências de caracteres, e fiquei pensando se deveria fazê-lo usando princípios de OOP ou não. O cliente me disse que não se importa com o código, ele só quer que a coisa seja feita .

Eu sei que o código orientado a objetos não é, por definição, mais limpo e, por outro lado, o código não OO não é por definição ruim. A pergunta que estou fazendo pode ser mais ou menos baseada em opiniões, mas pode haver algumas regras que eu não conheço.

Mais algumas informações sobre o que deve ser feito:

• analisar um .csvarquivo e processar os dados com base em um arquivo de configuração (as colunas podem ser diferentes - como no número de colunas ou nos dados que eles contêm)
• use os dados processados ​​acima para criar novos dados formatados personalizados (ou vários arquivos com base em alguns dos valores acima)
• use os últimos dados formatados para criar um arquivo XML.
• divida o arquivo XML em vários XMLs com base em seu conteúdo
• o aplicativo deve ser baseado em CLI
• é claro que existem outras coisas como: registrar alguns eventos, analisar argumentos da CLI e assim por diante.

Agora, essa não é uma aplicação grande / difícil, e também está quase concluída, mas durante todo o processo de desenvolvimento eu fiquei me perguntando se isso deveria ser feito usando OOP ou não.

Então, minha pergunta seria: como vocês sabem / decidem quando usar o OOP em um aplicativo?

Python é uma linguagem de múltiplos paradigmas, o que significa que você pode escolher o paradigma mais apropriado para a tarefa. Algumas linguagens como Java são OO de paradigma único, o que significa que você terá dores de cabeça se tentar usar qualquer outro paradigma. Os pôsteres dizendo "sempre use OO" provavelmente vêm de um plano de fundo nesse idioma. Mas, felizmente, você tem uma escolha!

Observo que seu programa é um aplicativo CLI que lê algumas entradas (arquivos csv e config) e produz alguma saída (arquivos xml), mas não é interativo e, portanto, não possui uma GUI ou API com estado. Esse programa é naturalmente expresso como uma função da entrada para a saída, que delega para outras funções para subtarefas.

OO, por outro lado, trata-se de encapsular o estado mutável e, portanto, é mais apropriado para aplicativos interativos, GUIs e APIs que expõem o estado mutável. Não é por acaso que o OO foi desenvolvido em paralelo com as primeiras GUIs.

OO tem outra vantagem, pois o polimorfismo permite uma arquitetura mais fracamente acoplada, na qual diferentes implementações da mesma interface podem ser facilmente substituídas. Combinado com a injeção de dependência, isso pode permitir o carregamento baseado na configuração de dependências e outras coisas interessantes. Porém, isso é apropriado principalmente para aplicativos muito grandes. Para um programa do tamanho do que você descreve, seria muito caro, sem nenhum benefício aparente.

Além das funções que realmente leem e gravam os arquivos, a maior parte da sua lógica pode ser escrita como funções livres de efeitos colaterais, que recebem algumas entradas e retornam outras saídas. Isso é eminentemente fácil de testar, muito mais simples do que testar unidades OO, nas quais você precisa zombar de dependências e outros enfeites.

Conclusão: sugiro várias funções divididas em módulos para organização, mas sem objetos.

Considere um botão em uma GUI. Tem estado (tamanho, cor, posição, etiqueta, etc.). As coisas podem acontecer (é clicado, precisa ser redesenhado, etc.). Em tais situações, modelá-lo como um objeto faz sentido. Como objeto, ele pode conter seu estado, um conjunto de ações que podem ser executadas nele (métodos) e pode notificar outras partes do aplicativo que as coisas aconteceram disparando eventos.

OOP é uma excelente ferramenta para lidar com GUIs e outras situações em que partes do sistema têm estado volátil.

Outras situações, como a que você descreve, em que os dados são lidos de uma fonte, processados ​​e gravados em um destino, são bem tratados por uma abordagem diferente: programação declarativa (ou função). O código declarativo para processamento de dados tende a ser mais fácil de ler e menor do que as soluções OOP.

Assim como um martelo e uma serra são ferramentas poderosas quando usadas corretamente, o mesmo acontece com as técnicas de programação declarativa e orientada a objetos. Você provavelmente poderia martelar um prego em um pedaço de madeira com o cabo de uma serra. Da mesma forma, você pode quebrar um pedaço de madeira ao meio com um martelo. Da mesma forma, você pode criar uma GUI com apenas funções e processar dados com objetos. Quando as ferramentas são usadas corretamente, os resultados são mais limpos e mais simples.

A regra geral que uso é que, se tenho muito estado ou preciso de interação do usuário, uso objetos; caso contrário, uso funções (de ordem pura e superior, sempre que possível).

A Programação Orientada a Objetos adiciona quatro novas ferramentas ao seu arsenal:

1. Encapsulamento
2. Abstração
3. Herança
4. Polimorfismo

Você usaria o OOP em seu aplicativo quando ele se tornasse grande o suficiente e complexo o suficiente para se beneficiar dessas ferramentas.

Esta pergunta parece um pouco confusa para mim. Se você está escrevendo em Python, certamente usará objetos. Quando você abre um arquivo, ele retorna um objeto. Quando você produz um resultado, ele retorna um objeto iterador. Cada função que você cria é um objeto. Questionar o valor de OO em aplicativos Python parece estranho, para dizer o mínimo.

Com base nos comentários aqui, sim, o Python suporta paradigmas funcionais, mas é principalmente baseado em objetos. A própria linguagem e as bibliotecas integradas são orientadas em torno de objetos. Sim, ele suporta lambda (assim como Java e qualquer outro número de idiomas normalmente descrito como OO), mas é intencionalmente simplista em comparação com uma verdadeira linguagem funcional.

Talvez essas distinções entre design OO e design funcional estejam se tornando obsoletas. Se eu criar pegar uma função polimórfica em um Objeto projetado OO * e passar um ponteiro para essa função em um objeto como um parâmetro para a função com estilo funcional *, é OO ou funciona? Eu acho que é ao mesmo tempo e também uma abordagem realmente eficaz para resolver problemas.

Penso que a verdadeira questão é 'quando você deve começar a projetar suas próprias classes, em vez de apenas criar um módulo com funções?' Eu acho que a resposta certa para isso é: quando isso ajuda a simplificar a solução. Eu daria a mesma resposta básica para qualquer linguagem orientada a objetos.

* redundância é intencional: não quero ser acusado aqui de assumir que os objetos são OO ou que as funções são funcionais.

Uma das coisas mais importantes sobre programação orientada a objetos é que, em vez de raciocinar sobre o fluxo do programa, você começa a raciocinar sobre o estado.

Muitas vezes vejo o objeto, vejo os métodos, mas o que vejo também é que o pensamento por trás do código é fluxo, e não estado.

E quando você raciocina sobre o estado, é fácil criar um bom código OOP, porque assim que seu código se torna muito complexo, você percebe que não pode mais raciocinar sobre seu estado e sabe que precisa refatorar.

Considere o seu exemplo: você deseja analisar um arquivo csv. De onde vem: um arquivo em disco. Você carrega e coloca na memória e analisa. Agora seu cliente vem: ei, também quero analisar arquivos da web. Então, você está feliz porque criou uma ótima interface para carregar seu arquivo e só precisa criar o código que o busca na Web, e o restante do seu programa permanece exatamente o mesmo.

E o mais legal é: você pode testar isso.

Em termos leigos:

• Você pode usar OOP ou não OOP em qualquer tipo de projeto que desejar.
• OOP não é a panacéia, mas ajuda a gerenciar a complexidade.
• Vai além da modularidade, trata-se de compartimentação. Pense nos diferentes compartimentos que um navio possui para manter a flutuabilidade se o casco estiver danificado.
• OOP é uma maneira de gerenciar dependências, para que os bugs possam ser mais fáceis de rastrear, pois há apenas um conjunto definido de maneiras pelas quais os diferentes componentes de um programa podem se comunicar.
• Em um programa, há muitas coisas funcionando: variáveis, constantes, métodos, arquivos, parâmetros, funções, módulos etc. Eles podem interagir entre si de maneiras que às vezes podem ser imprevisíveis. OOP é um conjunto de princípios que reduzem o número de maneiras pelas quais as coisas podem interagir entre si. Você não é forçado a usar o OOP para fazer isso, mas ajuda.

Dito isto, existem outros fatores a serem levados em consideração:

• Seus programadores são proficientes em OOP / OOD?
• Seus programadores são proficientes em uma linguagem OOP?
• Você acha que o software se tornará complexo com o tempo?
• Você planeja dimensionar ou reutilizar código no futuro?
• Você acha que seu "design" pode se tornar um ativo? Você poderá aproveitá-lo para crescer ou como base para projetos futuros?

Não me entenda mal: você pode conseguir tudo isso sem usar o OOP, mas com o OOP será mais fácil.

Mas...

Se sua equipe não é proficiente em POO / POO e não possui experiência nessa área, use os recursos que você possui.

Então, minha pergunta seria: como vocês sabem / decidem quando usar o OOP em um aplicativo?

Sempre use-o. Quando estiver acostumado a usá-lo, você o usará para tudo. É uma ótima maneira de garantir uma boa abstração entre os recursos e seu uso, o que é um benefício significativo para a manutenção. Nós o usamos, por exemplo, para

• objetos de estrutura de dados pequenos, porque geralmente são polimórficos, por exemplo, e a estrutura de dados intermediária depois de analisar algo geralmente possui várias entidades pequenas, que têm comportamento comum e ainda são especializadas. Esse é um ótimo caso de uso para uma classe ou interface base comum, com implementações e comportamentos especializados, isto é, uma hierarquia de classes (polimorfismo).

• como exemplo, porque facilita a substituição de um agente de log diferente

• grandes partes da estrutura do programa, porque você evoca vários concorrentes e talvez aproveite os processadores de várias CPUs. Por exemplo, um servidor da Web pode usar trivialmente vários manipuladores de solicitação simultâneos, devido a objetos.

Facilita a refatoração e a reutilização, como mencionei, incentivando uma boa abstração, o que facilita a manutenção. OOP deve ser adotado e usado o tempo todo. Uma boa programação de POO evita métodos estáticos e / ou dados estáticos e usa objetos para tudo.

A programação orientada a objetos fornece ferramentas para criar estrutura. Essas ferramentas são Encapsulamento, Abstração, Herança e Polimorfismo. Essas idéias ajudarão você a dividir seu programa em duas seções.

Como - Esta é a parte do trabalho de quadro do seu código, onde você cria algum tipo de abstração, decide como seus blocos funcionam em geral e como ele interage com outros blocos.

O que fazer - Esta parte é onde os blocos realizam o trabalho propriamente dito. Aqui a classe é derivada da classe base criada na seção "Como".

Pode-se beneficiar muito com o OOPS

1. se você puder reutilizar uma estrutura existente e precisar implementar apenas detalhes específicos na seção "o que fazer".
2. A funcionalidade que está sendo implementada para o projeto atual é genérica / comumente usada e outros projetos / projetos futuros podem se beneficiar da estrutura criada durante o desenvolvimento do projeto atual.
3. Dividir grandes projetos em padrões conhecidos para resolver um grande problema.
4. Use o OOPS para projetos pequenos, para adquirir o hábito de usá-lo e esteja pronto quando surgirem 1 a 3 tipos de problemas