No tienes acceso a esta clase

隆Contin煤a aprendiendo! 脷nete y comienza a potenciar tu carrera

Open/Closed Principle

12/26
Recursos

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

Aportes 36

Preguntas 1

Ordenar por:

Los aportes, preguntas y respuestas son vitales para aprender en comunidad. Reg铆strate o inicia sesi贸n para participar.

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();
    }
}```

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

鈥淟a 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.

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

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

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

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

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

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

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 鈥減ay鈥, 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.

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

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?

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.

Se podria decir que en la clase aplico polimorfismo. o bueno algo parecido

Debi贸 poner el c贸digo final, mal mal mal

Hubiese sido bueno escuchar algo relacionado al polimorfismo, ya que es un concepto fundamental para este principio, as铆 como tambi茅n, de la herencia e implementaci贸n de interfaces.

No me queda muy claro el ejemplo ya que para crear un nuevo tipo de documento, no s贸lo se necesita crear la nueva clase de tipo documento (el nuevo componente requisito) para que esta se adapte por s铆 solo al sistema, tambi茅n se debe modificar el c贸digo para insertar la nueva instancia de la clase dentro del array $docs

De hecho en PHP podemos usar interfaces y creamos la interfaz Document por ejemplo que tenga un metodo process, asi creamos un contrato y garantizamos que los objetos invoice, receipt, memo y cualquiera que herede de la interfaz Document, debera cumplir con este contrato, el buen uso de interfaces es algo que promueve mucho los principios SOLID incluso Jeffrey Way menciona en la serie de SOLID que todos de una u otra forma se relacionan con el concepto de interfaces

Nota: el pricipio de abierto 鈥 Cerrado nos propone una forma de estructurar nuestra clases de modo que podemos adaptar nuestra clases a nuevos requerimientos sin tener que modificar su estructura interna. Este principio es de muy importante en proyectos grandes, ya que podemos en estos proyectos tener clases muy grandes y funciones de la misma manera, solo tenemos que repartir las responsabilidades de las clases que llamadoras con las clases que se ejecutan al se invocadas.

Si en definitiva el c贸digo se hace m谩s legible y m谩s f谩cil de buscar errores!

SOLID: Open/Closed Principle
Establece que una entidad de software debe quedarse abierta para su extension, pero cerrada para su modificacion

es una forma para dise帽ar mejor nuestras clases para que sean mas faciles de adaptar por cambios

  1. Open/Closed Principle
    No eliminar funciones ya escritas y nunca desecharlas, adaptarlas a los nuevos requerimientos, siempre tratando de aplicar el primer principio de que haga una funcion unica

Para complementar, otra explicaci贸n
https://youtu.be/KxeUnivMNik

Ehhh鈥 ser铆a algo as铆.

function vehicleWheels(arrayValues) {
    for (let i = 0; i < arrayValues.length; i++) {
        console.log(arrayValues[i].getWheels());
    }
};

class Vehicle {
    constructor(name) {
        this.name = name
    }
};

class Bike extends Vehicle {
    constructor(name) {
        super(name)
    }
    getWheels() {
        return console.log(`${this.name} has 2 wheels`);
    }
};

class Car extends Vehicle {
    constructor(name) {
        super(name)
    }
    getWheels() {
        return console.log(`${this.name} has 4 wheels`);
    };
};

const arrayVehicle = [
    new Bike('bike'),
    new Car('camioneta'),
    new Car('tractor')
];


console.log(arrayVehicle);
console.log(vehicleWheels(arrayVehicle));

Todo clar铆simo. Gracias

https://architectcoders.com/wp-content/uploads/2019/08/principios-solid-devexperto.pdf

Conclusi贸n:

鈥淓l principio Open/Closed es una herramienta indispensable para protegernos frente a
cambios en m贸dulos o partes de c贸digo en los que esas modificaciones son frecuentes.
Tener c贸digo cerrado a modificaci贸n y abierto a extensi贸n nos da la m谩xima
flexibilidad con el m铆nimo impacto.鈥

Interesante; lo que veo es que se trata de organizar mejor las clases, dale cierta jerarqu铆a para que si se tiene que modificar una clase m谩s alta en la jerarqu铆a entonces solo es necesario modificar las jerarquias m谩s bajas.