vikaskaushik17/java-programs

Java-Programs

java-programs's Issues

Reporte SOLID - Curso Diseño de Software

REPORTE SOLID

Tenga un buen día, somos estudiantes del curso de diseño de software. En nuestra materia nos han solicitado revisar repositorios en github y para motivos de nuestro aprendizaje hemos analizado los principios SOLID dentro de su código buscando la manera de mejorarlo, proponiendo posibles soluciones a la escabilidad del mismo y cumpliendo con un diseño de software óptimo.

Principios mencionados dentro del reporte

• SRP Single Responsibility Principle
• OCP Open Closed Principle
• LSP Liskov's Substitution Principle
• ISP Interface Segregation Principle
• DIP Dependency Inversion Principle

OPEN-CLOSED PRINCIPLE

Con respecto a la primera violación de los principios SOLID encontrada en este repositorio, el Open-Closed Principle, se debería crear una interfaz para representar a las figuras geométricas necesarias que tenga un método para calcular su área. Esto se debe a que en este caso, el main está usando condicionales en el caso de que sus medidas cambien. Sin embargo, se debería incluir una clase para cada figura con su debido método para calcular el área. Asimismo, se debería incluir una clase para calcular el área, pues de esta forma, se podrían agregar más figuras sin necesidad de cambiar su método interno de hallar el área. De este modo, se encuentra abierto para su extensión (agregar figuras) pero cerrado para su modificación.

Liskov Substitution Principle: Violación 1

La solución más sencilla en este caso es tratar de hacer una clase “Vehicle” general, la cual tiene las propiedades y métodos generales de un vehículo para funcionar, pero, antes de crear clases hijas de Vehículo, nos ponemos a pensar qué propiedades tienen algunos vehículos y otros no, por lo que , tomando el ejemplo del método start(), podemos crear dos subclases , una que extienda directamente de “Vehicle” que puede ser “WithOffVehicle”, la cual no necesariamente necesita encender, pero tiene funcionalidades similares a otros vehículos como: acelerar o frenar; y otra subclase “WithOnVehicle” la cual es una clase que además de extender de Vehicle, posee un método start() que permite encender un motor, así, aquellos vehículos que necesitan del motor extienden de “WithOnVehicle” y aquellos que no de “WithOffVehicle”.

Así, los vehículos pueden extender sus respectivas clases padre con los métodos adecuados:

Liskov Substitution Principle: Violación 2

Con el objetivo de solucionar esta violación del principio LSP, se crea una clase únicamente para representar a los pájaros y luego otra clase llamada “BlyingBirds”, esto se realiza para permitir que las clases hijas no lancen una excepción en el caso de que sean aves que no puedan volar. De este modo, se arregla el problema de que la clase Penguin lance una excepción al utilizar el método fly().

Interface Segregation Principle: Violación 1

Observando el uso de la interfaz ITelophone, aparentemente está bien, pero el autor paso por alto la implementación innecesaria de un método, por lo que separaremos con una interfaz diferente para evitar ISP, proponiendo una interfaz que sea para teléfonos sin botón y con botón. Incluso, no se mencionó en un principio porque ya estaba establecidos todos los tipos de violación SRP, pero vemos que esta sobrecargado de métodos con diferentes tipos de acciones, por lo que todo eso será divido. Tambien existe una redundancia de métodos dial() y callPhone(), hacen lo mismo.

Finalmente, también se dividió a la persona que llama y el que recibe o no la llamada, ya que esos métodos no tienen nada que ver con el funcionamiento de algún tipo de teléfono.

Interface Segregation Principle: Violación 2

El problema en la clase Penguin vemos que extiende de la clase Bird que tiene el método fly(), la clase Bird implementa la interfaz CanFly, mostrando un mal uso de interfaz, ya que en el caso del Pinguino se desperdicia el uso de esa interfaz, por lo que, para una posible solución se establece que la clase Bird no implemente la interfaz CanFly, directamente hacemos que el tipo de pájaro implemente la interfaz de IFly si vuela y si no, simplemente no implemente nada.

Dependency Inverse Principle

En este caso, debido a que se toma en cuenta la consideración de que existen atributos que no serían utilizados en la clase vehículo, se debe depender de abstracciones más no de cosas concretas. Por ende, se incluiría una interfaz que represente a las llantas pues este principio indica que lo más apropiado es depender de interfaces.