En términos generales, todos los lenguajes de programación se pueden clasificar en dos paradigmas:  Programación     : sigue una secuencia de instrucciones que se ejecutan línea por línea. imperativa/ orientada a objetos      funcional: no secuencial, pero se preocupa más por el propósito del programa. Todo el programa es como una función que además tiene subfunciones, cada una de las cuales realiza una determinada tarea. Programación declarativa /  Como desarrollador junior, me doy cuenta de la manera difícil (léase: estaba mirando nerviosamente miles de líneas de código) que no se trata solo de escribir código funcional, sino también de código semánticamente fácil y flexible.  Si bien existen múltiples mejores prácticas para escribir código limpio en ambos paradigmas, voy a hablar sobre los principios de diseño SOLID relacionados con el paradigma de programación orientado a objetos.  ¿Qué es SÓLIDO?  S — Responsabilidad Única  O—Principio abierto-cerrado  L — Principio de sustitución de Liskov  I — Segregación de la interfaz  D — Inversión de dependencia  La principal razón de cualquier dificultad para comprender estos conceptos no es que su profundidad técnica sea insondable, sino que son pautas abstractas que se generalizan para escribir código limpio en la programación orientada a objetos. Veamos algunos diagramas de clase de alto nivel para llevar estos conceptos a casa.  Estos no son diagramas de clase precisos, pero son planos básicos para ayudar a comprender qué métodos están presentes en una clase.  Consideremos un ejemplo de un café a lo largo del artículo.  Principio de responsabilidad  única  Una clase debe tener una sola razón para cambiar  Considere esta clase que maneja los pedidos en línea recibidos por el café.     Esta única clase es responsable de múltiples funciones. ¿Qué pasa si tienes que añadir otros métodos de pago? ¿Qué sucede si tiene varias formas de enviar la confirmación? Cambiar la lógica de pago en la clase que se encarga de procesar los pedidos no tiene muy buen diseño. Conduce a un código altamente no flexible. ¿Qué tiene de malo?  Una mejor manera sería separar estas funcionalidades específicas en clases concretas y llamar a una instancia de ellas, como se muestra en la siguiente ilustración.    Principio abierto-cerrado  Las entidades deben estar abiertas a la extensión pero cerradas a la modificación.  En la cafetería, debe elegir los condimentos para su café de una lista de opciones y hay una clase que se encarga de esto.   El café decidió agregar un nuevo condimento, mantequilla. Observe cómo cambiará el precio según el condimento seleccionado y la lógica para el cálculo del precio está en la clase Café. No solo tenemos que agregar una nueva clase de condimento cada vez que crea posibles cambios de código en la clase principal, sino también manejar la lógica de manera diferente cada vez.  Una mejor manera sería crear una interfaz de condimentos que a su vez pueda tener clases secundarias que anulen sus métodos. Y la clase principal puede simplemente usar la interfaz de condimentos para pasar los parámetros y obtener la cantidad y el precio de cada pedido.    Esto tiene dos ventajas:  1. Puede cambiar dinámicamente su pedido para tener diferentes o incluso múltiples condimentos (café con moka y chocolate suena celestial).  2. La clase Condimentos va a tener una relación tiene con la clase Café, en lugar de es-a. Por lo tanto, su café puede tener moca/mantequilla/leche en lugar de que su café sea un tipo de café moca/mantequilla/leche.  Principio de sustitución de Liskov  Cada subclase o clase derivada debe ser sustituible por su clase base o padre.  Esto significa que la subclase debería poder reemplazar directamente a la clase principal; debe tener la misma funcionalidad. Me resultó difícil entender esto porque suena como una fórmula matemática compleja. Pero intentaré dejarlo claro en este artículo.  Piense en el personal de la cafetería. Hay baristas, gerentes y servidores. Todos ellos tienen una funcionalidad similar.  Por lo tanto, podemos crear una clase Staff base con nombre, posición, getName, getPostion, takeOrder(), serve().  Cada una de las clases concretas, Waiter, Barista y Manager puede derivar de esto y anular los mismos métodos para implementarlos según sea necesario para el puesto.   En este ejemplo, se usa   para garantizar que cualquier clase derivada de pentagrama se pueda usar indistintamente con la clase base de pentagrama sin afectar la corrección del código. el principio de sustitución de Liskov (LSP)  Por ejemplo, la clase Waiter amplía la clase Staff y anula los métodos takeOrder y serveOrder para incluir funciones adicionales específicas del rol de un camarero. Sin embargo, lo que es más importante, a pesar de las diferencias en la funcionalidad, cualquier código que espere un objeto de la clase Staff también puede funcionar correctamente con un objeto de la clase Waiter.  Veamos un ejemplo para entender esto       staff.takeOrder(); staff.serveOrder(); } }                            } } public   class   Cafe   {      public   void   serveCustomer (Staff staff)   { public   class   Main   {      public   static   void   main (String[] args)   {  Cafe cafe = new  Cafe();  Staff staff1 = new  Staff( "John" , "Staff" );  Waiter waiter1 = new  Waiter( "Jane" );  restaurant.serveCustomer(staff1); // Works correctly with Staff object 
  restaurant.serveCustomer(waiter1); // Works correctly with Waiter object 
  Aquí el método serveCustomer() en la clase Cafe, toma un objeto Staff como parámetro. El método serveCustomer() llama a los métodos takeOrder() y serveOrder() del objeto Staff para atender al cliente.  En la clase Main, creamos un objeto Staff y un objeto Waiter. Luego llamamos dos veces al método serveCustomer() de la clase Café: una vez con el objeto Staff y otra vez con el objeto Waiter.  Debido a que la clase Waiter se deriva de la clase Staff, cualquier código que espere un objeto de la clase Staff también puede funcionar correctamente con un objeto de la clase Waiter. En este caso, el método serveCustomer() de la clase Cafe funciona correctamente tanto con el objeto Staff como con el objeto Waiter, aunque el objeto Waiter tiene una funcionalidad adicional específica para el rol de un camarero.   Segregación de interfaz  Las clases no deberían verse obligadas a depender de métodos que no utilizan.  Entonces, existe esta máquina expendedora muy versátil en la cafetería que puede dispensar café, té, refrigerios y refrescos.   ¿Qué tiene de malo? Nada técnicamente. Si tiene que implementar la interfaz para cualquiera de las funciones, como dispensar café, también debe implementar otros métodos destinados a té, refrescos y refrigerios. Esto es innecesario y estas funciones no están relacionadas entre sí. Cada una de esas funciones tiene muy poca   entre ellas. cohesión    Es un factor que determina cuán fuertemente se relacionan entre sí los métodos en una interfaz. ¿Qué es la cohesión?  Y en el caso de la máquina expendedora, los métodos apenas son interdependientes. Podemos segregar los métodos ya que tienen muy poca cohesión.   Ahora, cualquier interfaz que esté destinada a implementar una cosa, solo debe implementar takeMoney(), que es común para todas las funciones. Esto separa las funciones no relacionadas en una interfaz, evitando así la implementación forzada de funciones no relacionadas en una interfaz.  Inversión de dependencia  Los módulos de alto nivel no deben depender de los módulos de bajo nivel. Los detalles deben depender de abstracciones.   Considere el acondicionador de aire (refrigerador) en el café. Y si eres como yo, siempre hace mucho frío allí. Veamos el control remoto y las clases de CA.   Aquí, remoteControl es el módulo de alto nivel que depende de AC, el componente de bajo nivel. Si obtengo un voto, también me gustaría un calentador :P Entonces, para tener una regulación de temperatura genérica, en lugar de un enfriador, separemos el control remoto y el de temperatura. Pero la clase remoteControl está estrechamente relacionada con AC, que es una implementación concreta. Para desacoplar la dependencia, podemos crear una interfaz que tenga funciones de aumentar la temperatura () y disminuir la temperatura () dentro de un rango de, digamos, 45-65 F.   pensamientos finales  Como puede ver, tanto los módulos de alto nivel como los de bajo nivel dependen de una interfaz que abstrae la funcionalidad de aumentar o disminuir la temperatura.  La clase concreta, AC, implementa los métodos con el rango de temperatura aplicable.  Ahora probablemente pueda obtener el calentador que quiero implementando diferentes rangos de temperatura en una clase concreta diferente llamada calentador.  El módulo de alto nivel, remoteControl, solo tiene que preocuparse por llamar al método correcto durante el tiempo de ejecución.

The code in this story is for educational purposes. The readers are solely responsible for whatever they build with it.

Read My Stories

Este audio es producido en el idioma original de la historia!

Cómo mantener su código SÓLIDO

About Author

COMENTARIOS

ETIQUETAS

ESTE ARTÍCULO FUE PRESENTADO EN

Related Stories

¿Quieres ganar un concurso de redacción de HackerNoon? Esto es lo que recomiendan los ganadores del concurso #crypto-api

Crecimiento de las criptomonedas: creación de perfiles de usuarios eficaces

Valhalla de Floki se une como patrocinador asociado de la gira de la India por Sri Lanka

Liberando el poder de la IA. Una revisión sistemática de técnicas de vanguardia: resumen e introducción

¿Quieres ganar un concurso de redacción de HackerNoon? Esto es lo que recomiendan los ganadores del concurso #crypto-api

Crecimiento de las criptomonedas: creación de perfiles de usuarios eficaces

Valhalla de Floki se une como patrocinador asociado de la gira de la India por Sri Lanka

Liberando el poder de la IA. Una revisión sistemática de técnicas de vanguardia: resumen e introducción

Light-Mode

Classic

Newspaper

Dark-Mode

Neon Noir

Minty

HN StartUps