¿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.