Programação Orientada a Não Objetos em Linguagem Orientada a Objetos [closed]

14

Recentemente me foi atribuída uma tarefa de criar uma calculadora com adição, subtração, multiplicação, divisão e potência de funções usando Programação Orientada a Objetos . Eu completei esta tarefa com sucesso. No entanto, depois reprogramou todo o programa sem usar técnica / método Orientada a Objetos.

A coisa que eu notei foi que o tamanho do meu código foi reduzido significativamente e foi bastante compreensível. Então, minha pergunta aqui é quando devo usar a programação orientada a objetos? Não há problema em criar programas sem orientação de objeto na linguagem orientada a objetos? Por favor, me ajudem com isso.

PS: Eu não estou pedindo aqui para me dizer méritos de Programação Orientada a Objetos em programação procedural.

    
por FaizanRabbani 23.12.2014 / 05:24
fonte

3 respostas

24

C ++ não é "apenas" uma linguagem OO, é uma linguagem multi-paradigmática. Por isso, 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 - a partir do qual você se beneficiará quando seu programa atingir um determinado tamanho ou complexidade. Essa estrutura adicional, no entanto, vem pelo preço de linhas adicionais de código. Portanto, para programas "pequenos" o melhor caminho é implementá-los primeiro em um estilo não-OO, e adicionar mais técnicas OO mais tarde quando o programa começar a crescer ao longo dos anos (o que provavelmente não acontecerá com "exercício" "programas, mas é o ciclo de vida típico para 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ê vai acabar com uma enorme pilha de código de espaguete.

    
por 23.12.2014 / 07:22
fonte
10

How do professional programmers make judgement call on whether to go for OOP or not? It would be really helpful for me.

Para mim, existem dois pontos de decisão. Primeiro, às vezes será óbvio no começo. Haverá muitos tipos semelhantes que compartilham métodos comuns que diferem amplamente em seus detalhes de implementação. Por exemplo, eu estava criando 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 método Execute() abstract. As classes herdadas forneciam a implementação, mas o sistema de fluxo de trabalho podia começar a execução sem saber nada sobre o tipo de tarefa que 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 transformou em um grande emaranhado de instruções if-then ou instruções de caso de comutação e, especialmente, quando essas instruções if-then exigem muito código de configuraçã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, é converter instruções if-then em instruções "executar esta ação". Em vez de um conjunto enorme de instruções if-then, basta informar o código para executar sua ação. Qual ação é realmente executada depende da implementação que você forneceu.

Por exemplo, aqui está o estilo funcional no pseudocódigo em 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 código em si:

// 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, isso parece muito trabalho para não obter nenhum benefício. E quando há muito pouco código no if-then, isso é 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 método Confirm() que precisa ser executado. Talvez você tenha uma rotina de inicialização, três ou mais métodos de ação que possam ser executados e um método Cleanup() . O algoritmo de base é idêntico, exceto por fazer 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 instruções if-then em todas as etapas do maneira.

    
por 23.12.2014 / 07:01
fonte
3

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 você planejou e chegou a uma conclusão de que você nunca vai planejar a extensibilidade do projeto que você faz, em seguida, escrever código sem OOP seria suficiente. Isso não significa que, se você usar a abordagem OOP, você nunca poderá atualizar seu projeto, mas seria uma tarefa tediosa. OOP é para nos ajudar a visualizar o nosso conceito como se fosse um organismo da vida real, porque entendemos melhor do que qualquer outra coisa.

    
por 23.12.2014 / 09:46
fonte