Principio de apertura / cierre y reapertura de clases de Ruby

7

En la POO hay un principio Abierto / Cerrado que establece que

  

"las entidades de software (clases, módulos, funciones, etc.) deben estar abiertas por extensión, pero cerradas por modificación".

Teniendo en cuenta que en Ruby es posible volver a abrir una clase, ¿no crees que esto rompe el principio de Abierto / Cerrado?

¿Cuándo crees que deberíamos favorecer la reapertura de clases en lugar de simplemente extenderlas?

¿Qué crees que son las trampas en la reapertura de clases?

    
pregunta Tudor Constantin 10.05.2011 - 07:48

1 respuesta

6

Las clases abiertas de Ruby proporcionan una manera de construir programáticamente clases complejas. Para bibliotecas complicadas, esto facilita la configuración y el código es más pequeño y más fácil de mantener. Si alguna vez te encuentras con un programador de Lisp, te hablarán sobre lo maravilloso que es usar el código para escribir código.

Este poder puede ser usado tanto para el bien como para el mal. La práctica de la funcionalidad Monkey Patching en una clase es conveniente, pero también es una forma de deuda técnica que hará más difícil mantenerse actualizado y mantener el código.

Una buena regla general es que una clase debe ser reabierta solo por la persona (grupo) que la escribió originalmente. Si otros se sienten, entonces necesita volver a abrir una de sus clases, eso es probablemente una señal de que necesita ser refactorizada para que sea más configurable, que está abierto para la extensión. Este es el D de SOLID .

    
respondido por el John F. Miller 10.05.2011 - 08:32

Lea otras preguntas en las etiquetas