Hola Habr! Aquí hay una traducción de un artículo de Robert Martin del Principio Abierto-Cerrado , que publicó en enero de 1996. El artículo, por decirlo suavemente, no es el último. Pero en RuNet, los artículos del tío Bob sobre SOLID se vuelven a contar solo en forma truncada, por lo que pensé que una traducción completa no sería superflua.

Decidí comenzar con la letra O, ya que el principio de apertura-cierre, de hecho, es central. Entre otras cosas, hay muchas sutilezas importantes a las que vale la pena prestarles atención:

• Ningún programa puede ser "cerrado" al 100%.
• La programación orientada a objetos (OOP) opera no con objetos físicos del mundo real, sino con conceptos, por ejemplo, el concepto de "ordenar".

Este es el primer artículo en mi columna de Notas del ingeniero para The C ++ Report . Los artículos publicados en esta columna se centrarán en el uso de C ++ y OOP y abordarán las dificultades en el desarrollo de software. Intentaré hacer que los materiales sean pragmáticos y útiles para los ingenieros en ejercicio. Para la documentación del diseño orientado a objetos en estos artículos, usaré la notación de Buch.

Hay muchas heurísticas asociadas con la programación orientada a objetos. Por ejemplo, "todas las variables miembro deben ser privadas", o "se deben evitar las variables globales", o "la determinación de tipo en tiempo de ejecución es peligrosa". ¿Cuál es la razón de tales heurísticas? ¿Por qué son verdad? ¿Son siempre ciertas? Esta columna explora el principio de diseño que subyace a estas heurísticas: el principio de apertura-cierre.
Ivar Jacobson dijo: “Todos los sistemas cambian durante el ciclo de vida. Esto debe tenerse en cuenta al diseñar un sistema que tenga más de una versión esperada ". ¿Cómo podemos diseñar un sistema para que sea estable frente al cambio y que tenga más de una versión esperada? Bertrand Meyer nos contó sobre esto en 1988, cuando se formuló el ahora famoso principio de apertura-cercanía:

Las entidades del programa (clases, módulos, funciones, etc.) deben estar abiertas para expansión y cerradas para cambios.

Si un cambio en el programa implica una cascada de cambios en los módulos dependientes, entonces aparecen signos indeseables de un diseño "malo" en el programa.

El programa se vuelve frágil, inflexible, impredecible y sin uso. El principio de apertura-cercanía resuelve estos problemas de una manera muy directa. Él dice que es necesario diseñar módulos que nunca cambien . Cuando los requisitos cambian, debe expandir el comportamiento de dichos módulos agregando un código nuevo, en lugar de cambiar el código antiguo que ya funciona.

Descripción

Los módulos que cumplen con el principio de apertura-cercanía tienen dos características principales:

1. Abierto a la expansión. Esto significa que el comportamiento del módulo se puede ampliar. Es decir, podemos agregar un nuevo comportamiento al módulo de acuerdo con los requisitos cambiantes para la aplicación o para satisfacer las necesidades de las nuevas aplicaciones.
2. Cerrado por cambio. El código fuente de dicho módulo es intocable. Nadie tiene derecho a hacerle cambios.

Parece que estos dos signos no encajan entre sí. La forma estándar de extender el comportamiento de un módulo es hacer cambios en él. Un módulo que no se puede cambiar generalmente se considera un módulo con comportamiento fijo. ¿Cómo se pueden cumplir estas dos condiciones opuestas?

La clave de la solución es la abstracción.

En C ++, utilizando los principios del diseño orientado a objetos, es posible crear abstracciones fijas que pueden representar un conjunto ilimitado de posibles comportamientos.

Las abstracciones son clases base abstractas, y todas las posibles clases sucesoras representan un conjunto ilimitado de posibles comportamientos. Un módulo puede manipular la abstracción. Dicho módulo está cerrado por cambios, ya que depende de una abstracción fija. Además, el comportamiento del módulo se puede ampliar creando nuevos descendientes de abstracción.

El siguiente diagrama muestra una opción de diseño simple que no cumple con el principio de apertura-cercanía. Ambas clases, Client y Server , no son abstractas. No hay garantía de que las funciones que son miembros de la clase Server sean virtuales. La clase Client usa la clase Server . Si queremos que el objeto de la clase Client use un objeto de servidor diferente, debemos cambiar la clase Client para hacer referencia a la nueva clase de servidor.

Cliente cerrado

Y el siguiente diagrama muestra la opción de diseño correspondiente, que cumple con el principio de apertura-cercanía. En este caso, la clase AbstractServer es una clase abstracta, cuyas funciones miembro son virtuales. La clase Client usa abstracción. Sin embargo, los objetos de la clase Client utilizarán objetos de la clase sucesora del Server . Si queremos que los objetos de la clase Client utilicen una clase de servidor diferente, presentaremos un nuevo descendiente de la clase AbstractServer . La clase del Client permanecerá sin cambios.

Cliente abierto

Resumen de Shape

Considere una aplicación que debería dibujar círculos y cuadrados en una GUI estándar. Los círculos y cuadrados se deben dibujar en un orden específico. En el orden correspondiente, se compilará una lista de círculos y cuadrados, el programa debe revisar esta lista en el orden y dibujar cada círculo o cuadrado.

En C, utilizando técnicas de programación de procedimientos que no cumplen con el principio de apertura y cierre, podríamos resolver este problema como se muestra en el Listado 1. Aquí vemos muchas estructuras de datos con el mismo primer elemento. Este elemento es un código de tipo que identifica la estructura de datos como un círculo o cuadrado. La función DrawAllShapes pasa a través de una matriz de punteros a estas estructuras de datos, reconociendo el código de tipo y luego llamando a la función correspondiente ( DrawCircle o DrawSquare ).

 // 1 //  /    enum ShapeType {circle, square} struct Shape { ShapeType itsType; }; struct Circle { ShapeType itsType; double itsRadius; Point itsCenter; }; struct Square { ShapeType itsType; double itsSide; Point itsTopLeft; }; // //     // void DrawSquare(struct Square*) void DrawCircle(struct Circle*); typedef struct Shape *ShapePointer; void DrawAllShapes(ShapePointer list[], int n) { int i; for (i=0; i<n; i++) { struct Shape* s = list[i]; switch (s->itsType) { case square: DrawSquare((struct Square*)s); break; case circle: DrawCircle((struct Circle*)s); break; } } } 

La función DrawAllShapes no cumple el principio de apertura-cierre, ya que no se puede "cerrar" a partir de nuevos tipos de formas. Si quisiera expandir esta función con la capacidad de dibujar formas de una lista que incluye triángulos, entonces necesitaría cambiar la función. De hecho, tengo que cambiar la función para cada nuevo tipo de forma que necesito dibujar.

Por supuesto, este programa es solo un ejemplo. En la vida real, el operador del switch de la función DrawAllShapes se repetiría una y otra vez en varias funciones a lo largo de la aplicación, y cada una haría algo diferente. Agregar nuevas formas a una aplicación de este tipo significa encontrar todos los lugares donde se usan tales switch (o cadenas if/else ) y agregar una nueva forma a cada una de ellas. Además, es muy poco probable que todas las switch y las cadenas if/else estén tan bien estructuradas como en DrawAllShapes . Es mucho más probable que los predicados en if se combinen con operadores lógicos, o los bloques de case y case de las switch de switch se combinen de tal manera que "simplifiquen" un lugar particular en el código. Por lo tanto, el problema de encontrar y comprender todos los lugares donde necesita agregar una nueva figura no puede ser trivial.

En el Listado 2, mostraré el código que demuestra una solución cuadrada / circular que cumple con el principio de apertura-cierre. Se introduce una clase de Shape abstracta. Esta clase abstracta contiene una función de Draw virtual pura. Las clases Circle y Square son descendientes de la clase Shape .

 // 2 //  /  - class Shape { public: virtual void Draw() const = 0; }; class Square : public Shape { public: virtual void Draw() const; }; class Circle : public Shape { public: virtual void Draw() const; }; void DrawAllShapes(Set<Shape*>& list) { for (Iterator<Shape*>i(list); i; i++) (*i)->Draw(); } 

Tenga en cuenta que si queremos extender el comportamiento de la función DrawAllShapes en el Listado 2 para dibujar un nuevo tipo de forma, todo lo que tenemos que hacer es agregar un nuevo descendiente de la clase Shape . No es necesario cambiar la función DrawAllShapes . Por lo tanto, DrawAllShapes cumple con el principio de apertura-cercanía. Su comportamiento se puede ampliar sin cambiar la función en sí.

En el mundo real, la clase Shape contendría muchos otros métodos. Y, sin embargo, agregar una nueva forma a la aplicación sigue siendo muy simple, ya que todo lo que necesita hacer es ingresar un nuevo heredero e implementar estas funciones. No es necesario explorar toda la aplicación en busca de lugares que requieran cambios.

Por lo tanto, los programas que cumplen con el principio de apertura-cercanía se cambian agregando un nuevo código, y no cambiando el existente; no cambian en cascada los cambios característicos de los programas que no corresponden a este principio.

Estrategia de entrada cerrada

Obviamente, ningún programa puede estar 100% cerrado. Por ejemplo, ¿qué le sucede a la función DrawAllShapes en el Listado 2 si decidimos que primero deben dibujarse círculos y luego cuadrados? La función DrawAllShapes no DrawAllShapes cerrada por este tipo de cambio. En general, no importa cuán "cerrado" esté el módulo, siempre hay algún tipo de cambio desde el cual no está cerrado.

Como el cierre no puede ser completo, debe ser introducido estratégicamente. Es decir, el diseñador debe elegir los tipos de cambios a partir de los cuales se cerrará el programa. Esto requiere algo de experiencia. Un desarrollador experimentado conoce a los usuarios y la industria lo suficientemente bien como para calcular la probabilidad de varios cambios. Luego se asegura de que se respete el principio de apertura-cercanía para los cambios más probables.

Uso de la abstracción para lograr una cercanía adicional.

¿Cómo podemos cerrar la función DrawAllShapes de los cambios en el orden de dibujo? Recuerde que el cierre se basa en la abstracción. Por lo tanto, para cerrar DrawAllShapes del pedido, necesitamos algún tipo de "abstracción de pedido". Un caso especial de pedido, presentado anteriormente, es dibujar figuras de un tipo frente a figuras de otro tipo.

La política de pedidos implica que con dos objetos, puede determinar cuál debe dibujarse primero. Por lo tanto, podemos definir un método para la clase Shape llamado Precedes , que toma otro objeto Shape como argumento y devuelve un valor booleano true si el objeto Shape que recibió este mensaje necesita ser ordenado antes que el objeto Shape que fue Pasado como argumento.

En C ++, esta función se puede representar como una sobrecarga del operador "<". El Listado 3 muestra la clase Shape con métodos de clasificación.

Ahora que tenemos una manera de determinar el orden de los objetos de la clase Shape , podemos ordenarlos y luego dibujarlos. El Listado 4 muestra el código C ++ correspondiente. Utiliza las clases Set , OrderedSet e OrderedSet de la categoría Components desarrollada en mi libro (Diseño de aplicaciones C ++ orientadas a objetos utilizando el método Booch, Robert C. Martin, Prentice Hall, 1995).

Entonces, hemos implementado el orden de los objetos de la clase Shape y dibujándolos en el orden apropiado. Pero todavía no tenemos una implementación de la abstracción del orden. Obviamente, cada objeto Shape debe anular el método Precedes para determinar el orden. ¿Cómo puede funcionar esto? ¿Qué código se debe escribir en Circle::Precedes para que los círculos se dibujen en cuadrados? Presta atención al listado 5.

 // 3 //  Shape    . class Shape { public: virtual void Draw() const = 0; virtual bool Precedes(const Shape&) const = 0; bool operator<(const Shape& s) {return Precedes(s);} }; 

 // 4 // DrawAllShapes   void DrawAllShapes(Set<Shape*>& list) { //    OrderedSet  . OrderedSet<Shape*> orderedList = list; orderedList.Sort(); for (Iterator<Shape*> i(orderedList); i; i++) (*i)->Draw(); } 

 // 5 //    bool Circle::Precedes(const Shape& s) const { if (dynamic_cast<Square*>(s)) return true; else return false; } 

Está claro que esta función no cumple con el principio de apertura-cercanía. No hay forma de cerrarlo de los nuevos descendientes de la clase Shape . Cada vez que aparece un nuevo descendiente de la clase Shape , esta función debe cambiarse.

Uso de un enfoque basado en datos para lograr el cierre

La cercanía de los herederos de la clase Shape se puede lograr utilizando un enfoque tabular que no provoca cambios en cada clase heredada. Un ejemplo de este enfoque se muestra en el Listado 6.

Usando este enfoque, cerramos con éxito la función DrawAllShapes de los cambios relacionados con el pedido, y cada descendiente de la clase Shape , desde la introducción de un nuevo descendiente o de un cambio en la política de pedidos para los objetos de la clase Shape dependiendo de su tipo (por ejemplo, los objetos de la clase Squares deberían ser dibujado primero).

 // 6 //     #include <typeinfo.h> #include <string.h> enum {false, true}; typedef int bool; class Shape { public: virtual void Draw() const = 0; virtual bool Precedes(const Shape&) const; bool operator<(const Shape& s) const {return Precedes(s);} private: static char* typeOrderTable[]; }; char* Shape::typeOrderTable[] = { "Circle", "Square", 0 }; //      . //   ,    //  . ,    , //      bool Shape::Precedes(const Shape& s) const { const char* thisType = typeid(*this).name(); const char* argType = typeid(s).name(); bool done = false; int thisOrd = -1; int argOrd = -1; for (int i=0; !done; i++) { const char* tableEntry = typeOrderTable[i]; if (tableEntry != 0) { if (strcmp(tableEntry, thisType) == 0) thisOrd = i; if (strcmp(tableEntry, argType) == 0) argOrd = i; if ((argOrd > 0) && (thisOrd > 0)) done = true; } else // table entry == 0 done = true; } return thisOrd < argOrd; } 

El único elemento que no está cerrado al cambiar el orden de las formas de dibujo es una tabla. La tabla se puede colocar en un módulo separado, separado de todos los demás módulos y, por lo tanto, sus cambios no afectarán a otros módulos.

Cierre adicional

Este no es el final de la historia. Cerramos la jerarquía de la clase Shape y la función DrawAllShapes de cambiar la política de ordenamiento en función del tipo de formas. Sin embargo, los descendientes de la clase Shape no están excluidos de las políticas de pedido que no están asociadas con los tipos de Shape . Parece que necesitamos organizar el dibujo de formas de acuerdo con una estructura de nivel superior. Un estudio completo de tales problemas está más allá del alcance de este artículo; sin embargo, un lector interesado podría pensar cómo resolver este problema utilizando la clase abstracta OrderedObject contenida en la clase OrderedShape , que hereda de las OrderedObject Shape y OrderedObject .

Heurística y Convenciones

Como se mencionó al principio del artículo, el principio de apertura-cercanía es la motivación clave detrás de muchas heurísticas y convenciones que han surgido durante los años de desarrollo del paradigma OOP. Los siguientes son los más importantes.

Hacer que todas las variables miembro sean privadas

Esta es una de las convenciones más duraderas de la OLP. Las variables miembro solo deben ser conocidas por los métodos de la clase en la que se definen. Los miembros variables no deben ser conocidos por ninguna otra clase, incluidas las clases derivadas. Por lo tanto, deben declararse con un modificador de acceso private , no public o protected .
A la luz del principio de apertura-cercanía, la razón de tal convención es comprensible. Cuando las variables miembro de la clase cambian, cada función que depende de ellas debe cambiar. Es decir, la función no está cerrada por cambios en estas variables.

En OOP, esperamos que los métodos de una clase no estén cerrados a los cambios en las variables que son miembros de esta clase. Sin embargo, esperamos que cualquier otra clase, incluidas las subclases, esté cerrada por cambios en estas variables. Esto se llama encapsulación.

Pero, ¿qué sucede si tiene una variable sobre la que está seguro de que nunca cambiará? ¿Tiene sentido hacerlo private ? Por ejemplo, el Listado 7 muestra la clase de Device que contiene el bool status miembro variable. Almacena el estado de la última operación. Si la operación fue exitosa, entonces el valor de la variable de status será true , de lo contrario false .

 // 7 //   class Device { public: bool status; }; 

Sabemos que el tipo o significado de esta variable nunca cambiará. Entonces, ¿por qué no hacerlo public y darle acceso directo al cliente? Si la variable realmente nunca cambia, si todos los clientes siguen las reglas y solo leen de esta variable, entonces no hay nada de malo en el hecho de que la variable es pública. Sin embargo, considere lo que sucederá si uno de los clientes aprovecha la oportunidad para escribir en esta variable y cambiar su valor.

De repente, este cliente puede afectar el funcionamiento de cualquier otro cliente de la clase Device . Esto significa que es imposible cerrar clientes de la clase Device por cambios en este módulo incorrecto. Esto es demasiado riesgo.

Por otro lado, supongamos que tenemos la clase Time , que se muestra en el Listado 8. ¿Cuál es el peligro de la publicidad de las variables que son miembros de esta clase? Es muy poco probable que cambien. Además, no importa si los módulos del cliente cambian los valores de estas variables o no, ya que se supone un cambio en estas variables. También es muy poco probable que las clases heredadas puedan depender del valor de una variable miembro en particular. Entonces, ¿hay un problema?

 // 8 class Time { public: int hours, minutes, seconds; Time& operator-=(int seconds); Time& operator+=(int seconds); bool operator< (const Time&); bool operator> (const Time&); bool operator==(const Time&); bool operator!=(const Time&); }; 

La única queja que podría hacerle al código en el Listado 8 es que el cambio de hora no es atómico. Es decir, el cliente puede cambiar el valor de la variable minutes sin cambiar el valor de la variable hours . Esto puede hacer que un objeto de la clase Time contenga datos inconsistentes. Preferiría introducir una sola función para configurar el tiempo, que tomaría tres argumentos, lo que haría que configurar el tiempo sea una operación atómica. Pero este es un argumento débil.

Es fácil encontrar otras condiciones bajo las cuales la publicidad de estas variables pueda generar problemas. Sin embargo, en última instancia, no hay una razón convincente para hacerlos private . Sigo pensando que hacer públicas tales variables es un mal estilo, pero tal vez no sea un mal diseño. Creo que este es un mal estilo, porque no cuesta casi nada ingresar a las funciones apropiadas para acceder a estos miembros, y definitivamente vale la pena protegerse del pequeño riesgo asociado con la posible aparición de problemas con el cierre.

Por lo tanto, en casos tan raros, cuando no se viola el principio de apertura-cierre, la prohibición de public variables public y protected depende más del estilo y no del contenido.

No hay variables globales ... en absoluto!

El argumento contra las variables globales es el mismo que el argumento contra las variables de miembros públicos. Ningún módulo que dependa de una variable global puede cerrarse desde un módulo que pueda escribir en él. Cualquier módulo que use esta variable de una manera no prevista por otros módulos los romperá. Es demasiado arriesgado tener muchos módulos, dependiendo de los caprichos de un solo módulo malicioso.
Por otro lado, en los casos en que las variables globales tienen una pequeña cantidad de módulos que dependen de ellos o no se pueden usar de manera incorrecta, no causan daño. El diseñador debe evaluar cuánta privacidad se sacrifica y determinar si la conveniencia que brinda la variable global vale la pena.

Aquí nuevamente, los problemas de estilo entran en juego. Las alternativas al uso de variables globales suelen ser de bajo costo. En tales casos, el uso de una técnica que introduce, aunque pequeño, pero un riesgo de cierre en lugar de una técnica que elimina por completo ese riesgo, es una señal de mal estilo. Sin embargo, a veces usar variables globales es realmente conveniente. Un ejemplo típico son las variables globales cout y cin. En tales casos, si no se viola el principio de apertura-cercanía, puede sacrificar el estilo por conveniencia.

RTTI es peligroso

Otra prohibición común es el uso de dynamic_cast . Muy a menudo, dynamic_cast o alguna otra forma de determinación del tipo de tiempo de ejecución (RTTI) es acusado de ser una técnica extremadamente peligrosa y, por lo tanto, debe evitarse. Al mismo tiempo, a menudo dan un ejemplo del Listado 9, que obviamente viola el principio de apertura-cercanía. Sin embargo, el Listado 10 muestra un ejemplo de un programa similar que usa dynamic_cast sin violar el principio de abrir-cerrar.

La diferencia entre ellos es que, en el primer caso, que se muestra en el Listado 9, el código debe cambiarse cada vez que aparece un nuevo descendiente de la clase Shape (sin mencionar que esta es una solución absolutamente ridícula). Sin embargo, en el Listado 10, no se requieren cambios en este caso. Por lo tanto, el código en el Listado 10 no viola el principio de abrir-cerrar.
En este caso, la regla general es que RTTI se puede usar si no se viola el principio de apertura-cierre.

 // 9 //RTTI,   -. class Shape {}; class Square : public Shape { private: Point itsTopLeft; double itsSide; friend DrawSquare(Square*); }; class Circle : public Shape { private: Point itsCenter; double itsRadius; friend DrawCircle(Circle*); }; void DrawAllShapes(Set<Shape*>& ss) { for (Iterator<Shape*>i(ss); i; i++) { Circle* c = dynamic_cast<Circle*>(*i); Square* s = dynamic_cast<Square*>(*i); if (c) DrawCircle(c); else if (s) DrawSquare(s); } } 

 // 10 //RTTI,    -. class Shape { public: virtual void Draw() cont = 0; }; class Square : public Shape { // . }; void DrawSquaresOnly(Set<Shape*>& ss) { for (Iterator<Shape*>i(ss); i; i++) { Square* s = dynamic_cast<Square*>(*i); if (s) s->Draw(); } } 

Conclusión

Podría hablar durante mucho tiempo sobre el principio de apertura-cercanía. En muchos sentidos, este principio es más importante para la programación orientada a objetos. El cumplimiento de este principio particular proporciona las ventajas clave de la tecnología orientada a objetos, a saber, reutilización y soporte.

, - -. , , , , , .