Programação não orientada a objetos em linguagem orientada a objetos [fechado]

Recentemente, fui designada para criar uma calculadora com funções de adição, subtração, multiplicação, divisão e potência usando a Programação Orientada a Objetos . Concluí esta tarefa com sucesso. No entanto, depois reprogramai o programa inteiro sem usar a técnica / método orientado a objetos .

A coisa que notei que o comprimento do meu código foi reduzido significativamente e era compreensível. Então, minha pergunta aqui é quando devo usar a Programação Orientada a Objetos? Tudo bem criar programas sem Orientação a Objetos na Linguagem Orientada a Objetos? Por favor, me ajude neste.

PS: Não estou pedindo aqui para me dizer os méritos da Programação Orientada a Objetos sobre a programação procedural.

C ++ não é "apenas" uma linguagem OO, é uma linguagem com vários paradigmas. Portanto, permite que você decida a favor ou contra a programação OO ou misture os dois. O uso de técnicas OO adiciona mais estrutura ao seu programa - da qual você se beneficiará quando seu programa atingir um determinado tamanho ou complexidade. Essa estrutura adicional, no entanto, tem o preço de linhas de código adicionais. Portanto, para programas "pequenos", o melhor caminho a seguir é implementá-los primeiro em um estilo não OO e adicionar mais e mais técnicas OO mais tarde, quando o programa começar a crescer ao longo dos anos (o que provavelmente não acontecerá " ", mas é o ciclo de vida típico de muitos programas de negócios).

A parte complicada é não perder o momento em que a complexidade do seu programa atinge o tamanho que exige mais estrutura. Caso contrário, você terminará com uma pilha enorme de código de espaguete.

Como os programadores profissionais julgam se querem ou não fazer OOP? Seria realmente útil para mim.

Para mim, existem dois pontos de decisão. Primeiro, às vezes será óbvio no começo. Existem muitos tipos semelhantes que compartilham métodos comuns que diferem amplamente em seus detalhes de implementação. Por exemplo, eu estava construindo um sistema de fluxo de trabalho e precisava da capacidade de implementar tarefas arbitrárias. Para executar a tarefa, implementei uma classe base da qual cada tarefa foi herdada, com um Execute()método abstrato. As classes herdadas forneceram a implementação, mas o sistema de fluxo de trabalho poderia iniciar a execução sem saber nada sobre que tipo de tarefa estava sendo executada.

A maioria dos projetos não é tão clara assim. O segundo ponto de decisão é quando um subconjunto do projeto se transforma em um enorme emaranhado de instruções if-then ou de caso de troca e, especialmente, quando essas instruções if-then exigem muito código de instalação para serem executadas corretamente. Sinto-me começando a perder a lógica do que estou tentando realizar, e o código começa a parecer frágil. Nesse ponto, geralmente é um sinal de que é hora de refatorar o código em classes base com implementações específicas.

Uma grande parte da mudança para um estilo orientado a objeto, em oposição a um estilo funcional, é a conversão de instruções if-then em instruções "execute esta ação". Em vez de um enorme conjunto de instruções if-then, basta dizer ao código para executar sua ação. A ação realmente executada depende da implementação que você forneceu.

Por exemplo, aqui está o estilo funcional no pseudocódigo no estilo C #:

if ( action == "email" ) { 
    callEmailFunction(userInfo);
}
else if ( action == "sms" ) { 
    callSmsFunction(userInfo);
}
else if ( action == "web" ) { 
    endpoint = "http://127.0.0.1/confirm";
    confirmWeb(endpoint, userinfo);
} 
...

Mas talvez você possa reescrever isso para algo assim:

interface IConfirmable {
    void Confirm(UserInfo userinfo);
}

public class ConfirmEmail : IConfirmable { 
    public void Confirm(UserInfo userinfo) {
        // do the appropriate thing to confirm via email
    }
}

public class ConfirmSms : IConfirmable { 
    public void Confirm(UserInfo userinfo) {
        // do the appropriate thing to confirm via email
    }
}

public class ConfirmWeb : IConfirmable { 
    // this is a constructor
    public ConfirmWeb(string endpoint) { 
        ...
    }

    public void Confirm(UserInfo userinfo) {
        // do the appropriate thing to confirm via web
    }
} 

E então o próprio código:

// An implementation that decides which implementation of the base class to use
// This replaces the if-then statements in the functional programmming.
IConfirmable confirmer = ConfirmerFactory.GetConfirmer();

// get the userinfo however you get it, 
// which would be the same way you get it in the functional example.
UserInfo userinfo = ...;

// perform the action.
confirmer.Confirm(userinfo);

Agora, quando há muito pouco código dentro do if-then, parece muito trabalho para não se beneficiar. E quando há muito pouco código no if-then, isso está correto: é muito trabalho para código que é mais difícil de entender.

Mas o estilo orientado a objetos realmente brilha quando você tem mais de uma ação do que apenas o Confirm()método que precisa ser executado. Talvez você tenha uma rotina de inicialização, três ou mais métodos de ação que podem ser executados e um Cleanup()método. O algoritmo base é idêntico, exceto que faz suas chamadas nos objetos apropriados que implementam uma classe base comum. Agora você começa a ver um benefício real para o estilo orientado a objetos: o algoritmo base é muito mais fácil de ler do que se estivesse verificando as instruções if-then em todas as etapas do caminho.

Sim, é perfeitamente normal usar código de estilo antigo, desde que o escopo do seu projeto seja bem conhecido ou limitado. Se você planeja estender seu programa ou projeto OOP é um caminho a percorrer, porque você pode manter e estender seu código sem problemas, por outro lado, se o planejou e chegou à conclusão de que nunca planejará a extensibilidade do projeto que você faz, escrever código sem OOP seria suficiente. Isso não significa que, se você usar uma abordagem não OOP, nunca poderá atualizar seu projeto, mas seria uma coisa tediosa de se fazer. OOP é ajudar-nos a visualizar nosso conceito como se fosse um organismo da vida real, porque entendemos isso melhor do que qualquer outra coisa.