Programación no orientada a objetos en lenguaje orientado a objetos [cerrado]

Recientemente se me asignó la tarea de crear una calculadora con funciones de suma, resta, multiplicación, división y potencia usando la programación orientada a objetos . Completé con éxito esta tarea. Sin embargo, luego reprogramé todo el programa sin utilizar la técnica / método orientado a objetos .

Lo que noté fue que la longitud de mi código se redujo bastante significativamente y fue bastante comprensible. Entonces mi pregunta aquí es ¿cuándo debo usar la programación orientada a objetos? ¿Está bien crear programas sin orientación a objetos en lenguaje orientado a objetos? Amablemente ayúdame con esto.

PD: No estoy pidiendo aquí que me diga méritos de la Programación Orientada a Objetos sobre la programación de procedimientos.

C ++ no es "solo" un lenguaje OO, es un lenguaje multi-paradigmático. Por lo tanto, le permite decidir a favor o en contra de la programación OO, o mezclarlos a ambos. El uso de técnicas OO agrega más estructura a su programa, de lo cual se beneficiará cuando su programa alcance un cierto tamaño o complejidad. Sin embargo, esta estructura adicional viene por el precio de líneas de código adicionales. Entonces, para los programas "pequeños", la mejor manera de hacerlo es implementarlos primero en un estilo que no sea de OO, y agregar más y más técnicas de OO más tarde cuando el programa comience a crecer con los años (lo que probablemente no sucederá con el "ejercicio" ", pero es el ciclo de vida típico de muchos programas de negocios).

La parte difícil es no perder el momento en que la complejidad de su programa alcanza el tamaño que exige más estructura. De lo contrario, terminarás con una enorme pila de código de espagueti.

¿Cómo hacen los programadores profesionales para decidir si deben ir a OOP o no? Sería realmente útil para mí.

Para mí, hay dos puntos de decisión. Primero, a veces será obvio al principio. Habrá muchos tipos similares que comparten métodos comunes que difieren ampliamente en sus detalles de implementación. Por ejemplo, estaba construyendo un sistema de flujo de trabajo y necesitaba la capacidad de implementar tareas arbitrarias. Para ejecutar la tarea, implementé una clase base de la que cada tarea heredó, con un Execute()método abstracto. Las clases heredadas suministraron la implementación, pero el sistema de flujo de trabajo podría comenzar la ejecución sin saber qué tipo de tarea se estaba ejecutando.

Sin embargo, la mayoría de los proyectos no son tan claros. El segundo punto de decisión es cuando un subconjunto del proyecto se ha convertido en una gran maraña de declaraciones if-then o declaraciones de cambio de caso, y especialmente cuando esas declaraciones if-then requieren una gran cantidad de código de configuración para ejecutarse correctamente. Siento que empiezo a perder la lógica de lo que estoy tratando de lograr, y el código comienza a sentirse frágil. En ese punto, generalmente es una señal de que es hora de refactorizar el código en clases base con implementaciones específicas.

Una gran parte de cambiar a un estilo orientado a objetos en lugar de un estilo funcional es convertir las declaraciones if-then en declaraciones "ejecutar esta acción". En lugar de un gran conjunto de declaraciones if-then, simplemente le dice al código que ejecute su acción. La acción que realmente se ejecuta depende de la implementación que haya proporcionado.

Por ejemplo, aquí está el estilo funcional en el pseudocódigo 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);
} 
...

Pero tal vez podrías reescribir eso a algo como esto:

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
    }
} 

Y luego el código en sí:

// 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);

Ahora, cuando hay muy poco código dentro del if-then, esto parece mucho trabajo para no obtener ningún beneficio. Y cuando hay muy poco código en el si-entonces, eso es correcto: eso es mucho trabajo para el código que es más difícil de entender.

Pero el estilo orientado a objetos realmente brilla cuando tiene más de una acción que solo el Confirm()método que debe realizarse. Tal vez tenga una rutina de inicialización, tres o más métodos de acción que se pueden ejecutar y un Cleanup()método. El algoritmo base es idéntico, excepto que realiza sus llamadas a los objetos apropiados que implementan una clase base común. Ahora comienza a ver un beneficio real para el estilo orientado a objetos: el algoritmo base es mucho más fácil de leer que si estuviera verificando declaraciones if-then en cada paso del camino.

Sí, es perfectamente normal usar código de estilo antiguo, siempre que el alcance de su proyecto sea bien conocido o sea limitado. Si planea extender su programa o proyecto, OOP es un camino a seguir, porque puede mantener y extender su código sin problemas, por otro lado, si lo planeó y llegó a la conclusión de que nunca va a planear la extensibilidad del un proyecto que realice y luego escribir código sin OOP sería suficiente. No significa que si utiliza un enfoque que no sea OOP, nunca podrá actualizar su proyecto, pero sería algo tedioso. OOP es para ayudarnos a visualizar nuestro concepto como si fuera un organismo de la vida real porque los entendemos mejor que cualquier otra cosa.