Tamaño reducido (responsabilidad única)

Clase 18 de 24 • Curso de Clean Code y Buenas Prácticas con JavaScript

Gerardo Ferreyra

student•

S: El principio de responsabilidad única:
- Nunca debe haber más de una razón para cambiar una clase. En otras palabras, cada clase debe tener una sola responsabilidad.
O: El principio abierto-cerrado:
- Las entidades de software, deben estar abiertas a la extensión, pero cerradas a la modificación.
L: El principio de sustitución de Liskov:
- Las funciones que usan punteros o referencias a clases base deben poder usar objetos de clases derivadas sin saberlo.
I: El principio de segregación de interfaces:
- Muchas interfaces específicas del cliente son mejores que una interfaz de propósito general.
D: El principio de inversión de dependencia:
- Depende de abstracciones, no de concreciones.

Carina Payleman

student•

Principio de responsabilidad única:

1 clase = 1 funcionalidad

Juan Rossano

student•

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.

LEONARD CUENCA

student•

Clase 18: Tamaño reducido (responsabilidad única)

Este concepto viene del manifiesto SOLID que son las bases para la Programación POO.

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."

Gerardo Ferreyra

student•

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();

gemma clavero del moral

student•

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

Johan Sebastian

student•

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();

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."

// 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();

// 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();

Tamaño reducido (responsabilidad única)

Introducción al Clean Code

Deuda técnica y refactorización de código

Reglas del diseño simple

Qué es Clean Code

Nombre y uso de las variables

Uso correcto de var, let y const

Reglas para la nomenclatura

Cómo nombrar según el tipo de dato

Nombres de Variables y Funciones Correctos en JavaScript

Ámbito de las variables

Ámbito global

Ámbito local o de función

Ámbito de bloque

Ámbito estático

Hoisting

Funciones

Declaración y expresión de funciones

Parámetros y argumentos

Funciones de flecha y el this

Clases

POO con ES6 (constructores, métodos y herencia)

Herencia en JavaScript

Tamaño reducido (responsabilidad única)

Organización

Optimizaciones

Cuándo usar comentarios

Formato coherente (codear en equipos)

Principio DRY

Tipos de Algoritmos y Complejidad Big O en JavaScript

Cierre

Sigue aprendiendo JavaScript