CLEAN CODE

BM Software

Contenido
GIT.............................................................................................................................3
ENTORNO DE DESARROLLO.................................................................................3
TEST UNITARIOS.....................................................................................................4
CLEAN CODE............................................................................................................5
Comentarios...........................................................................................................5
Nombres (Clases, variables y métodos)................................................................6
Métodos..................................................................................................................7
Clases....................................................................................................................8
Arquitectura............................................................................................................9
REFACTORIZACIÓN..............................................................................................10
Code Smells generales........................................................................................10
Código Smells específicos...................................................................................11
Tipos de refactorizaciones...................................................................................15
PATRONES DE SOFTWARE..................................................................................19
Creacionales........................................................................................................20
Singleton...........................................................................................................20
Factory..............................................................................................................21
Abstract Factory...............................................................................................22
Builder...............................................................................................................22
Prototype..........................................................................................................23
Estructurales........................................................................................................23
Adapter.............................................................................................................23
Brigde...............................................................................................................25
Composite:........................................................................................................25
 Decorator..........................................................................................................26
Facade/Fachada...............................................................................................27
Flyweight...........................................................................................................28
Proxy.................................................................................................................28
Comportamiento...................................................................................................29
Chain of Responsability / Cadena de resposabilidades...................................29
Command / Comando......................................................................................30
Interpreter.........................................................................................................30
Iterator..............................................................................................................31
Mediator............................................................................................................32
Memento...........................................................................................................32
Observer / Observador.....................................................................................33
State.................................................................................................................34
Strategy............................................................................................................35
Template Method..............................................................................................35
Visitor................................................................................................................36
PRINCIPIOS SOLID................................................................................................37
SRP: Single Resposability Principle.................................................................37
OCP: Open/Closed Principle............................................................................37
LPS: Liskov Subtitution Principle......................................................................38
ISP: Interface Segregation Principle................................................................38
DIP: Dependency Inversion Principle...............................................................38
PRINCIPIOS LEAN (PRINCIPIO DE INVERSIÓN DE DEPENDENCIA)..............39
Principios de LEAN...........................................................................................39
 GIT

Es un sistema de control de versiones descentralizado es decir que se puede usar

de manera local sin necesidad de tener internet
Los comandos más usados en este sistema son:
USO COMANDO EN GIT
Crear un repositorio git init nombre_proyecto
Añadir git add objeto_añadir
Confirmacion git commit –a –m “mensaje para el
commit”
Estado de las versiones en una rama git status
Ver todos los commits git log
Guardar cambios en un repositorio git push
remoto

Los IDEs mas usados e importantes ya vienen con cierta configuracion para
manejar git o en algunos casos es necesario installar un plugin para activarlos

ENTORNO DE DESARROLLO

Se pueden dividir en 3 tipos: ligeros, IDEs y remotos

Ligeros: No ocupan mucho y se pueden complementar a través de plugins
a. Sublime
b. Atom
c. Visual Studio Code
d. iBrackets
e. Notepad++
IDEs: Son más potentes además de venir con los mismos usos de uno ligero y se
pueden completar mas con plugins
a. Eclipse // Versión gratuita
b. NetBeans // Version gratuita
c. IntelijIDEA – Jetbrains
d. Visual Studio // Version gratuita
Remotos: Son IDEs en la nube, pero por ende se necesita internet además de no
tener el sistema de refactor tan bien implementado en comparación a un IDE de
escritorio
Cloud9: php, rails, nodejs, Django, C++
Codenvy. Eclipse che online
Codenavywhere, infinidad de lenguajes

TEST UNITARIOS

Es una técnica que permite comprobar el correcto funcionamiento de una unidad

de código, es decir un programa verifica que otro programa funcione de manera
correcta o esperada, estos pueden contar con las características como:
a. Poder automatizarse y repetirse
b. Cubrir todo lo posible
Por ende, debe aparecer un nuevo rol: TESTER

Se le pueden realizar test de JUnit a:

a. Métodos públicos
b. Test independientes entre si
Y las preguntas que más aparecen de manera común son:
a. assertEquals
b. assertNull
c. assertNotNull
d. assertTrue
e. assertFalse
 f. assertSame
g. assertNotSame
h. assertThat
i. assertArrayEquals
La razon del porque deberia hacer los test son mas comunes de lo que cualquier
programador pensaria:
a. Verifican el codigo
b. Localizar errores
c. Se pueden automatizar
d. Documentan tu codigo, muestran el como usarlo
e. Obliga a mejorar el codigo
f. Facilita cambios de codigo
g. Ayuda a refactorizar, desacoplar algunas clases y simplificar los metodos

CLEAN CODE
Comentarios

Si es necesario comentar un fragmento de código significa que el código no es

muy limpio
Los comentarios se pueden clasificar de las siguientes formar
a. Comentarios malos
a. Obvios (generados normalmente por los editores)
b. Corporativos/Disclaimer/Legales
c. Historial
d. Saludos/Greets
e. Javadocs a no ser que sea para una API publica
f. Desahogos/Pensamientos
g. Secciones/Ascii Art
h. Marcar cierres
i. Codigo documentado (codigos que no se usan)
j. Comentarios informativos generales
k. Comentarios confusos (inconexos, inutiles, e irrelevantes)
b. Comentarios validos
a. Para formatos de fechas
 b. Para explicar una exprecion regular
c. Aclarar alguna intencion en caso de ser super necesario
d. Clarificar un resultado
e. Advertencia
f. Los TODOs

Nombres (Clases, variables y métodos)

Variables:
 No escatimar en el nombre
 Deben explicarse por si solos y ser claros
 Nombre coherentes
 Deben ser sustantivos
o int age;
o String firstName
 Deben tener un proposito
o Boolean isDead

Metodos:
 Deben ser verbos ya que reflejan una accion
o loadFile
o validate
 Deben describir su funcion
 En caso de ser booleanos
 IsFinished (en caso que se manejen en ingle siempre debe ir “is”
en el nombre del metodo booleano)
Clases:
 Deben ser sustantivos o frase de nombres
o Order
o XMLParser
 Evitar verbos
 Evitar nombres genéricos
o Data
o Loader

Generalidades a manejar
 Tratar que describan el “problema”:
 o No revelan intencion
 Int foo = 0;
o Si describen el problema
 Int age;
 float amount;
 Deben estar sujeto al dominio (empresa a a la que va dirigido el codigo)
o Significados especiales
o Patrones: CustomerFactury
o Implementacion de interfaces: ParserImp
o Estructura subyacente: CustomerMap, OrderList
 Sean pronunciables
 Tratar que no sean tan ambiguos o generen informacion erronea
o ArrayList elementos  Que clase de elementos manejan
o String nameOfTheCustomerWhoHasPaid
o String nameOfTheCustomerWhoHasntPaid
 Distingir que contiene
 Procurar usar conectores unicos
 Evitar codificaciones, prefijos
o LblClientName es un label  Suele verse en Visual Studio
 Aplicar la regla del ambito
o La longitud de una variable debe ser proporcional a su ámbito
o Usualmente manejar una sola letra para ciclos o datos que solo se
vayan a usar una vez

Métodos

El método deberá hacer solo una cosa y hacerla bien, debe tener una extensión
máxima de 5 líneas, además de caber en la pantalla que se esté proyectando, ser
legible u en casos extremos su longitud deberá ser de 24 líneas de código.
En cuestión de parámetros este deberá tener como máximo 3 y que no sean
booleanos ya que son muy propensos a dar error, estos tampoco deberán servir
para validar un switch/case, tampoco manejo de datos nulos, ni usar Out
1. In  Solo es de entrada su valor no cambia al terminar la llamada
2. Out  solo de salida, su valor puede cambiar al terminar la llamada
3. In/out  tanto de entrada como de salida
En caso que un método maneja más de una responsabilidad este se le deberá
aplicar la refactorización extract until you drop, es decir extraer la responsabilidad
de más y separarla en un método nuevo
Evitar la programacion defensiva la cual consta de validar siempre que los
parametros que pasamos estan pasando de manera correcta o deseada ya que
estos valores deben venir validados desde antes

Evitar el tratar de alterar la ejecucion normal de la app, ademas de evitar usar los
comandos break, continue y return en funciones grandes y se hacen aceptables
en metodos pequeños
Ademas que los errores deben manejarse por un try-cath y los switch se pueden
reemplazar por una refactorizacion, realizar una llamada al metodo que es y no
confirmar dicha llamada

Clases

Las clases deben tener responsabilidades pequeñas y por lo general debe ser solo
1, si es necesario cambiar la funcionalidad de la clase debe ser por un motivo
razonable e incluso deben tener cohesión entre clases y aun así no deben
solaparse entre ellas mismas
Las características de buenas clases son tener pocos atributos y estos deben ser
usados por todos métodos.
Se deben controlar de manera correcta los cambios que se realicen en la clase,
manejar riesgos tales como errores, al añadir más responsabilidades o cambiar la
responsabilidad que ya tiene la clase; es necesario que la clase este protegida y
de ser posible manejar interfaces.
Un error común es el uso innecesario de métodos SET y GET y en muchos casos
todos estos métodos no son usados.
Estructura de datos vs objetos:
1. Se disitnguen según
a. La que exponen
b. La que ocultan
2. DTO y registros activos Mapean datos de una BD
a. DTO: datos
 b. Registrar activos: datos con metodos para gestionar registros
Una forma de medir la cualidad de una buena encapsulacion es usando LA LEY
DE DEMÉTER, ejemplo:
El método F de una clase C solo puede llamar:
 Métodos de de la clase C
 Objetos creados por el método F
 Objetos pasados como argumentos al método F
 Objetos contenidos en atributos de la clase C

Arquitectura

Una buena arquitectura se logra identificar gracias a que sus elementos son
fáciles de localizar, además que en caso alguno de necesitar un cambio en alguna
parte de la arquitectura esta no afectará al desarrollo del programa, haciendo que
el programa sea más fácil de testear.
Cabe recalcar que una buena arquitectura siempre está abierta al cambio hasta el
final del desarrollo del programa o proyecto y la mejor forma de lograrlo es retrasar
ciertas decisiones (Frameworks, BD, Bootsrap, entornos, etc. ya que son solo
herramientas) así maximizando el número de opciones
Los casos de uso son el TODO de la arquitectura y estos no deben mezclar se con
la UI, BD, etc.
Manejar un buen sistema de particionado tales como:
1. Business objects: Entities
a. Entidades independientes de la app, representan elementos del
dominio, pero no mapean exactamente la base de datos
2. Use Case: controls / Interactor
a. Son los metodos mas especificos de la app , los casos de uso
3. UI object: boundaries
a. Frontera entre la arquitectura y el exterior
b. Son mecanismo de entrega
c. Comunican los casos de uso con la UI y la BD
 REFACTORIZACIÓN

“Es más complicado escribir código que entienda otra persona que lo entienda
una maquina ya que cualquier idiota puede hacer”

Para muchos programadores es todo un desafío, en ciertos aspectos, cambiar

algo del código en el que se encuentren trabajando y no alterar su comportamiento
inicial y así mejorar la estructura, en especial a los programadores junior
En el ámbito de la refactorización hay algo llamado CODE SMELLS o CODIGO
APESTOSO que se divide en generales y específicos

Code Smells generales

Este tipo de códigos suelen identificarse por el código repetido (copy/paste), hay
abstracciones ni herencia además de no haber unas reglas de negocio claras y ser
un software procedimental.
Otras características a destacar son:
 El código es rígido, lo cual genera que sea difícil realizar un cambio este y
en caso de necesitar uno puede obligar hacer modificaciones a módulos
independientes, este no permite estimar con precisión los tiempos
necesarios para introducir cambios
  Fragilidad: El sistema presenta cambios inesperados, es decir, a veces
sirve a veces no, el sistema se puede romper al momento de presentar
cambios e incluso si se cambia una parte del sistema y en cierta parte de
este algo se daña
 Viscosidad: Hay varias formas de realizar un cambio, pero estos pueden
alterar el diseño planeado para el sistema, resulta más fácil usar HACKS
que realizar cambios que realmente ayuden al sistema e incluso es más
fácil meter “la pata” que acertar al momento de realizar ciertos cambios y
por ende se necesita más tiempo para compilar, hacer test unitarios, etc.
 Inmovilidad: El sistema contiene partes que se pueden usar en otros
sistemas, pero estos no se pueden separar, el esfuerzo y riesgo de separar
las partes es demasiado alto para correr el riesgo
 Complejidad innecesaria: El código y el diseño de este presenta un
problema a futuro, se usa código muerto (métodos, atributos y variables que
no se usan en ningún momento), el código presente áreas inaccesibles
además de funcionalidades no solicitudes
 Opacidad: El diseño resulta algo difícil de entender y el código algo difícil
de entender
 Uso de múltiples lenguajes o idiomas
o HTML/JavaScript/CSS
o Java/XML/HTML/JSON
o Ingles/español
 El comportamiento del sistema no es obvio o lo esperado de este y no
maneja casos excepcionales o extremos: datos vacíos, negativos, etc.
Haciendo que el sistema no sea capaz de responder a estos datos
 Algunos aspectos del código tales como:
o Espaciado inconsistentes
o Indentacion incorrecto
o No seguir convenciones
o Los métodos no siguen un orden
 Los datos de configuración no están en un nivel alto y no se encuentran
separados del código

Código Smells específicos

Son problemas de manera que se dan en ciertas partes del código que puede ser
más fácil de solucionar e incluso ya se han hablado de ellos anteriormente
 Los comentarios no deben existir a no ser que sea muy necesario
 Los métodos largos, recordemos que un método solo debe hacer una cosa
y tener como máximo en lo posible 5 líneas de código y en casos extremos
hasta 24, en caso que el método este manejando más de una
responsabilidad se le deberá aplicar las siguientes refactorizaciones, que se
explicaran más adelante
o Extract Method
o Replace Temp with Query
o Replace Method with Method Object
 El manejo de muchos parametros, recordemos que deben ser como
maximo 3, y en caso que haya mas se debera realizar las siguientes
refactorizaciones:
o Introduce Parameter Object
o Replace Parameter with Method Call
 Para el código repetitivo o duplicado se debería realizar las siguientes
refactorizaciones:
o Extract Method
o Pull up
o Substitute Algorithm
 Código desordenado o clutter, constructores de mas setters, getters,
toString, etc sin necesitarlo o incluso sin usarlos realmente, se recomienda
usar la encapsulación
 Los imports son demasiados e incluso son de la misma “rama”, es preferible
usar todo un import a tenerlo repetido varias veces para algo en especifico

.
 Condicionales muy complejas, tratar de cambiarlas por polimorfismo o
patrones Strategy , las negaciones son muy dificiles de leer por ende es
mejor tener operaciones, para este tipo de situaciones se recomienda el
uso de Extract Method
 Explosión combinatoria, esto ocurre cuando tenemos partes de código que
realizan la misma operación, pero con distintos datos o comportamientos,
para esto se recomienda el uso de interfaces y la refactorización se llama
extract interfaces
 Clases muy largas, recordemos que las clases no deben ser excesivamente
largar y en caso de ser así cuentan con muchas responsabilidades, se
recomienda las siguientes refactorizaciones
o Extract class
o Introduce parameter Object
 Los nombres que no indican alguna función en específico o nombres que
no tiene que ver con su función, se aplica la refactorización de RENAME y
al código muerto (recordando que el código muerto es código que no se
está usando, pero existen) se aplica la refactorización llamada DELETE
 No se debe pensar el en futuras situaciones ya que esto sería una
generalidad de código y estaría mal visto
 Uso de atributos temporales u opcionales, clases con muchos campos
opcionales o innecesarios, para esto se recomienda la creación de una
clase en específico que maneje dichos datos
 La existencia de clases similares, pero con distintas interfaces, este tipo de
clases similares se pueden llegar a generalizar, renombrando o creando
una superclase y así reduciendo la duplicidad, las refactorizaciones
recomendadas son:
o Rename
o Move Method
o Extract Superclass
 Uso de valores primitivos, estos se usan de manera excesiva para la
manipulación de datos y es más conveniente extraer una clase para ellos,
se recomienda el uso de la refactorización Replace Data Value with
Object o Introduce Parameter Object
 Clases de datos, por lo general las clases deberían mostrar un
comportamiento, no solo almacenar datos
o Encapsulate Field
o Encapsulate Collection
o Move Method
 Agrupaciones de datos, los datos de distintas clases aparecen siempre
juntas, quiza haya que agruparlas en una clase
o Extract Class
o Introduce Parameter Object
 Herencia rechazada, se aplica la herencia pero resulta que no se usan los
métodos heredados en la subclase, o si los usamos pero en efecto distinto
o Replace Inheritance with Delegation
 Intimidad inapropiada Se trata de que las clases sepan mucho uno de las
otras. No deberian haber interdependencia(trabajen juntas pero la una sin
saber de la otra)
o Move Method
o Move Field
 Exposicion indecente, evitar en lo posible que las clases muestren mas de
lo necesario
o Encapsulate
 Envidia, los metodos que hacen un uso muy extensivo de otra clase quiza
no estan tan donde deberian
o Move Methods
o Extract Method
 Clases vagas, clases que tienen poca importancia y pueden ser integradas
a otras
o Inline class
 Cadenas de mensajes, si se ven una secuencia de llamadas y uso de
temporales, es muy probable que exista una dependencia muy fuerte
o Hide Delegate

 Intermediario, cuando una clase acaba delegando todas las acciones quiza
no tiene sentido que siga existiendo
o Hide Delegate
 Cambio divergente, al realizar cambios en la clase nos damos cuenta que
se hacen en apartados muy dispares, quizas la clase haga demasiadas
cosas
o Extract class
o Extract Superclass/Extract subclass
 Cirugia escopeta, cuando se realiza un cambio en una clase requiere
cambiar michas otras clases relacionadas
o Move Field
o Move Method
 Herencias paralelas, cada vez que se hace un subclase tiene que hacer
otra subclase en otro punto, deben unirse
o Move Field
o Move Method
 Librerias incompletas, cuando necesitamos un método en concreto que no
se encuentra en la libreria
o Introduce Foreign Method
o Introduce Local Method
  Solucucion expandida, para conseguir algo en concreto necesitamos un
monton de clases distintas, se debe simplificar el diseño

Tipos de refactorizaciones

Cabe recalcar que a medida que se vaya refactorizando un código puede que este
cambie y haya ciertas incongruencias entre los tipos de refactorización, es algo
normal ya que el código mantiene en un estado cambiante y ningún tipo es una
solución fija para el problema que este en el momento

Nombre de la Función Motivación Beneficios

refactorización
Cambiar los nombres Se aplica cuando el Aclaracion
Rename de las variables, nombre no explica Mayor legibilidad
métodos, claramente el Cumplir convenciones
parámetros, clases, propósito del
etc. elemento
Encapsulate/Encapsulació Hacer privados Aplicar el principio No exponer detalles
n atributos y métodos de encapsulacion Mejorar operaciones
que no sean usados de POO de acceso
desde afuera
Magic Number / extraer Modificar valores Sustituir un número Aclarar el propósito del
constantes númericos y inexplicado por una número
convertirlos a constante con un Legibilidad
constantes nombre que aclare Facilita el cambio
el significado del Evita los cambios
número accidentales en un
punto
Evitar el uso de
números complejos:
3,14
 Extract Method/ Extraer Sacar parte del Simplificar métodos Código mas legible
método codigo de un método Eliminar código
y meterlo en un duplicado
método nuevo Reducir el tamaño del
método
Inline method Reintroducir el Simplificar quitando Codigo legible
código de un método métodos Evitar la proliferacion
dentro del método demasiados simple excesiva de métodos
que le llama u obvios Simplificar las clases

Convertir parámetros en Sustituir una lista de Reducir el número Codigo mas legible
objetos parámetros por un de parámetros de Reducir el número de
objeto los métodos parametros
Evitar duplicidad de
código en parámetros,
comprobaciones
Replace Temp with Query Las expreciones que Eliminar variables Codigo legible
se guardan en temporales y servir Reutilizacion de
variables temporales como preparacion a expreciones
se extraen como Extract Method Facilitar la extraccion
métodos de metodos
Introduce Explaining Sustituir una Aclarar el Codigo/Condicionales
Variable expresion compleja significado de mas legibles
por una variable expresiones Aclara el proposito de
complicadas las expreciones
Split Temporary Variable Cambiar una variable Procupar asignar a Codigo mas legible
temporal que se cada elemento del Una resposabilidad
reutiliza para código un unico única para cada
distintos fines en un proposito variable
método Evita efectos
inesperados
Facilita el extract
methods
Borrar las asignaciones a Evitar que se Evitar el descontrol Asignar un proposito
parámetros asignen valores a un del valor de ese unico a los parametros
parametro de un párametro Evitar efectos
método inesperados
Reemplazar método con el Extraer un método Facilitar que se Codigo mas legible
objeto del método complejo lleno de pueda simplificar el Aislar un método
variables a una clase método complejo
especifica convertiendo Facilitar el Extract
variables en Method
campos de la clase Simplifica las clases

Descomponer condicional Descomponer las Simplificar las Codigo mas legible

 expresiones expresiones en las Condiciones mas
complejas de una condicionales expresibas
estructura Reutilizacion de
condicional condiciones
Reduccion de métodos
Consolidar una exprecion Agrupar los bloques Simplificar el codigo Codigo mas legible
condicional condicionales que Evitar la duplicidad de
comporten el mismo codigo
cuerpo de condicion Reduce el tamaño de
método
Consolidar fragmentos de Extraer código que Evitar la duplicidad Reutilizacion de código
condicional duplicados se repite dentro de de código Reduce el tamaño de
distintas expreciones métodos
Eliminar bandera de control Eliminar variables Evitar mecanismos Simplificar el codigo
que se utilizan para obsoletos de control Facilita el seguimiento
controlar el flujo del en favor de de la ejecución
programa instrucciones como
break, continue o
return
Reemplazar condicionales Simplificar las Facilitar la Codigo mas legible
anidades con clausulas estructuras de las legbilidad del Reduce el tamaño del
guards condicionales codigo metodo
aninadas, a ser Aislamiento de
posible llegando a un clausulas que permite
unico nivel reordenarlas de forma
optima
Facilita el Consolidate
Conditional Expression
Facilita el seguimiento
de la ejecucion
Reemplazar una Sustituir las Evitar la duplicidad Evita la duplicidad de
condicional con expreciones de estructuras codigo
polimorfismo condicionales por condicionales cada Facilita la extension de
jerarquias de clases vez que se quiere casos
hacer una accion Aplica el princio Tell-
Dont-Ask
Introducir un objeto nulo Modificar un valor Evita la Elimacion de
null por un objeto comprobacion de si comprobaciones y
que represente un algo es o no null condicionales
valor nulo Simplificar el codigo
Separar consulta de Evitar que un mismo Procurar que cada Cada método solo
modificación método se consulte método haga una tiene un proposito
datos y a la vez haga cosa y evitar que un Se reduce el tamñao
modificaciones método de consulta de los métodos
tenga efectos Se evitan efectos
inesperados inesperados
 Parametrizar método Unificar en un Evitar codigo Evitar duplicación
método varios duplicado Facilitar nuevos casos
métodos en los que con el parametro
solo cambia un valor

Reemplazar parámetro con Separar un método Evitar el excesivo Codigo legible

métodos explicitos que hace varias crecimiento de un Controlar el tamaño de
acciones/tareas método los métodos
dependiendo el Extension de casos no
parametro causa problemas

Sustituir algoritmo Modificar el codigo Mejorar el Los que provea el

interno de un método funcionamiennto y nuevo algoritmo
rendimiento Simplifica el
concreto de un mantenimiento si se
método usan librerias de
terceros
Extract Class/Extraer clase Sacar parte del Extraer de una Codigo legible
contenido de una clase una porcion Simplificar clases
clase a otra que tiene sentido Desacoplamiento
como clase Single Responsability
diferenciada Principle
Inline Class Meter el contenido No tener una clase Eliminar clases inutiles
de una clase dentro sin utilidad ni
de otra resposable de nada
Ocultar delegado Evitar que el cliente Ocultar los detalles Encapsulacion
entre a una clase del sistema del Desacoplamiento
delegada a traves de cliente Facilita los cambios del
clases intermedias sistema
Introducir metodos Añadir un metodo en Extender la Evitar duplicidad
externos la clase cliente para funcionalidad de Permite extender la
poder extender la una clase a la que funcionalidad de las
funcionalidad de otra no se debe tener clases
clase acceso
Introducir una extension Extender una clase Añadir nuevas Dotar de nuevas
local existente para poder funciones a una funcionalidades
dotarla de nuevas clase a la que no Creacion de
funcionalidades tenemos acceso componentes
reutilizables
Reemplazar un dato con Convertir un atributo Necesitamos dotar Ampliacion del sistema
un objeto de una clase en un a un atributo de un de forma desaclopada
objeto comportamiento y Se crea una clase
datos mas amplios coherente, aparte
Se evita que una clase
crezca y asuma
resposanbilidades
 ajenas
Single Responsability
Principle
Encapsular colección Ocultar los detalles Encapsulacion de Limitar el acceso a
de implementacion una colección para determinadas
de una colección evitar el acceso funcionalidades
directo a ella Dotar de
funcionalidades extra a
estructuras simples
Pull Up Es una jerarquia de Aprovechar el Eliminar la duplicidad
clases, subir a la mecanismo de Simplificar las
superclase herencia para no subclases
atributos/métodos duplicar
comunes a todos atributos/metodos
Pull Down En una jerarquia de La coherencia de la Codigo mas coherente
clases, mover jerarquia de clases Evita el acceso a
atributos/metodos de atributos/metodos
la superclase a las inutiles
subclases Evita la posibilidad de
errores
Reemplazar array con Convertir datos Crear un objeto que Codigo mas legible
objeto variados que se tenga un atributo Simplicidad/Desacopla
almacenan en un concreto para cada de clases
array en un objeto tipo de dato del Single Responsability
array Unique

PATRONES DE SOFTWARE
Los elementos de software que describen un problema y aportan una solución
reutilizable para el mismo
Un patrón de software se compone de 3 componentes:
 Nombre
 Problema/Escenario
 Soluciones
 Consecuencias
A su vez existen distintos tipos de patrones:
 Creacionales
 Estructurales
 De comportamiento
Creacionales

Singleton

Nos permite garantizar que solamente exista una instancia de una clase,
ocultando el constructor y solo permitiendo un punto de acceso a su instancia
única

Escenarios generales:
 Se requiere que una clase tenga únicamente una instancia
 Se precisa un acceso controlado a una instancia única a través de un único
punto llamada
 Cuando la instancia única debe ser extendida mediante una subclase y los
clientes deben ser capaces de hacerlo sin modificar el código de la clase
base
Factory

Define un interface para crear un objeto, pero deja en mano de las subclases que
clase concreta instanciar. Este patron por tanto, deja en manos de las subclases la
creacion de instancias

Escenarios generales:
 Cuando los sistemas deben ser capaces de utilizar diferentes familias de
objetos
 Las familias de objetos deben ser utilizadas juntas y queremos reforzar
esta condicion
 Cuando la creacion, conposicion y representacion de instancias debe
ser independiente del sistema que las utiliza
 Cuando las clases concretas deben ser desacopladas de los clientes
 Para realizar una publicacion de librerias sin exponer los detalles de la
implementacion, unicamente los interfaces
Abstract Factory

Provee una interfaz para crear un conjunto de jerarquias de objetos relacionados o

dependientes sin necesidad de especificar sus clases especificas

Escenarios generales:
 Es una evolucion del patron Factory, por tanto se puede aplicar en escenarios
similares
 Hay varias jerarquias de subclases
 Puede implementarse usando metodos factory o con Prototype
Builder

Separa la construccion de un objeto complejo de su presentacion, con la que el

mismo proceso de construccion puede dar lugar a diferentes representaciones

Escenarios generales
 Los algoritmo de creacion de objetos deben ser desacopladas del sistema,
ademas de las partes que los componen y de como se ensamblan
 Se precisan de multiples fromas de algoritmos de creación
 El proceso de construccion debe permitir diferentes representaciones del
objeto que se crea
 Se necesita poder añadir nueva funcionalidad de creacion sin que se cambie el
código principal

Prototype

Especifica los tipos de objetos a crear utilizando un prototipo de instancia y utiliza

una copia de ese prototipo para crear nuevos objetos

Escenarios generales
 Objetos o estructura de objetos deben ser identicos o deben paracerse a otros
objetos ya existentes
 Las clases que deben crearse se especifican en tiempo de ejecucion
 Cuando la creacion, composicion y representacion de los objetos debe
desacoplarse del sistema
 La creacion inicial de cada objeto es una operación costosa
 En los objetos existen un número limitado de combinaciones de estados.Por
tanto compesa definir unos prototipos y clonarlos, ajustanto eses estado
posteriormente

Estructurales

Adapter
Convierte el interface de una clase en otro interface que se ajusta mas a lo que
precisa el cliente. Este patron permite que clases que eran incompatibles puedan
relacionarse

Escenarios generales:
 Necesitamos usar una clase existente que no cumpla con los requerimientos
de una interface
 Necesitas crear una clase reutilizable que sea capaz de interactuar con clases
no relacionadaso imprevistas, en definitiva, clases incompatibles
 Necesita el acceso a multiples subclases pero es mas práctico adaptar el
interface de la clase base que crear subclases de las mismas para poder
usarlas
Brigde

Desacopla una clase partiendola en su abstraccion y en su implemtacion de tal

manera que ambas pueden variar de forma independiente

Escenarios generales:
 Las abstracciones y las implementaciones no deben estar vinculadas en el
momento de compilar o ejecutar.
 Las abstracciones y las implementaciones deberían ser extensibles, y además,
de manera independiente.
 Los cambios en la implementación de una abstracción no debe afectar a los
clientes.
 Los detalles de implementación deben ocultarse al cliente.
 Necesitas compartir una implementación entre muchos objetos y quieres
ocultarlo a los clientes

Composite:

Compone los objetos en estructuras de árbol para representar jerarquías de parte

o del todo. Este patrón permite a los clientes tratar a objetos individuales y sus
composiciones de manera uniforme.
Escenarios generales:
 Se precisan representaciones de objetos jerárquicas.
 Los objetos y las composiciones de objetos deben tratarse de la misma
manera. Los clientes deben poder ignorar las diferencias entre los objetos de la
jerarquía, sean compuestos o individuales.
Decorator

Otorgar responsabilidades adicionales a un objeto de manera dinámica. Suponen

una alternativa muy flexible a la creación de subclases para extender las
funcionalidades.

Escenarios generales:
 Poder añadir nuevas responsabilidades a los objetos de manera dinámica y de
forma transparente.
 No se pueden crear subclases para conseguir modificaciones.
 Las implementaciones deben poder desacoplarse de las responsabilidades y
los comportamientos.
 Una funcionalidad específica no puede residir en una clase base o en la parte
alta de la jerarquía de clases.
 Cuando se tiende a crear una jerarquía de clases demasiado grande para
cubrir todas las posibles variantes de funcionalidad a base de crear
extensiones.
Facade/Fachada

Provee una interface única para un conjunto de interfaces de nuestro sistema. Es

una fachada que se pone por encima del sistema para que este sea más fácil de
usar.

Escenarios generales
 Se precisa interface simple para dar acceso a un sistema complejo.
 Los sistemas y subsistemas se deben organizar en capas dando acceso de
una a otra través de fachadas.
 Existen muchas dependencias entre la implementación del sistema y los
clientes y se precisa desacoplarlos.
Flyweight

Se trata de compartir elementos ya generados, con el propósito de tener soporte

para un amplio número de objetos concretos.

Escenarios generales:
 Se utilizan muchos objetos similares y su coste es elevado
 La mayor parte del estado del objeto puede aislarse
 En lugar de utilizar muchos objetos, usamos y reutilizamos unos pocos
modificando su estado.
 La identidad de cada objeto no es relevante y la aplicación no depende de ello.
Proxy

Nos permite ofrecer un objeto por delante de otro para controlar el acceso al
mismo.

Escenarios generales:
 Se necesita un control de acceso al objeto original y deben proveerse distintos
derechos de acceso.
 El objeto representado es externo al sistema.
 Se requiere funcionalidad añadida cuando se accede a un objeto: contadores
de acceso, registros de acceso, control de bloqueo, etc.
 Se precisa crear objetos costosos bajo demanda

Comportamiento

Chain of Responsability / Cadena de resposabilidades

Este patrón está orientado a evitar el acoplamiento entre el emisor y receptor

dando a diferentes objetos encadenados la opción de ocuparse de las peticiones.

Escenarios generales:
 Muchos objetos pueden responder a una petición, no se sabe cuál de ellos es
a prioridad y no se precisa que esa petición sea responsabilidad de un único
objeto.
 Un conjunto de objetos, deberían ser capaces de responder a una petición en
tiempo de ejecución, sin necesidad de especificar uno en concreto.
 Se puede asumir que una petición no sea respondida o tratada.
Command / Comando

Encapsula una petición como un objeto, permitiendo parametrizar los clientes con
distintas peticiones, además de encolar o registrar peticiones e incluso dar opción
a revertir peticiones.

Escenarios generales:
 Se precisa registrar un histórico de peticiones.
 Las peticiones pueden ser transferidas de un proceso a otro.
 Las peticiones deben ser soportadas en tiempo u orden variable.
 Se necesita desacoplar a quien lanza la petición de quien la soporta.
 Se precisa funcionalidad de callback, es decir, poder pasar como parámetro un
método a ejecutar. En POO aplicamos este patrón para poder tener callbacks.

Interpreter

Dado un lenguaje, define una representación de su gramática junto a un intérprete

que utiliza esa representación para interpretar sentencias de ese lenguaje.
Escenarios generales:
 Se necesita interpretar una gramática que puede estar representada a modo
de árbol.
 La gramática es simple. En el caso de gramáticas más complejas conviene
utilizar herramientas específicas, como parsers.
 La eficiencia no es relevante.
 Se precisa desacoplar la gramática de las expresiones subyacentes.
Iterator

Permite que un objeto agregado (que contiene un conjunto de elementos), pueda

ser accesible como una secuencia sin exponer su representación interna

Escenarios generales
 Se requiere acceder a un conjunto de elementos sin necesidad de acceder a
toda la estructura.
 Se necesita un interface único para recorrer la estructura.
 Existen diferencias entre los detalles de implementación de varios iteradores,
es decir, se precisa soporte para la iteración polimórfica.
Mediator

Define un objeto que encapsula la manera en la que otros objetos interactúan.

Este patrón otorga mayor desacoplamiento al hacer que los objetos no interactúen
entre si de forma directa.

Escenarios generales
 La comunicación entre un conjunto de objetos está bien definida y es compleja.
La dependencia entre ellos no tiene estructura concreta o es difícil de entender.
 Existen demasiadas relaciones y se precisa un punto único para el control o la
comunicación.
 Es difícil reutilizar un objeto porque tiene referencias y comunicación con otros
objetos.
 Un comportamiento que se reparte entre muchas clases necesita ser
personalizado sin hacer subclases.

Memento
Permite sacar una instantánea del estado de un objeto para externalizarlo,
guardarlo o recuperarlo más adelante, todo ello sin desencapsular el mismo.

Escenarios generales
 Cuando el estado interno de un objeto debe poder ser salvado para ser
recuperado más adelante.
 Los límites de la encapsulación deben preservarse.
 Se precisa si al exponer el estado a través de interfaces se acaba exponiendo
la implementación

Observer / Observador

Define una dependencia uno a varios entre objetos de tal manera que cuando el
estado de un objeto cambia, todos los elementos dependientes son notificados y
cambian de manera automática.
Escenarios generales
 Los cambios de estado en uno o más objetos debe afectar al comportamiento
de otros objetos.
 Se precisan capacidad de broadcasting entre objetos.
 Se requiere que los objetos no tengan que preocuparse de la propagación de
mensajes o notificaciones.
 Cuando un objeto precisa cambiar otros, pero no sabemos quienes o no
podemos asumirlo previamente. Y por supuesto, no queremos acoplamiento.
 Cuando una abstracción tiene dos aspectos dependientes. Si encapsulamos
esos aspectos en objetos separados podemos variarlos y reutilizarlos de forma
separada.
State

Permite a un objeto alterar su comportamiento cuando su estado interno cambia.

Se crea un objeto específico por cada estado, no es lo mismo que el patron
MEMENTO

Escenarios generales
 El comportamiento de un objeto debe ser regido por su estado y debe poder
hacerlo en tiempo de ejecución.
 Condiciones complejas vinculan ese comportamiento a su estado. Pueden
existir estructuras condicionales cuyas ramas se procurarán separar en
diferentes clases.
 La transición entre los estados de un objeto debe ser explícita.
Strategy

Nos permite definir una familia de algoritmos, encapsulando cada uno de ellos y
haciéndolos intercambiables. Este patrón nos permite que un algoritmo puede
variar de forma dinámica en el uso que hacen los clientes.

Escenarios generales
 Se requieren muchas versiones o variantes de un algoritmo.
 Se aplica cuando la única diferencia entre muchas clases relacionadas es su
comportamiento.
 El comportamiento de una clase debe definirse en tiempo de ejecución.
 Los algoritmos utilizan datos a los que el código no queda expuesto.
 Existen sentencias condicionales complejas y difíciles de mantener.
Template Method

Define el esqueleto del algoritmo de una operación, delegando alguno de los

pasos a las subclases. Este patrón permite que las subclases modifiquen ciertos
pasos de un algoritmo sin modificar la estructura general del mismo.
Escenarios generales
 Se precisa una única implementación abstracta de un algoritmo y en todo caso
dejar las particularidades las subclases.
 El comportamiento común entre subclases debe localizarse en una clase
común.
 Cuando las todas o la mayoría de las subclases necesitan implementar un
comportamiento.
 Controlar mejor la extensión en las subclases utilizando mecanismos tipo hook
en métodos que nos permitan extender el comportamiento solo en ciertos
puntos.
 Las clases base debe ser capaces de invocar de forma uniforme a las
subclases.
Visitor

Representa una operación que debe ser efectuada en los elementos de una
estructura de objeto. Nos permite definir un nuevo método u operación sin
necesidad de cambiar las clases de los elementos en los que actúa.

Escenarios generales
 Se necesita cuando una estructura de objetos debe tener múltiples
operaciones no relacionadas.
 Se precisa ejecutar operaciones sobre clases concretas de una estructura de
objetos
 La estructura de objetos no puede cambiar, pero si las operaciones que se
hacen sobre ellos.
 Se necesita cuando las operaciones deben ser aplicables en múltiples
estructuras de objetos que implementen los mismos conjuntos de interfaces.
 PRINCIPIOS SOLID

Son principios basados en POO que permiten tener un código más limpio,
mantenible y extensible
Cada letra es un principio y cada uno de estos principios cuenta con una
definición:
 Single Responsability Principle
 Open/Closed Principle
 Liskov Subtitution Principle
 Interface Segregation Principle
 Dependencia Inversión Principle

SRP: Single Resposability Principle

Principio
 Las clases deben ser pequeñas en responsabilidades
 Una clase de tener una única responsabilidad dentro de todo el proyecto
 Si se cambia algo, solo debería haber una razón
 Puede haber mas de un rol usando la clase
Problemas:
 Si se cambia algo afectará a otros
 Tiene más acoplamientos, dependencias y es sensible a cambios
OCP: Open/Closed Principle

Principio
 Un módulo de software debe estar abierto a extensiones y cerrado a
modificaciones.
o Abierto: debería ser fácil cambiar el comportamiento del módulo
o Cerrado: ese comportamiento se debería poder cambiar sin
modificar el módulo
 Basta con escribir un buen módulo
 Las modificaciones se basan añadir nuevo código, no en modificar el
módulo.
Problemas
  Es difícil en sistemas grandes

LPS: Liskov Subtitution Principle

Principio
 Si S es un subtipo de T, los objetos de tipo T en un programa pueden ser
intercambiados por objetos de tipo S sin alterar ninguna de sus
propiedades.
 Ejemplos el cuadrado y un rectangulo / Carro electrico o gasolina
ISP: Interface Segregation Principle

Principios
 Los clientes no deberían implementar interfaces que no utilicen
 Es preferible crear muchos pequeños interfaces que sean implementados
por clientes específicos.
Problemas
 Demasiados accesos no deseados
DIP: Dependency Inversion Principle

Principios
 Los módulos de alto nivel, deben depender de abstracciones, no de los
módulos de bajo nivel.
 Las abstracciones, no deben depender de los detalles de bajo nivel. Los
módulos de bajo nivel, también deben depender de abstracciones.
Elementos de un sistema
 Módulos de alto nivel, lógica de negocio
 Módulos de bajo nivel, detalles
 PRINCIPIOS LEAN (PRINCIPIO DE INVERSIÓN DE
DEPENDENCIA)

Estan inspirados en los sistemas de gestion industrial, LEAN lo cual significa

ajustado
Principios de LEAN

 Eliminate waste/eliminar la basura

o Desarrollar una funcionalidad o producto incorrecto
o No gestionar bien el backlog
o Volver a hacer el mismo trabajo
o Desarollar soluciones innecesariamente complejas
o Carga cognitiva
o Estress psicológico
o Espera/Multitarea
o Perdida de comunicación
o Comunicación inefectiva
 Amplify learning / aprendizaje amplificado
o Desarrollo  Aprendizaje continuo
o Las ideas se plasma en código
o Reuniones  Aprendizaje dominio y necesidades
o Ciclos cortos con refactoring y tests
 Decide as late as posible / Decidir lo mas tarde posible
o Posponer decisiones críticas
o Ajustar la solución en ciclos
o Probar y evaluar
 Deliver as fast as posible /entregar lo mas rapido posible
o Proyectos web y móviles
o Feedback continuo
 o El primero en llegar triunfa
 Empower the team / Fortalezer el equipo
o Sin gestores ni “recursos”
o El equipo asume su gestión
o Tareas asumibles y contacto con cliente
o ¿Cumple el test de Joel? ¡Deja en paz al equipo!
 Build integrity in / Construir con integridar dentro
o Ofrecer imagen de robustez
o Integridad = flexibilidad + mantenibilidad
o ¿Cómo?
 Contacto con cliente
 Ciclos
 Información en pequeñas dosis
 Refactoring + Testing + integracion continua
 See the whole / Verlo todo
o Proyectos complejos
o Dividir y descomponer tareas
o Trabajar con equipos mas estables
o Implicar todas las partes