[C# Psuedo-código] Actividad para Diseño detallado de Software

actividad.cs

using System;
using System.Collections.Generic;
using System.Linq;
using System.Threading.Tasks;

namespace Namespace {
  class Bebida {

  }

  class Fanta: Bebida {

  }

  class Coca: Bebida {

  }

  class Sprite: Bebida {

  }

  class IncaCola: Bebida {

  }

  class DispensadorDeBebida {
    public Bebida Dispensar(string tipo) {
      switch (tipo) {
        case 'Fanta': {
          return new Fanta();
        }
        case 'Coca': {
          return new Coca();
        }
        case 'Sprite': {
          return new Sprite();
        }
        case 'IncaCola': {
          return new IncaCola()
        }
        default: {
          return null;
        }
      }
    }
  }
}

Solución

• Problemas presentes en el código: presenta alto acoplamiento puesto que las clases están hardcoded en el método de la clase DispensadorBebida, lo que impide agregar nuevos tipos de bebidas al dispensador. Además presenta baja cohesión porque las clases que heredan de Bebida no tienen comportamiento alguno, lo que implica que no fue correcto el nivel de abstracción.
  • Por otro lado, cambiando el constructor de cualquiera de las bebidas hace que deje de ser válido el método Dispensar, por ejemplo al agregarle argumentos adicionales, lo que arrojaría un error.
• El método Dispensar rompe el principio Open-closed al usar las clases de manera estática a través del switch, específicando explícitamente cuales son las bebidas a dispensar, sin considerar que se pudieran agregar más tipos de bebidas, o restringir la cantidad de ellas. Además, al hacer uso de sus constructores sin argumentos puede llevar a que un cambio del constructor de la clase usada genere errores.
• Para solucionar el problema, se puede cambiar el método Dispensar, quitando el switchy en vez de recibir un stringpara identificar la bebida, simplemente usar Generics para recibir el tipo de la bebida a usar (Fanta, IncaCola, etc), y luego usar el constructor de la clase genéricamente. Para esto, también las bebidas deben implementar una interfaz IBebida que permita que todas las bebidas deban implementar cierto método instanciador.
• Open-closed arregla el problema porque así se puede extender la funcionalidad de la clase sin tener que modificarla. Luego, haciendo lo mencionado anteriormente no será necesario modificar DispensadorBebida para agregar nuevas bebidas, o bien eliminar bebidas del dispensador. Esto tampoco genera problemas puesto que reduce el acoplamiento y mantiene la cohesión anterior del modelo.