Open/Closed Principle

Clase 12 de 26 • Curso de Patrones de Diseño y Buenas Prácticas en PHP

Resumen

Open/Closed Principle establece que una entidad de software debe quedarse abierta para su extensión, pero cerrada para su modificación.

Guillermo Ruiz Alvarado

student•

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#)

abstract class Documentos{
    public abstract void Process(); 
}
class Factura: Documentos { }
class Recibo: Documentos { }
class Memo : Documentos { }
class Ticket : Documentos { }
class Autorizaciones : Documentos { }

class Comprobante
{
    public void ComprobanteProcess(Documentos docs)
    {        
	docs.Process();
    }
}```

Creck Brayan Mauri Pastor Paredes

student•

apuntado

Usuario anónimo

user•

¡Anotado!

Carlos Eduardo Gomez García

teacher•

Una manera más fácil de ver este principio es:

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

Orlando Jose Altamiranda Piñango

student•

No entiendo PHP, pero ya entendí mucho mejor el concepto con tu aporte. Gracias Retax

Adan Uri Plata Estrada

student•

explicación sencilla de entender, gracias!!

Juan Pena Verdú

student•

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

JOSE LUIS DAMIAN SAAVEDRA

student•

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.

Bernardo Ayala Montezuma

student•

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

Bernardo Aguayo Ortega

student•

me quedo mucho más claro, gracias

JOSE LUIS DAMIAN SAAVEDRA

student•

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.

Jhon Alexander Romero Gonzaga

student•

Si no esta muy claro el Open/Closed Principle, en este video esta mas comprensible: https://www.youtube.com/watch?v=lOg2IuQIp-s

Alexander Agrazal

student•

no estuvo muy claro la clase. gracias por el aporte

Elisa Zamarron Muñoz

student•

Gracias, este video me ayudó a entender mejor el tema.

María Sierra

student•

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.

Jorge Méndez Ortega

student•

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

https://www.youtube.com/watch?v=2X50sKeBAcQ

Jose Rios

student•

Excelente, me voy a suscribir, no lo conocía

Victor Gomez

student•

Un video para complementar el contenido de la clase: https://www.youtube.com/watch?v=2X50sKeBAcQ

Jose Rios

student•

Gracias por compartir!

Daniel Ponce

student•

PRINCIPIO DE ABIERTO/CERRADO

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.

class Payment
{
    public function payWithPaypal()
    {
    }

    public function payWithCreditCard()
    {
    }
}

class User
{

    public function pay($type)
    {
        $payment = new Payment();

        if ($type == "paypal") {
            $payment->payWithPaypal();
        } elseif ($type == "credit") {
            $payment->payWithCreditCard();
        }
    }
}

Aplicando el principio se resolveria de la siguiente manera:

class PaypalPayment
{
    public function pay()
    {
    }
}

class CreditCardPayment
{
    public function pay()
    {
    }
}

class PaymentFactory
{
    public function initializePayment($type)
    {
        if ($type == 'paypal') {
            return new PaypalPayment();
        } elseif ($type == 'credit') {
            return new CreditCardPayment();
        }

        throw new Exception('No soportamos ese metodo de pago.');
    }
}

class User{
    
    public function pay($type)
    {
        $paymentFactory = new PaymentFactory();
        $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.

Jose Manuel del Villar Soriano

student•

Por ejemplo en Java, yo creo que esto se solucionaría implementando una interfaz.

Fernando Mejia

student•

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&quot;processing a memo&quot;;	
	}
}

classInvoiceimplementsDocument{
	publicfunctionprocess() 
	{
		echo&quot;processing a invoice&quot;;	
	}
}

classReceiptimplementsDocument{
	publicfunctionprocess() 
	{
		echo&quot;processing a receipt&quot;;	
	}
}

classDocProcessor{

	public $document;

	public function__construct( Document $document) 
	{
		$this-&gt;documents = $documents;
		return $this;	
	}

	public functionprocessDocuments()
	{
		return $this-&gt;documents-&gt;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

Marcos Orozco Rios

student•

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.

Leonel Absalon Blanco Castillo

student•

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.

Daniel Carmona

student•

Me cuesta trabajo el como pensar meter todo a una recursividad

Fernando Arriola Colunga

student•

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

Christian David Sánchez

student•

Este principio nos enseña a pensar siempre en el futuro (nuevos requerimientos)

Fernando Hernandez

student•

Cada Documento tendrá una clase que atienda cada tipo de Documento ... Asi son mas adaptables al entorno.

Aarón Fabricio Santa Cruz Valdez

student•

Me hubiera gustado que escriba el código de todo lo que esta explicando para entenderlo mejor.

Sergio Estrella

teacher•

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?

Carlos Mario Mora Restrepo

student•

No me quedo muy claro. Entonces la idea es que cada clase debe separarse para que se enfoque en su propio proceso?

Japheth Calzada López

student•

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

Medios Digitales

student•

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.

Enrique Devars

teacher•

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.

Open/Closed Principle

Comprender los objetivos y pre-requisitos del curso

Todo lo que aprenderás sobre buenas prácticas para escribir código

¿A quién beneficia contar con código bien escrito?

Ejes que hacen a la calidad del código

Aprender a escribir código legible

Código prolijo

Identificadores mnemotécnicos, específicos y precisos

Aprender a escribir código mantenible

Código modular

Código reutilizable

Código organizado

Escribir código libre de vicios

Evitar el hardcoding

Evitar efectos colaterales

Conocer los principios SOLID

Principios SOLID: Single Responsibility Principle

Open/Closed Principle

Liskov Substitution Principle

Interface Segregation Principle

Dependency Inversion Principle

Conocer los conceptos de Patrones de diseño y su aplicación

Patrones de diseño: Singleton

Factory

Command

Comprender las nociones de testing automatizado

Introducción al Testing Automatizado

Armado del entorno de pruebas en PHP

Test Driven Development

Incorporar habilidades para el trabajo en equipo

Pull requests

Documentación

Reforzar lo aprendido

A quién beneficia el código bien escrito

Aplicar lo aprendido: Libro de visitas

Conclusiones