Tamaño reducido (responsabilidad única)
Contenido del curso
Nombre y uso de las variables
Ámbito de las variables
Funciones
Clases
Optimizaciones
Cierre
Tamaño reducido (responsabilidad única)
Tamaño reducido (responsabilidad única)
Contenido del curso
Gerardo Ferreyra
Carina Payleman
Juan Rossano
LEONARD CUENCA
Gerardo Ferreyra
gemma clavero del moral
Johan Sebastian
S: El principio de responsabilidad única:
O: El principio abierto-cerrado:
L: El principio de sustitución de Liskov:
I: El principio de segregación de interfaces:
D: El principio de inversión de dependencia:
Principio de responsabilidad única:
1 clase = 1 funcionalidad
Para mi es este el concepto que mas tomo con pinzas. La orientacion a objetos nacio como un paradigma de programacion cuya idea madre era que las aplicaciones se diseñaran e implementaran como una respresentacion digital del sistema real entendiendo que la aplicacion era un reflejo de un ecosistema real. De esta forma los objetos del sistema eran una copia de un objeto del sistema real. Era comun que se represente la idea con un sistema de clases que representara los animales del mundo real donde una clase base era la animal y de ahi se especializara para incorporarle funciones acorde al tipo de animal como aves, mamiferos, peces, etc, y asi sucesivamente. Pero lo importante era que esos objetos pudieran realizar las acciones que reflejen lo que hacen los objetos en el mundo real. Pongamos como ejemplo la recepcionista de un centro de salud. Puede dar un turno, para esto validar que la persona esta registrada en el sistema y en caso de que no puede ingresarla o derivarla a otro sector, pero esa misma recepcionista tambien recepcionar a un paciente que ya tenia turno y tambien entregar los resultados a otro que ya fue atendido. En el mundo real ¿los objetos tienen solo una responsabilidad? En el paradigma orientado a objetos era primordial no repetir el error mas comun de la programacion funcional que era tomar decisiones del diseño por cuestiones de programacion ya que era normal empezar a codificar y diseñar en el proceso. En el nuevo paradirma primero se diseñaba y si al codificar se encontraba alguna complicacion a la hora de implementar un caso de uso se debia volver al diseño pero no se podia cambiar ninguna interface de la clase. El diseño debia estar bien hecho reflejando todo el curso de mensajes para llevar a cabo un caso de uso lo que permitia que dos programadores hicieran clases distintas en paralelo porque cada uno debia garantizar la implementacion de la interfaz. Hoy en dia estan ganado terreno otras ideas pero me parece que conceptualmente se esta rompiendo una de las bases del paradigma y es que las clases son resultado del diseño y no de la programación y con este principio de buenas prácticas de programación se esta limitando al diseño que debe representar al sistema real. Una cosa es que la clase deba estar bien diseñada, no ser solo un repositorio de funciones o que haya clases que no representen el mundo real. Por ejemplo hay clases que se usan para implementar un servicio, componente o como quiera llamarlo cada equipo. En mi empresa hay un componente que es el que calcula impuestos y ese componente es una clase. De esa forma se encapsulan los calculos de impuestos y ahi si, por ser una clase interna que no es una representacion del mundo real entiendo la aplicacion del principio. Pero siempre se nombran las clases como para aplicar el principio a todas. Y para mi es muy limitante tomarlo como una norma. Puede ser que si tiene muchas responsabilidad (que segun esta norma ya son 2) revisar su diseño para confirmar esos detalles: si es una clase de sistema o es una clase que representa un objeto del mundo real y la logica de esas responsabilidades. Si se hace una clase para la seguridad del sistema que verifica que el usuario existe, luego lo autentica validando la clave y luego autoriza sus acciones en base a su rol considerando que esa clase funciona con una sola tabla que contiene usuario, contraseña y rol ¿se considera 3 responsabilidad y se debe implementar en 3 clases distintas? En el ejemplo de esta clase pareceria que cada clase deberia tener solo un metodo para corresponder a este principio. Uno de los ejemplos que se usan para enseñar orientacion a objetos es, por ejemplo, un auto. La clase debe tener los metodos encenderMotor, apagarMotor, acelerar, frenar, etc. Aunque heredemos de una clase vehiculo cualquier clase de este tipo debe minimamente tener acelerar y frenar. Por eso creo que debe haber un equilibrio en el diseño entre las propiedades y funciones de una clase real y el principio de responsabilidad unica.
Clase 18: Tamaño reducido (responsabilidad única)
S : The single-responsibility principle: "There should never be more than one reason for a class to change. In other words, every class should have only one responsibility." O : The open–closed principle: "Software entities ... should be open for extension, but closed for modification." L : The Liskov substitution principle: "Functions that use pointers or references to base classes must be able to use objects of derived classes without knowing it. See also design by contract." I : The interface segregation principle: "Many client-specific interfaces are better than one general-purpose interface." D : The dependency inversion principle: "Depend upon abstractions, [not] concretions."
Código de la clase
// Sín princiopio de responsabilidad única class UserSetting { constructor(user, settings) { this.user = user; this.settings = settings; } changeSetting(settings) { if (this.verifyCredencials()) { } } verifyCredencials() { } } // Con princiopio de responsabilidad única class UserAuth { constructor(user) { this.user = user; } verifyCredencials() { return true; } } class UserSetting extends UserAuth { constructor(user, settings) { super(user) this.settings = settings; } changeSetting(settings) { if (this.verifyCredencials()) { console.log(`Puede modificar su configuración`); } else { console.log(`No tiene acceso.`); } } } const newAccess = new UserSetting('Alex', 'Dark Mode'); newAccess.changeSetting();
Por si les sirve, les dejo el ejemplo de la profe a mi estilo: Siento que la prueba es algo mas diciente.
// CON Responsabilidad unica: // que cada funcion cumpla con un solo objetivo class UserAuth { constructor(user = "") { this.user = user; } verifyCredentials() { if (this.user){ return true; } } } class UserSettings extends UserAuth { constructor(user, settings = "") { super(user); this.settings = settings; } changeSettings(settings) { if (this.verifyCredentials()) { console.log(this.user, ": Puede modificar su configuración a ",this.settings); }else{ console.log(this.user,": No tiene acceso a ", this.settings); } } } const solicitudAccesoInvalida = new UserSettings(null,'Dark Mode'); solicitudAccesoInvalida.changeSettings() //> null : No tiene acceso a Dark Mode const solicitudAccesoValida = new UserSettings('Alex','Dark Mode'); solicitudAccesoValida.changeSettings() //> Alex : Puede modificar su configuración a Dark Mode
class UserAuth { constructor(user) { this.user = user; } verifyCredentials() { const name = 'Johan'; if (this.user === name) { return true } else { return false; } } } class UserSettings extends UserAuth { constructor(user, settings) { super(user); this.settings = settings; } changedSettings(settings) { if (this.verifyCredentials()) { console.log(`Puede modificar su configuración: ${this.settings}`); } else { console.log(`Credenciales incorrectas para confgurar: ${this.settings}`); } } } const newAccess = new UserSettings('Johan', 'Dark Mode'); newAccess.changedSettings();