SOLID

Principios S.O.L.I.D

Una de las palabras más oídas en la CODEMOTION 2015 fue “S.O.L.I.D” y no es para menos, ya que con el se definen unas buenas prácticas. En un principio pensé que era algo novedoso, algo que habían creado para el desarrollo mobile, pero ni mucho menos es así.
Este conjunto de principios se remonta a principios de la década de los 2000, cuando Robert C. Martin, también conocido como “Uncle Bob”, creó esta regla mnemotécnica de principios básicos para el desarrollo orientado a objetos. La aplicación de estos principios hace que el código creado sea mucho más mantenible y expandible, siendo menor la creación de código spaghetti, y las refactorizaciones sobre el mismo.

Cada una de las letras corresponde con un principio diferente:


Single Responsibility Principle

A class should have one, and only one, reason to change.
(Una clase debería tener una y solo una, razón para cambiar)

Cada clase es responsable de solo una tarea, por lo que si es modificada, solo debería ser porque esa tarea ha sido cambiada. Si en algún momento nuestra clase tiene más de una responsabilidad, éstas deben desacoplarse en distintas clases.


Open Closed Principle

You should be able to extend a classes behavior, without modifying it.
(Deberías ser capaz de extender el comportamiento de una clase sin modificarlo)

Una clase debe estar abierta a extensión pero no a su modificación. Esto se consigue mediante herencia. Teniendo una clase padre que tiene un comportamiento específico, puedes extender esta clase a una clase hija, pudiendo esta tener más funcionalidad, pero manteniendo la anterior. Con esto consigues que la clase padre esté cerrada a modificación pero abierta a la extensión.


Liskov Substitution Principle

Derived classes must be substitutable for their base classes.
(Las clases derivadas deben ser sustituibles por sus clases base)

Quizás sea el punto en el que más dudas tiene la gente. En este principio se comenta una clase que extiende de otra puede usarse como sustituta de su padre sin que su comportamiento se modifique.Pongamos un ejemplo para que quede más claro. Tenemos una clase “Telefono” que contiene un método que es “realizarLlamada()”. Si tuviéramos una clase “SmartPhone” que extiende de “Telefono”, podríamos sustituir todas las referencias a “Telefono” por referencias a “SmartPhone”


Interface Segregation Principle

Make fine grained interfaces that are client specific.
(Haz interfaces pequeñas que sean para un cliente específico)

Este principio nos indica que se usen interfaces para mostrar a los clientes que las usen sólo los métodos que necesiten, así evitaremos que tengan acceso a ciertas partes que no deben ver.
En el desarrollo android, en especial en MVP, tenemos un caso clarísimo. Normalmente las actividades o fragmentos implementan la parte de las vistas, pasándole a los presentadores nuestra implementación. El presentador solo tendrá acceso a los métodos de la interfaz, ocultándole así los métodos del fragment/actividad (onCreate, onResume, etc..) que no necesitan.


Dependency Inversion Principle

Depend on abstractions, not on concretions.
(Haz que dependas de abstracciones y no de concreciones)

Por último, el principio de inversión de dependencias nos indica que se debe depender de abstracciones y no de concreciones de clases. Si tenemos una clase que implementa una interfaz deberíamos poder ser capaces de usar la interfaz como ejecutora de los métodos sin que eso suponga un problema.
La inyección de dependencias en android mediante Dagger / Dagger2 , nos ayuda a cumplir este principio.

keep_calm_solid

Para finalizar, comentar que estos principios no son obligatorios ni la única verdad existente; Son buenas prácticas, que si las sigues, tu código, tu trabajo y sobre todo TUS COMPAÑEROS te lo agradecerán.

Puedes ver AQUI el artículo de Uncle Bob en el que se exponen estos principios.


Deja un comentario

3 × 2 =