PDF de programación - Principio de responsabilidad única

Principio de responsabilidad única

Este artículo, dedicado al llamado "Principio de responsabilidad única", es el primero de una serie de cin-
co artículos que descubren cinco principios fundamentales del paradigma de la Programación Orienta-
da a Objetos (POO).

F

ue en los preparativos del Code Camp
de Tarragona ‘2009 cuando surgió la idea de escri-
bir esta serie de artículos para describir cinco prin-
cipios fundamentales de la POO cuyas iniciales con-
forman las siglas SOLID. La comprensión de dichos
principios nos permitirá mejorar la percepción del
no siempre fácil campo de la POO, evitando así
malas prácticas que la gran flexibilidad que ofrece
esta metodología otorga, fundamentalmente a través
de los lenguajes y herramientas que la soportan.

Las herramientas de desarrollo rápido (Rapid
Application Development, RAD), como Visual Studio
2010, ofrecen al desarrollador un conjunto de fun-
cionalidades que aumentan, ya sea a través de asis-
tentes o mediante "arrastrar y soltar", la productivi-
dad en el desarrollo de aplicaciones, y le permiten
focalizarse únicamente en la utilización de propie-
dades o eventos específicos, sin tener que preocu-
parse en muchas ocasiones del código generado "por
debajo". Sin embargo, en ocasiones acabamos pagan-
do un precio muy elevado, ya que estas herramien-
tas dejan tras de sí "cajas negras lógicas" de código
difíciles de modificar o reutilizar, en las que los con-
ceptos clave de la orientación a objetos son sacrifi-
cados en aras de la productividad; pero hablar de pro-
ductividad es hablar de facilidad de mantenimiento
y calidad del software, con lo que dicho sacrificio, sen-
cillamente, no tiene o debería tener cabida.

está compuesto por una serie de componentes,
tales como la pantalla, el teclado, la radio GPRS/3G,
el módulo Bluetooth, etc. Todos estos componen-
tes tienen una responsabilidad específica, ya sean
los módulos de entrada y salida de datos o los
módulos de conectividad y comunicación, etcéte-
ra, y por tanto existe una cohesión entre todos los
componentes, ya que no hay ningún componente
que haga funciones que se solapen con las de otros
componentes, ni ninguna función básica que no
quede descubierta por un determinado compo-
nente. A la hora de buscar un nuevo móvil, mira-
remos las características y especificaciones técni-
cas del dispositivo, y además de contemplar las
especificaciones que deseamos, también espera-
remos que los componentes sean de alta calidad;
no es viable que un móvil esté compuesto por los
últimos componentes electrónicos del mercado y
se venda con una pantalla no táctil en "blanco y
negro" de 3 pulgadas, o que, por ejemplo, no ten-
ga algo tan básico como un micrófono.

En un sistema informático también tenemos
componentes (además de módulos, clases, etc.),
y todos estos componentes lógicos tienen su res-
ponsabilidad dentro del sistema. Pensemos pues
en el nivel de cohesión de una aplicación no como
en una suma de los componentes, sino como el
conjunto de los mismos.

Cohesión

Acoplamiento

Para tratar de comprender el término "nivel de cohe-
sión", vamos a utilizar como ejemplo el teléfono
móvil. Como todos sabéis, un dispositivo móvil

Siguiendo con el ejemplo del teléfono móvil, un
ejemplo de acoplamiento lo encontramos en los
cargadores de nuestros móviles. Son cada vez más

José Miguel Torres y Hadi Hariri
MVP de Device Application Development
y Technical Evangelist en JetBrains

los fabricantes que optan por adaptado-
res de corriente estándar en lugar de cre-
ar adaptadores propietarios que casi
siempre acaban tirados en el contenedor
de reciclaje cuando sustituimos el móvil.
Se entiende que se opta por la universa-
lidad de los dispositivos de corriente para
su reaprovechamiento en otros disposi-
tivos, incluso de diferentes fabricantes.
En la ingeniería del software, el acopla-
miento entre módulos, clases o cualquier
otro tipo de entidad lógica es el grado de
dependencia entre ellos. Cuanto más
estándar sea la relación de una entidad
lógica con otras, mayor reaprovecha-
miento podremos hacer de ella.

Encapsulación

Seguramente se habrá dado cuenta de
que la parte interna de un móvil no es fácil-
mente accesible; es decir, no tenemos
acceso a la electrónica interna. La idea de
la encapsulación es la de abstraer deter-
minadas funciones para que, además de
ser reutilizables, no requieran que los
usuarios tengan los conocimientos del
diseñador. La complejidad de un disposi-
tivo móvil o de cualquier otro dispositivo
electrónico es muy elevada, y la gran
mayoría de usuarios son capaces de sacar-
le el máximo provecho sin tener nociones
específicas sobre su arquitectura interna.
La radio Bluetooth o el módem GPRS/3G
son los mismos para varios modelos,
incluso de diferentes fabricantes. Esta es
precisamente la idea de la encapsulación
de funciones o características, que lo úni-
co que requiere es que el usuario sepa qué
se puede hacer con esa función y no cómo
está diseñada.

Aplicaciones SOLIDas

Siguiendo el modelo del teléfono móvil y
la idea subyacente de estos tres aspec-
tos, podríamos afirmar que el teléfono
ideal sería aquel que estuviera compues-
to por los mejores componentes del mer-
cado, cuyas interfaces de conexión para
la sincronización de datos y recarga de la
batería fueran estándares, y cuyas fun-
cionalidades pudiéramos conocer en pro-

fundidad sin necesidad de tener que con-
sultar detalles en la documentación téc-
nica para saber cómo han sido diseña-
das y así poder sacarles el máximo pro-
vecho.

Extrapolando este ejemplo a nuestro
mundo, el mundo del software, tenemos
que tener siempre presentes estos tres
aspectos fundamentales desde el momen-
to mismo en que empezamos el diseño
de una nueva aplicación. Es ahí donde
entran en escena los cinco principios des-
critos por el acrónimo mnemotécnico
SOLID y presentados a principio de esta
década por Robert C. Martin (figura 1).

que ver con el nivel de acoplamiento entre
módulos dentro de la ingeniería del soft-
ware. En términos prácticos, este princi-
pio establece que:

Una clase debe tener una y solo una
única causa por la cual puede ser modi-
ficada.

Si una clase tiene dos responsabili-
dades, entonces asume dos motivos por
los cuales puede ser modificada. Por
ejemplo, supongamos una clase llama-
da Factura, la cual dentro de un contex-
to determinado ofrece un método para
calcular el importe total, tal y como mues-
tra la figura 2.

Figura 1. Los cinco principios SOLID

Los principios SOLID pretenden ser
una guía a seguir durante la fase de
desarrollo para facilitar el manteni-
miento de las aplicaciones y tratar de
eliminar el impacto de las inevitables
modificaciones que éstas sufren duran-
te su ciclo de vida, además de facilitar
el uso de las unidades de testeo, entre
otras ventajas.

Principio de responsabilidad única

El Principio de responsabilidad única (Sin-
gle Responsability Principle - SRP) fue
acuñado por Robert C. Martin en un artí-
culo del mismo título y popularizado a
través de su conocido libro [1]. SRP tiene

Figura 2

Detectando responsabilidades

La piedra angular de este principio es la
identificación de la responsabilidad real
de la clase. Según SRP, una responsabi-
lidad es "un motivo de cambio"; algo que
en ocasiones es difícil de ver, ya que esta-
mos acostumbrados a pensar un con-
junto de operaciones como una sola res-
ponsabilidad.

Si implementamos la clase Factura
tal y como se muestra en el listado 1,

Los principios SOLID pretenden ser una guía a seguir
durante la fase de desarrollo para facilitar el manteni-
miento de las aplicaciones

a
í
n
a
M
t
e
N
t
o
d

33

public class Factura
{

public string _codigo;
public DateTime _fechaEmision;

public decimal _importeFactura;
public decimal _importeIVA;
public decimal _importeDeduccion;
public decimal _importeTotal;
public ushort _porcentajeDeduccion;

// Método que calcula el total de la factura
public void CalcularTotal()
{

// Calculamos la deducción
_importeDeduccion = (_importeFactura * _porcentajeDeduccion) / 100;
// Calculamos el IVA
_importeIVA = _importeFactura * 0.16m;
// Calculamos el total
_importeTotal = (_importeFactura ‐ _importeDeduccion) + _importeIVA;

blema es separar las responsabilidades;
para separarlas, primero hay que identi-
ficarlas. Enumeremos de nuevo los pasos
que realiza el método CalcularTotal1:

• Aplica una deducción. En base a la base
imponible se calcula un descuento por-
centual.

• Aplica la tasa de IVA del 16% en base

a la base imponible.

• Calcula el total de la factura, teniendo
en cuenta el descuento y el impuesto.

En este método se identifican tres res-
ponsabilidades. Recuerde que una res-
ponsabilidad no es una acción, sino un
motivo de cambio, y por lo tanto se
deberían extraer las responsabilidades de
deducción e impuestos en dos clases
específicas para ambas operaciones; esta-
bleciendo por un lado la clase IVA y por
otro la clase Deduccion, tal y como se
presenta en el listado 2.

}

}

Listado 1

podríamos decir que la responsabili-
dad de esta clase es la de calcular el
total de la factura y que, efectivamen-
te, la clase cumple con su cometido.
Sin embargo, no es cierto que la clase
contenga una única responsabilidad. Si
nos fijamos detenidamente en la imple-
mentación del método CalcularTotal,
podremos ver que, además de calcular
el importe base de la factura, se está
aplicando sobre el importe a facturar
un descuento o deducción y un 16% de
IVA. El problema está en que si en el
futuro tuviéramos que modificar la tasa
de IVA, o bien tuviéramos que aplicar
una deducción en base a una tarifa por
cliente, tendríamos que modificar la cla-
se Factura por cada una de dichas razo-
nes; por lo tanto, con el diseño actual
las responsabilidades quedan acopla-
das entre sí, y la clase violaría el prin-
cipio SRP.
Separando responsabilidades

public class IVA
{

public readonly decimal _iva = 0.16m;

public decimal CalcularIVA(decimal importe)
{

return importe * _iva;

}

}

public class Deduccion
{

private de