Open/Closed Principle

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:

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

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

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.

Principio abierto/cerrado (OCP): Este principio establece que el código debe ser abierto para la extensión, pero cerrado para la modificación. Esto significa que el código debe poder adaptarse a los cambios sin tener que modificarlo.

Creo que en este caso podemos aplicar el patron strategy

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:

“El 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.