Pregunta

El principio abierto/cerrado establece que las entidades de software (clases, módulos, etc.) deben estar abiertas a la extensión, pero cerradas a la modificación.¿Qué significa esto y por qué es un principio importante del buen diseño orientado a objetos?

¿Fue útil?

Solución

Específicamente, se trata de un "Santo Grial" del diseño en programación orientada a objetos: hacer que una entidad sea lo suficientemente extensible (a través de su diseño individual o de su participación en la arquitectura) para soportar futuros cambios imprevistos sin reescribir su código (y a veces incluso sin volver a compilar). **).

Algunas formas de hacer esto incluyen Polimorfismo/Herencia, Composición, Inversión de Control (también conocido comoDIP), programación orientada a aspectos, patrones como estrategia, visitante, método de plantilla y muchos otros principios, patrones y técnicas de OOAD.

** Consulte los 6 "principios del paquete", REP, PCC, CRP, ADP, SDP, SAP

Otros consejos

Significa que debes poner código nuevo en nuevas clases/módulos.El código existente debe modificarse sólo para corregir errores.Las nuevas clases pueden reutilizar el código existente mediante herencia.

El principio abierto/cerrado tiene como objetivo mitigar el riesgo al introducir nuevas funciones.Como no modifica el código existente, puede estar seguro de que no se dañará.Reduce el costo de mantenimiento y aumenta la estabilidad del producto.

Es la respuesta al frágil problema de las clases base, que dice que modificaciones aparentemente inocentes a las clases base pueden tener consecuencias no deseadas para los herederos que dependían del comportamiento anterior.Por lo tanto, debe tener cuidado de encapsular aquello en lo que no desea confiar para que las clases derivadas obedezcan los contratos definidos por la clase base.Y una vez que existen los herederos, hay que ser en realidad Cuidado con lo que cambias en la clase base.

Más específicamente que DaveK, generalmente significa que si desea agregar funcionalidad adicional o cambiar la funcionalidad de una clase, cree una subclase en lugar de cambiar la original.De esta manera, cualquiera que use la clase principal no tiene que preocuparse de que cambie más adelante.Básicamente, se trata de compatibilidad con versiones anteriores.

Otro principio realmente importante del diseño orientado a objetos es el acoplamiento flexible a través de una interfaz de método.Si el cambio que desea realizar no afecta la interfaz existente, realmente es bastante seguro cambiarlo.Por ejemplo, para hacer que un algoritmo sea más eficiente.Los principios orientados a objetos también deben ser atenuados por el sentido común :)

Las entidades de software deben estar abiertas a la extensión pero cerradas a la modificación.

Eso significa que cualquier clase o módulo debe escribirse de manera que pueda usarse tal como está, ampliarse, pero nunca modificado.

Mal ejemplo en Javascript

var juiceTypes = ['Mango','Apple','Lemon'];
function juiceMaker(type){
    if(juiceTypes.indexOf(type)!=-1)
        console.log('Here is your juice, Have a nice day');
    else
        console.log('sorry, Error happned');
}

exports.makeJuice = juiceMaker;

Ahora, si desea agregar otro tipo de jugo, debe editar el módulo en sí. De esta manera, estamos rompiendo OCP.

Buen ejemplo en Javascript

var juiceTypes = [];
function juiceMaker(type){
    if(juiceTypes.indexOf(type)!=-1)
        console.log('Here is your juice, Have a nice day');
    else
        console.log('sorry, Error happned');
}
function addType(typeName){
    if(juiceTypes.indexOf(typeName)==-1)
        juiceTypes.push(typeName);
}
function removeType(typeName){
  let index = juiceTypes.indexOf(typeName)
    if(index!==-1)
        juiceTypes.splice(index,1);
}

exports.makeJuice = juiceMaker;
exports.addType = addType;
exports.removeType = removeType;

Ahora puede agregar nuevos tipos de jugo desde fuera del módulo sin editar el mismo módulo.

El principio significa que debería ser fácil agregar nuevas funciones sin tener que cambiar las funciones existentes, estables y probadas, ahorrando tiempo y dinero.

A menudo, el polimorrismo, por ejemplo el uso de interfaces, es una buena herramienta para lograrlo.

Una regla general adicional para cumplir con OCP es hacer que las clases base sean abstractas con respecto a la funcionalidad proporcionada por las clases derivadas.O como dice Scott Meyers: "Hacer abstractas las clases que no son hojas".

Esto significa tener métodos no implementados en la clase base y solo implementar estos métodos en clases que no tienen subclases.Entonces el cliente de la clase base no puede confiar en una implementación particular en la clase base ya que no existe ninguna.

Sólo quiero enfatizar que "Abierto/Cerrado", aunque obviamente es útil en la programación orientada a objetos, es un método saludable para usar en todos los aspectos del desarrollo.Por ejemplo, en mi propia experiencia, es un gran analgésico usar "Abierto/Cerrado" tanto como sea posible cuando se trabaja con C simple.

/roberto

Esto significa que el software OO debe desarrollarse, pero no modificarse intrínsecamente.Esto es bueno porque garantiza un rendimiento confiable y predecible de las clases base.

Recientemente me dieron una idea adicional de lo que implica este principio:que el principio abierto-cerrado describe a la vez una forma de escribir código, así como el resultado final de escribir código de forma resiliente.

Me gusta pensar en Abierto/Cerrado dividido en dos partes estrechamente relacionadas:

  • código que es Abierto cambiar puede cambiar su comportamiento para manejar correctamente sus entradas o requiere una modificación mínima para proporcionar nuevos escenarios de uso.
  • código que es Cerrado La modificación no requiere mucha o ninguna intervención humana para manejar nuevos escenarios de uso.La necesidad simplemente no existe.

Por lo tanto, el código que exhibe un comportamiento Abierto/Cerrado (o, si lo prefiere, cumple el Principio Abierto/Cerrado) requiere una modificación mínima o nula en respuesta a escenarios de uso más allá de para lo que fue creado originalmente.

¿En lo que respecta a la implementación?Encuentro que la interpretación comúnmente declarada, "¡Abierto/cerrado se refiere al código que es polimórfico!" ser en el mejor de los casos una declaración incompleta.El polimorfismo en el código es una herramienta para lograr este tipo de comportamiento;Herencia, Implementación... en realidad, cada principio de diseño orientado a objetos es necesario para escribir código que sea resistente en la forma que implica este principio.

En principio de diseño, SOLID – la "O" en "SOLID" significa el principio abierto/cerrado.

El principio Abierto y Cerrado es un principio de diseño que dice que una clase, módulos y funciones deben estar abiertos a la extensión pero cerrados a la modificación.

Este principio establece que el diseño y la escritura del código deben realizarse de manera que se agreguen nuevas funciones con cambios mínimos en el código existente (código probado).El diseño debe realizarse de manera que permita agregar nuevas funcionalidades como nuevas clases, manteniendo lo más posible el código existente sin cambios.

Beneficio del principio de diseño abierto y cerrado:

  1. La aplicación será más sólida porque no cambiaremos la clase ya probada.
  2. Flexible porque podemos adaptarnos fácilmente a nuevos requisitos.
  3. Fácil de probar y menos propenso a errores.

Mi blog publica sobre esto:

http://javaexplorer03.blogspot.in/2016/12/open-closed-design-principle.html

Licenciado bajo: CC-BY-SA con atribución
No afiliado a StackOverflow
scroll top