a principios de la década 2000 • Haciendo nuestro código SOLID conseguimos un código flexible y escalable • Representa los 5 principios básicos de la programación orientada a objetos ◦ Single responsibility ◦ Open-closed ◦ Liskov substitution ◦ Interface segregation ◦ Dependency inversion
responsabilidad es igual a un único motivo para cambiar • Si una clase tiene múltiples responsabilidades hay riesgo de modificar una responsabilidad pero alterar otra al estar ambas en el mismo sitio. • Hay que evitar clases muy grandes que hacen muchas cosas • Este principio aplica también a los métodos y funciones • Si aplicamos este principio estamos evitando duplicar código
a cumplir este principio • Bertrand Meyer fue el primero que habló sobre este principio en 1988 en el libro Object-Oriented Software Construction. • Las entidades de software deben estar abiertas para su extensión, pero cerradas para su modificación. • Deberían poder extender o modificar su comportamiento sin modificarse • Abrir una clase para editarla conlleva riesgos de afectar a más cosas
(string.Equals(args[0], UPDATE_CATALOGPRODUCT_TO_CA)) { //Synchronizing from catalog to CA ... } if (string.Equals(args[0], UPDATE_CA_TO_INVENTORYPRODUCT)) { //Synchronizing from CA to Catalog ... } if (string.Equals(args[0], ASSIGN_ALLLABELS_CA)) { //Assigning labels to CA ... } } ¿Añadir más casos de sync? Aplicaciones de consola
no pueden modificar las capacidades de su clase base. ◦ Dos clases que heredan de otra tienen que tener las mismas capacidades. ◦ Dos clases que implementan el mismo interface tienen que tener las mismas capacidades. • Acuñado por Barbara Liskov en el año 1987 durante una conferencia sobre Jerarquía y Abstracción de datos. • Clases compartiendo abstracción deben poder ser intercambiables.
caso en dTLP) public class Cuadrado : Rectangulo { public override int Ancho { get { return base.Ancho;} set { base.Ancho = value; base.Alto = value; } } public override int Alto { get { return base.Alto; } set { base.Ancho = value; base.Alto = value; } } } public class Rectangulo { private int ancho; private int alto; public virtual int Ancho { get { return ancho; } set { ancho = value; } } public virtual int Alto { get { return alto; } set { alto = value; } } } [TestMethod] public void AreaRectangulo() { Rectangulo r = new Rectangulo { Ancho = 5, Alto = 2 }; // el test pasa Assert.AreEqual(r.Ancho * r.Alto, 10); // true } [TestMethod] public void AreaRectangulo() { Rectangulo r = new Cuadrado{ Ancho = 5, Alto = 2 }; // Fallará, pues Cuadrado establece // a 2 el ancho y el alto Assert.AreEqual(r.Ancho * r.Alto, 10); // false }
(int pageNumber, int pageSize, string prefixSKU); } Ej 2: Interface public class MultichannelCASellerService : IMultichannelCASellerService { public ICAResult SyncProductsComplete (IEnumerable<ProductInfoCA> data) { //code } public List<ProductInfoCA> GetFilteredInventoryItemList (string prefixSKU) { //code } } public class MultichannelCASellerFTPService : IMultichannelCASellerService { public ICAResult SyncProductsComplete (IEnumerable<ProductInfoCA> data) { //code } public List<ProductInfoCA> GetFilteredInventoryItemList (string prefixSKU) { throw new NotImplementedException(); } } El uso de NotSupportException o NotImplementedException viola este principio
en otras más pequeñas y más específicas para que los clientes sólo tendrán que saber sobre el métodos que son de interés para ello • Fue propuesto originalmente por Robert C. Martin (Uncle Bob). • Ayuda a resolver la violación del principio de sustitución de Liskov por interface. • Es un ejemplo de cómo los principios SOLID interactúan y mejoran entre sí. • Este principio establece que ningún cliente debe ser forzado a depender de métodos que no utiliza. • Las interfaces pesadas no permiten escalar bien.
• Los módulos de alto nivel no deberían depender de los de bajo nivel, ambos deberían depender de abstracciones. • Las abstracciones no deben depender de los detalles, los detalles deben depender de las abstracciones. • La ventana de aplicar este principio de nuevo poder escalar mejor modificando el menor código posible. • Importante, la abstracción la marca el cliente • Este principio ayuda a poder realizar test unitarios • Voy a poder probar una clase y simular sus simular sus dependencias