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

14

Recientemente se me asignó la tarea de crear una calculadora con funciones de suma, resta, multiplicación, división y potencia utilizando Programación Orientada a Objetos . He completado con éxito esta tarea. Sin embargo, luego reprogramé todo el programa sin utilizar técnicas / métodos orientados a objetos.

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

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

    
pregunta FaizanRabbani 23.12.2014 - 05:24
fuente

3 respuestas

24

C ++ no es "solo" un lenguaje OO, es un lenguaje de paradigma múltiple. Así que le permite decidir a favor o en contra de la programación OO, o mezclar ambos. El uso de técnicas OO agrega más estructura a su programa, de lo que se beneficiará cuando su programa alcance un cierto tamaño o complejidad. Esta estructura adicional, sin embargo, viene por el precio de líneas adicionales de código. Por lo tanto, para los programas "pequeños", la mejor manera es implementarlos primero en un estilo que no sea OO, y luego agregar más y más técnicas de OO cuando el programa comience a crecer con el paso de los años "programas, pero es el ciclo de vida típico para muchos programas de negocios).

La parte difícil es no perder el momento en el 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ódigos de espagueti.

    
respondido por el Doc Brown 23.12.2014 - 07:22
fuente
10
  

¿Cómo los programadores profesionales emiten juicios de opinión sobre si ir o no?   para OOP o no? Sería muy útil para mí.

Para mí, hay dos puntos de decisión. Primero, a veces será obvio al principio. Habrá muchos tipos similares que compartirán métodos comunes que difieren ampliamente en sus detalles de implementación. Por ejemplo, estaba creando 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 se heredó cada tarea, con un método abstracto Execute() . Las clases heredadas proporcionaron la implementación, pero el sistema de flujo de trabajo podría comenzar la ejecución sin saber nada sobre 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 sentencias if-then o de conmutación, y especialmente cuando esas sentencias if-then requieren una gran cantidad de código de configuración para ejecutarse correctamente. Siento que estoy empezando a perder la lógica de lo que estoy tratando de lograr, y el código comienza a sentirse frágil. En ese momento, 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 de "ejecutar esta acción". En lugar de un gran conjunto de declaraciones if-then, simplemente le dices al código que ejecute su acción. La acción que se ejecuta realmente depende de la implementación que proporcionó.

Por ejemplo, aquí está el estilo funcional en pseudocódigo de 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 quizás puedas reescribirlo 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 propio 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);

Ahora, cuando hay muy poco código dentro de if-then, parece que hay mucho trabajo para no obtener ningún beneficio. Y cuando hay muy poco código en el if-then, 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 tienes más de una acción que solo el método Confirm() que se debe realizar. Quizás tenga una rutina de inicialización, tres o más métodos de acción que se puedan ejecutar y un método Cleanup() . 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 las afirmaciones de if-then en cada paso del manera.

    
respondido por el Charlie Kilian 23.12.2014 - 07:01
fuente
3

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

    
respondido por el user50927 23.12.2014 - 09:46
fuente

Lea otras preguntas en las etiquetas