NataliaMw
commented
3 years ago Principio abierto/cerrado Repositorio A Este principio establece que una clase debe estar abierta a extensiones, pero cerrada para las modificaciones, argumentando que las clases deberían ser diseñadas para nunca cambiar y cuando los requisitos cambien se debería extender el comportamiento de las clases añadiendo código, no modificando el existente. Basándonos en esa definición, procederemos a proponer una solución que aplique correctamente el principio Abierto/Cerrado:
Repositorio A: 1era violación Una clase padre está cerrada, ya que puede ser usada como base para otras clases. Pero también está abierta, ya que cualquier clase nueva puede heredar de la misma, agregando nuevas características. Cuando se define una clase descendiente, no hay motivo para modificar la original. Es con este concepto base que encontramos la primera violación al principio Open/Closed, donde las clases Médico y Paciente funcionan como usuarios de la aplicación y, en caso de que se llegue a agregar un usuario extra que interactúe con alguno de los otros 2, no sería buena idea que se modifiquen las clases previas. Quedaria la solución así
package TDAs;
public abstract class Usuario {
private String cedula;
private String nombres;
private String apellidos;
private int edad;
private String genero;
public Usuario(String cedula, String nombres, String apellidos, int edad, String genero) {
this.cedula = cedula;
this.nombres = nombres;
this.apellidos = apellidos;
this.edad = edad;
this.genero = genero;
}
public Usuario(String cedula) {
this.cedula = cedula;
}
public String getCedula() {
return cedula;
}
public void setCedula(String cedula) {
this.cedula = cedula;
}
public String getNombres() {
return nombres;
}
public void setNombres(String nombres) {
this.nombres = nombres;
}
public String getApellidos() {
return apellidos;
}
public void setApellidos(String apellidos) {
this.apellidos = apellidos;
}
public int getEdad() {
return edad;
}
public void setEdad(int edad) {
this.edad = edad;
}
public String getGenero() {
return genero;
}
public void setGenero(String genero) {
this.genero = genero;
}
@Override
public String toString() {
return "Usuario [cedula=" + cedula + ", nombres=" + nombres + ", apellidos=" + apellidos + ", edad=" + edad
+ ", genero=" + genero + "]";
}
}Esa sería la clase Usuario. Las clases Medico y Paciente solamente modifican sus atributos, de la siguiente forma: EJEMPLO CLASE PACIENTE:
public class Paciente extends Usuario implements Comparable<Paciente>{
private String sintoma;
public Paciente(String cedula, String nombres, String apellidos, int edad, String genero, String sintoma) {
super(cedula, nombres, apellidos, edad, genero);
this.sintoma=sintoma;
}Y el UML modificado quedaría:
Repositorio A: 2da violación Los métodos en su generalidad deben cerrados para la modificación, pero abiertos para la extensión. Esto quiere decir que cada vez que se quiera agregar una funcionalidad extra en el código no se debe modificar el código ya existente, solo debería añadirse. Por lo tanto, en las clases Formulario Medico y Formulario Paciente, donde existe el uso del método generarArchivo() se viola directamente el principio. Ya que en caso de que se requiera una funcionalidad extra que tenga directamente que ver con los archivos creados, es preferible añadir un método adicional a modificar el existente. Y este se repite en algunas clases. Por lo tanto, nuestra solución propuesta es crear una interfaz que contenga al método generarArchivo() y cualquier futuro método relacionado, que sea implementada por las clases respectivas: Formulario Medico y Formulario Paciente. De esta forma, se crea la Interfaz IArchivos y se implementa en los debidos formularios:
package interfaz;
public interface IArchivos {
public void generarArchivo(String datos);
}Y las clases:
public class FormularioPaciente implements IArchivos
El UML modificado quedaría así:
Repositorio A: 3era violación Los formularios del proyecto tienen varias funcionalidades en común, entre ellas está la función de regresar. Esto de por sí se trata de una violación al principio, ya que está vulnerable a la modificación y en caso de una extensión se tendrá que modificar en todos los formularios. Si se llegara a implementar una funcionalidad extra para los formularios, como un botón que vaya adelante o uno que cambie el panel de color, se tendría que modificar el código, cosa que queremos evitar. Por lo tanto, la solución propuesta es desarrollar una interfaz de la que hereden los formularios que implementen estos métodos, Formulario Médico, Formulario Paciente, Formulario Atención y Formulario Puestos. Una vez modificado quedaría de la siguiente manera:
package interfaz;
public interface IFormulario {
public void volverMenu();
}Recordando implementar en cada formulario.
Viendo eso, el diagrama UML quedaría así:
Violaciones
Existen diferentes tipos de violaciones del principio SOLID que hemos encontrado en este código. Por lo cual se ha decidido crear este issue para proseguir a reportar las respectivas violaciones.