Open/Closed Principle: Invita a usar las clases abstractas.
Abierto para la extensión (en el ejemplo ya existe factura , memo y recibo pero podría agregarse ticket, boleta, autorizaciones, etc) pero cerrado para la modificación, por lo tanto no se modifica nada:
(C#)
"La clase debe quedar abierta para añadir nuevos features, pero que esos nuevos features no impliquen modificar el código que ya estaba (A eso se refiere cerrada para su modificación)"
Es decir, todo el código nuevo que metamos debe adaptarse automáticamente con el código viejo que ya teníamos y no debe implicar modificar este código viejo.
Abierto a nuevos features, cerrado a modificación de features antiguos.
No entiendo PHP, pero ya entendí mucho mejor el concepto con tu aporte. Gracias Retax
explicación sencilla de entender, gracias!!
Principio de abierto/cerrado de Meyer:
Una clase está cerrada, dado que puede ser compilada, almacenada en una librería y usada por otras clases de cliente. Pero también está abierta, dado que a partir de ella podríamos crear nuevas subclases que incorporaran características nuevas. Y al crear una subclase, no hay ninguna necesidad de modificar las clases cliente de la superclase
De echo para que este principio funciones, los hijos que dependen de una clase padre o clase abstracta, deben respetar las características del padre. Con el el tercer principio (Liskov sustitution principle) comprenderás mejor ello.
El principio de abierto/cerrado nos propone una forma de estructurar nuestras clases para que estas se adapten a nuevos requerimientos sin la necesidad de modificar su estructura interna. (Dejarlas abiertas para su extensión y cerradas
a modificaciones).
me quedo mucho más claro, gracias
Este principio tiene dependencia en el concepto de "Polimorfismo", así que abordarlo este concepto antes de ver este video, te dará una mejor perspectiva de este principio.
no estuvo muy claro la clase. gracias por el aporte
Gracias, este video me ayudó a entender mejor el tema.
Open/closed Principle
Este principio nos propone una forma de estructurar nuestras clases, o sea una entidad de software debe quedarse abierta para su extensión, pero cerrada para su modificación.
Estos temas son buenísimos y mas si todo esto se combina con patrones de diseño se puede conseguir un desarrollo muy robusto.
Yo sigo un canal en youtube llamado BetaTech el cual es muy bueno desde mi punto de vista, en un video el habla de solid por lo que se meh ace interesante compartir este video
Una entidad debe estar abierta a la extensión pero cerrada a la modificación
Ampliar la funcionalidad agregando nuevo código en lugar de cambiar el código extendido.
Separe los comportamientos, para que el sistema se pueda ampliar fácilmente, pero nunca se rompa.
Objetivo: llegar a un punto en el que nunca puedas romper el núcleo de tu sistema.
En este ejemplo se puede apreciar que el User tiene el metodo "pay", que mediante este puede realizar un pago de acuerdo con el tipo de metodo de pago. Pero esto viola el principio ya que esta abierto para la modificacion, ya que payment esta abierto a modificacion.
Aplicando el principio se resolveria de la siguiente manera:
classPaypalPayment{publicfunctionpay(){}}classCreditCardPayment{publicfunctionpay(){}}classPaymentFactory{publicfunctioninitializePayment($type){if($type =='paypal'){returnnewPaypalPayment();}elseif($type =='credit'){returnnewCreditCardPayment();}thrownewException('No soportamos ese metodo de pago.');}}classUser{publicfunctionpay($type){ $paymentFactory =newPaymentFactory(); $payment = $paymentFactory->initializePayment($type); $payment->pay();}}
Ahora el metodo pay de la clase User solo necesita pasar el metodo de pago y no puede hacer mas, osea esta cerrado para modificion y la clase PaymentFactory esta abiero a eser extendido como por ejemplo agregar otro metodo de pago.
Por ejemplo en Java, yo creo que esto se solucionaría implementando una interfaz.
exacto puedes implementar una interfaz de tipo Document y hacer que invoice, receipt, memo y otros documentos lo implementen y asi respeten este contrato, asi cada una tendra una implementacion concreta, ademas usando interfaces esto son intercambiables yo agregaria algo como:
interfaceDocument{ publicfunctionprocess
}classMemoimplementsDocument{publicfunctionprocess(){ echo"processing a memo";}}classInvoiceimplementsDocument{publicfunctionprocess(){ echo"processing a invoice";}}classReceiptimplementsDocument{publicfunctionprocess(){ echo"processing a receipt";}}classDocProcessor{public $document;publicfunction__construct(Document $document){ $this->documents = $documents;return $this;}publicfunctionprocessDocuments(){return $this->documents->process();}}
de hecho con esto en vez de un array podrías recibir directamente cualquier objeto que implemente esta interfaz y ya si requieres usar un array puedes implementar un object value que sea algo asi como DocumentPile por ejemplo que sepa que debe recibir un array y de alguna manera separas tu código de forma mas reusable y ojo los typehints o return types en PHP no son obligatorios, como pasa en Dart y Javascript
O-Abierto/Cerrado (Open/Closed)
Principio atribuido a **Bertrand Meyer **que habla de crear clases extensibles sin necesidad de entrar al código fuente a modificarlo.
Es decir, el diseño debe ser abierto para poderse extender pero cerrado para poderse modificar. Aunque dicho parece fácil, lo complicado es predecir por donde se debe extender y que no tengamos que modificarlo.
Para conseguir este principio hay que tener muy claro como va a funcionar la aplicación, por donde se puede extender y como van a interactuar las clases.
En este video si concuerdo con algunos comentarios de que sería bueno verlo en otro lenguaje de programación, por ejemplo en el caso de esto de Open / Closed según como lo explico, yo que he estudiado c# lo miraría como tener una interfaz documento la cual se implementaría para cada uno de los tipos de documentos, entonces en la clase principal donde se vaya a llamar el evento procesar, se llamaría al método process() de la interfaz del documento que donde se implemento, al menos así lo miraría un poco más claro. Con esto ya teniendo en esa estructura en el futuro por ejemplo si viene un nuevo tipo de documento, por ejemplo Boleta, este implementaría la interfaz Documento y a su ves estaría el método Process(), ya no se tendría que modificar la clase desde donde se manda a llamar process, pero al final no puedo negar que te da un punto de partida para que uno mismo sea autodidacta y se esfuerce en buscar algo más de información y como podría hacer las cosas.
Me cuesta trabajo el como pensar meter todo a una recursividad
Entonces lo correcto sería crear una nueva clase para cada tipo de documento con su respectivo metodo process??? Eso me suena un poco como los getters y los setters
Este principio nos enseña a pensar siempre en el futuro (nuevos requerimientos)
Cada Documento tendrá una clase que atienda cada tipo de Documento ... Asi son mas adaptables al entorno.
Me hubiera gustado que escriba el código de todo lo que esta explicando para entenderlo mejor.
En resumidas cuentas.
Si todos los tipos de documento hacen el mismo proceso, pero de una manera diferente dependiendo el tipo, se lo pone como método de esa clase y se pueden añadir cuantas clases diferentes quiera.
¿Estoy en lo correcto?
No me quedo muy claro. Entonces la idea es que cada clase debe separarse para que se enfoque en su propio proceso?
podría decirse que si, y cumpliríamos el principio uno de que tenga una sola responsabilidad, en este ejemplo el procesar el tipo de documento quedaría en otra clase
Al profesor le falto dar mas información en el ejemplo. Lo que se hace es abstraer el metodo "process" en una interfaz que sea implementado por cada tipo de documento.
Open/Closed principle/ Principio de abierto cerrado
Una entidad de software debe quedarse abierta para su extensión, pero cerrada para su modificación
Es repartir las responsabilidades a los objetos de una mejor manera. Esto nos da la ventaja de que sean más adaptables al entorno.
