Hace poco me topé con un post en el que enumeraba las librerias y herramientas más interesantes para desarrollo con .NET y tenia ya ganas de crear mi propia lista de librerias recomendables para .NET. Esta lista de librerías son sólo un conjunto de las que, o bien más utilizo o he utilizado y las que creo, bajo mi punto de vista, que todo desarrollador debería, como mínimo conocer.

Dicho esto, a continuación detallo estas diez + dos librerías esperando vuestra opinión y feedback tanto para las que expongo como para las tantas otras que me he dejado en el tintero (la lista, afortunadamente, es cada vez más grande). Espero que os resulte útil:

Collections/Generics

PowerCollections – Es una libreria de colecciones genéricas complementarias a la que proporciona el CLR de .NET Framework desarrollada por Intellect las cuales conocí en el libro “CLR via C# 4.0” de Jeffrey Richter. Algunas de las clases que proporciona son Deque, MultiDictionary, Bag, OrderedBag, OrderedDictionary, Set, OrderedSet u OrderedMultiDictionary, además de las que extienden las que el propio CLR proporciona.

Dependency Injection/Inversion of Control

StructureMap - Además de StructureMap, Castle Windsor o Unity son otras de las librerias IoC que he utilizado. El motivo del uso de StructureMap fue quizás la mayor facilidad de uso [Opinión Personal] respecto a otras. De cualquier forma, en este punto es más importante el beneficio de la Inyección de Dependencias que el propio framework. StructureMap fue inicialmente desarrollada y mantenida por by Jeremy D. Miller, The Shade Tree Developer y Joshua Flanagan.

Design by Contract

Microsoft Code Contracts: Code Contracts facilita la adopción de la programación por contratos de forma agnostica al lenguaje mediante precondiciones, poscondiciones e invariantes. Esta bajo licencia Microsoft Research License Agreement.

Logging

Log4Net – Desde que conocí Log4net, despues de una muy mala, malísima vamos experiencia con otro tipo de librerias, tambien Open Source, me parece la apuesta más facil y eficaz para el logging de aplicaciones. Log4net forma parte del proyecto Apache Logging Services.

ORM

NHibernate/FluentNHibernate: No tengo mucha experiencia en este campo pero por lo poco que he tocado y por la experiencia, todas las librerias que surgen de la comunidad como necesidad acaban convirtiendose en un must-have, o must-use en este caso. Cabe decir que tampoco he mirado alternativas. NHibernate no es mas que la adaptación a .NET de la famosa libreria ORM para Java. FluentNHiberante facilita el, a veces, tedioso mapeo de entidades y objetos a través de los archivos hbm.xml. FluentNHibernate se define como una libreria XML-less ya que permite todo este mapeo a través de código.

No-SQL Database

MongoDB: Se trata de una de las bases de datos No-SQL más extendidas y pese a que no es una librería en sí, el conocimiento de sus posibilidades, sus pros y sus contras es obligatorio. Su modelo de datos por documentos está basado en JSON y BSON y por tanto es schema-less. Es una alternativa a las bases de datos relacionales gracias a la escalabilidad horizontal que proporcionan este tipo de herramientas. Está bajo Free Software Foundation’s GNU AGPL v3.0.

Unit Testing/Mocking/BDD

NUnit: Inicialmente basada en la libreria JUnit de Java, NUnit 2.5 es la sexta versión basda en xUnit. Está escrita en C# y fue totalmente rediseñada para sacar el máximo provecho a la plataforma .NET. Se integra estupendamente tanto con las MS Test Tools como con Resharper 5.x.

Moq: Muy útil especialmente para desarrolladores sin un gran bagaje en Mocking. Ofrece soporte a muchas de las características de .NET como LINQ Trees Expressions o expresiones lambda y se caracteriza por su facilidad de uso y su forma natural de escrbir stubs y mocks.

BDD specflow: Distribuida bajo licencia BSD e inspirada en Cucumber y su comunidad, esta libreria abarca las diferentes posibilidades del desarrollo orientado a comportamiento o BDD y resalta, entre otros, su uso con aplicaciones ASP.NET MVC.

Framework

nServiceBus: Framework de comunicaciones para arquitecturas SOA distribuidas, nServiceBus es un proyecto que surge de la necesidad en base a la experiencia personal de Udi Dahan, precursor y principal coordinador del proyecto. Recientemente ha incorporado nueva política de licencias y se anunció, y así hicimos en Genbeta dev, las novedades que traerá incorporada en la proxima versión 3.0.

Otras

Añado estas dos librerias por recomendación de un buen amigo y con las que todavia no he tenido la oportunidad de trabajar pero que estan haciéndose un hueco importante entre la comunidad de desarrolladores. Se trata de:

Elmah: ELMAH (Error Logging Modules and Handlers), es una libreria de logging específicamente desarrolada para aplicaciones ASP.NET y es especialmente útil para el registro de errores en Modulos y Manejadores de ASP.NET MVC.

NuGet: Otra de las librerias Open Source hospedada en Codeplex y miembro de la ASP.NET Gallery. Su intención es la de facilitar la integración y despliegue de librerias de terceros a los desarrollos .NET, evitando el tedioso proceso de referenciación y modificación de referencias en el app.config.

Foto | Tomada por L.Marie y hospedada en flickr.

En el Professional Developer Conference que se celebró el año pasado en Redmond se anunció Office 365, como apuesta por parte de Microsoft de aplicaciones de productividad en la nube. Pues bien, ya ha aparecido el Developer Training Course oficial del MSDN para el desarrollo de aplicaciones Office 365, tras la publicación de la primera Beta y la petición de muchos desarrolladores de un espacio de recursos e información.

El curso consta de 7 módulos, 10 horas de video y 17 hands-on-labs que cubren casi la totalidad de productos en términos de integración, desarrollo y despliegue. El índice completo y contenido del curso es:

Developing in the Cloud with Office 365

• Video: Developing in the Cloud with Office 365
• Video: SharePoint Online Overview
• Video: Exchange Online Overview
• Video: Lync Online Overview Developing for SharePoint Online with Sandbox Solutions
• Hands-On-Labs: Creating a Visual Web Part Sandboxed Solution for SharePoint Online
• Hands-On-Labs: Creating Custom Lists
• Hands-On-Labs: Custom Actions and Event Receivers
• Hands-On-Labs: Resource Points
• Video: Developing for SharePoint Online with Sandbox Solutions
• Video: Sandboxed Solutions – Deploying a List
• Video: Sandboxed Solutions – Event Receivers
• Video: Sandboxed Solutions – Resource Monitoring Building Workflow Solutions for SharePoint Online
• Hands-On-Labs: Building Workflow Solutions
• Hands-On-Labs: Implementing a Custom Workflow Action in Visual Studio
• Video: Building Workflow Solutions for SharePoint Online
• Video: Implementing Workflows in SharePoint Designer 2010
• Video: Developing Custom Workflow Actions with Visual Studio 2010 Developing SharePoint Online Solutions with the Client Object Model
• Hands-On-Labs: Using the Client Object Model in Silverlight
• Hands-On-Labs: Using the Client Object Model in JavaScript
• Hands-On-Labs: Accessing SharePoint Online List Data using SharePoint Web Services
• Video: Developing SharePoint Online Solutions with the Client Object Model
• Video: Using the Client Object Model with JavaScript Leveraging Excel and Access Services in SharePoint Online
• Hands-On-Labs: Excel Services
• Hands-On-Labs: Access Services
• Video: Leveraging Excel and Access Services in SharePoint Online
• Video: Leveraging Access Services in SharePoint Online
• Video: Leveraging the Excel REST API
• Presentacion: Leveraging Excel and Access Services in SharePoint Online Developing Communication Solutions for Lync Online
• Hands-On-Labs: Integrating Microsoft Lync 2010 Functionality into your Applications
• Hands-On-Labs: Launching Contextual Conversations from the Microsoft Lync Controls
• Hands-On-Labs: Introduction to the Microsoft Lync 2010 Managed API – Working with Automation
• Hands-On-Labs: Introduction to the Microsoft Lync 2010 Managed API – Exploring the Lync API Object Model
• Video: Developing Communication Solutions for Lync Online
• Video: Developing Contextual Conversation Solutions for Lync Online
• Video: Lync API Automation with Lync Online
• Video: Building Custom Communication Clients for Lync Online via the Lync API Developing Messaging Solutions for Exchange Online
• Hands-On-Labs: Getting Started with Exchange Web Services Managed API 1.1 – Working with Mailbox Items
• Hands-On-Labs: Getting Started with Exchange Web Services Managed API 1.1 – Working with Extended Properties
• Hands-On-Labs: Working with the Exchange Services – Free-Busy Service
• Video: Developing Messaging Solutions for Exchange Online
• Video: Development with Extended Properties with Exchange Online
• Video: Developing for Exchange Online Using the Free/Busy Service

Como soporte además se puede hacer uso de una maquina virtual de evaluación con Microsoft Sharepoint 2010 instalado para lo que no tienen un entorno de test. Por último necesitamos acceder a la Beta de Office 365 inscribiéndonos desde aqui.

Sitio oficial | Blog de Chris Mayo

Open Data Protocol, (aka OData), es una iniciativa impulsada por Microsoft para la exposición de datos como Servicio basándose en estándares de Internet y es la evolución de lo que era anteriormente conocido como ADO.NET Data Services (proyecto Astoria). Desde su aparición a principios del año pasado son ya muchos los productos, Web Sites y tecnologias que exponen sus datos utilizando este protocolo. En el caso de Microsoft lo podemos enconatrar ya en Sharepoint 2010, SQL Azure, Azure Storage, hasta ahora recientemente en Team Foundation Server (del que hablaremos en el proximo post).

Sobre la estandarización, OData está construido sobre Atom Publishing Protocol o AtomPub especificado en RFD 5023 quien a su vez está sontruido sobre Atom Syndication Format o Atom especificado en RFC4287.

OData tratar de dar solución a la exposición de orígenes de datos, relacionales o no, a través de un Servicio Web ejecutando operaciones con un lenguaje “estándar” basandose en:

• La creación de una forma uniforme de representación de datos estructurados a través de Atom o JSON (JavaScript Object Notation)
• La utilización de convenciones URL uniformes tanto para la navegación, filtrado, orden y paginación de datos (entre otros)
• La creación de operaciones uniformes dirigidas por dirección mediante las acciones GET, POST, PUT y DELETE.

Desde http://odata.org podemos encontrar API’s de creación y consumo de Servicios OData. Entre el abanico de librerías cliente podemos encontrar:

• OData Javascript Library
• OData SDK for PHP
• Restlet extension for OData (Java)
• ruby_odata: OData client library for ruby
• OData Client Library for Windows Phone 7 series
• OData client for Objective-C
• Silverlight 4
• OData Extension for Joomla
• OData Drupal

En cuanto a librerias de servidor, es decir API’s para la generación de datos, se encuentran:

• odata4j (Java)
• OData on Rails (prerelease for ruby)
• MySQL OData
• .NET Framework

Productos como Excel 2010, a través de PowerPivot, LINQPad, la mayoria de exploradores Web así como controles Telerik o Tableau ya dan soporte como consumidores compatibles con OData.

Por otro lado, entre las empresas que empiezan a exponer sus propios datos por OData se encuentran destacadas a eBay, Facebook Insight, IBM WebSpehere, Netflix, twitpic, GeoREST, Nuget, Windows Live o Dbpedia entre otras en el sector privado y Open Government Data Initiative (OGDI), The City of Edmonton Open Data Catalogue o Public Transit Data Community, por destacar algunas.

Más información | OData.org

Recently, I came across a interesting question on how to convert from a byte array to BitmapImage. The typicall scenario is when given an image represented by BitmapImage object it should be stored in a database as byte[].

The code I’m going to show below has been extracted from Stackoverflow.com but I found it in several sites after googling, therefore I can’t point out the author.

The code is quite simple just use:

   1: public byte[] GetBytes(BitmapImage bi) 

   2: { 

   3:     WriteableBitmap wbm = new WriteableBitmap(bi); 

   4:     return wbm.ToByteArray(); 

   5: } 

Where ToByteArray method is:

   1: public static byte[] ToByteArray(this WriteableBitmap bmp) 

   2: { 

   3:     // Init buffer 

   4:     int w = bmp.PixelWidth; 

   5:     int h = bmp.PixelHeight; 

   6:     int[] p = bmp.Pixels; 

   7:     int len = p.Length; 

   8:     byte[] result = new byte[4 * w * h]; 

   9:  

  10:     // Copy pixels to buffer 

  11:     for (int i = 0, j = 0; i < len; i++, j += 4) 

  12:     { 

  13:         int color = p[i]; 

  14:         result[j + 0] = (byte)(color >> 24); // A 

  15:         result[j + 1] = (byte)(color >> 16); // R 

  16:         result[j + 2] = (byte)(color >> 8);  // G 

  17:         result[j + 3] = (byte)(color);       // B 

  18:     } 

  19:  

  20:     return result; 

  21: } 

Another way to achieve it is using ImageTools for Silverlight. I have used it in several Windows Phone projects, specially animating gif images, and it contains a method that could be used in order to convert BitmapImage from and to byte[] by just using a few lines of code:

   1: using (var writingStream = new MemoryStream()) 

   2:                         { 

   3:                             var encoder = new PngEncoder 

   4:                             { 

   5:                                 IsWritingUncompressed = false 

   6:                             }; 

   7:                             encoder.Encode(bitmapImageInstance, writingStream); 

   8:                             // ...

   9:                         } 

Both solutions works fine. The first one does not need any kind of library reference meanwhile the second one needs ImageTools library (that could be reached in Nuget).

My life is easier since I met RestSharp library. Since then, all my Windows Phone app use such library, and excluding some issues on behalf of Newtonsoft.Json version, the truth is that RestSharp is quite helpful. Well, one of the issues I would like to talk about is concerning to the Content Types that RestSharp supports. There are 6 types of content and we may find them in AcceptTypes property of the RestClient object.

In the following example, we aim to achieve some kind of xml based data and perform some actions like xml deserialization.

   1: //endpoint: http://www.someurl.com/someResource/orWhatever

   2: private void RestSample() 

   3: {

   4:     var client = new RestClient

   5:     {

   6:         BaseUrl = "http://www.someurl.com/"

   7:     };

   8:  

   9:     var request = new RestRequest

  10:     {

  11:         Resource = string.Format("someResource/orWhatever")

  12:     };

  13:  

  14:     client.ExecuteAsync(request, (a) =>

  15:     {

  16:         var serializer = new XmlSerializer(typeof(MyFeedType));

  17:         if (a.StatusCode == HttpStatusCode.OK)

  18:         {

  19:             var document = XDocument.Parse(a.Content); //let's play

  20:         }

  21:         else

  22:         {

  23:             //something was wrong

  24:         }

  25:     });

  26: }

We assume that this endpoint provides xml content and therefore this snippet code will work correctly. The issue here is when that endpoint does not explicity address to a given content type and supports more than one content type. Let’s say this endpoint provides both “application/xml” and “application/json”. Then the code above will not work since the a.Content given from the request will contain json based content. Well, we may use JsonDeserializer class in order to turn this json string into a C# objects, however I would like to share with you the reason because it happens.

The reason comes from the RestClient’s AcceptTypes property I pointed out above. If we breakpoint client object before the call we can see the 6 content types that RestSharp providers per default.

RestClient will try the first one which is “application/json” and as the endpoint provides json then the RestClient object call  named client will retrieve json content in the RestRequest callback.

The only way I figured out in order to force explicity xml call is by removing the “application/json” content as follows:

   1: client.RemoveHandler("application/json"); 

Maybe there would be another way to achieve it, if so and you know it, drop me a comment.

El Principio de Sustitución de Likov fue acuñado por Barbara Liskov en el año 1987 durante una conferencia sobre Jerarquía y Abstraccióbn de datos. Su principal cometido es la de asegurar en la herencia entre clases de la Programación Orientada a Objetos que una clase derivada no únicamente es sino que debe comportarse como la clase base. Su definición es:

Si por cada objeto o1 del tipo S existe un objeto o2 del tipo T tal que para todos los programas P definidos en términos de T y el comportamiento de P permanece invariable cuando o1 es sustituido por o2, entonces S es un subtipo de T.

Pese a lo complejo que pueda llegar a parecer la definición en la practica lo podemos ver con algo más de claridad con el típico ejemplo del cuadrado y el rectángulo. En el siguiente snippet de código en C# se muestran las clases.

public abstract class Rectangulo
{
   public virtual int Ancho { get; set; }
   public virtual int Alto { get; set; }
   public abstract float Area();
}

public class Cuadrado : Rectangulo
{
    public override int Ancho  {
        get {
            return base.Ancho;
        }
        set {
            base.Ancho = value;
            base.Alto = value;
        }
    }
    public override int Alto  {
        get {
            return base.Alto;
        }
        set {
            base.Ancho = value;
            base.Alto = value;
        }
    }
    public override float Area()
    {
        return Ancho*Alto;
    }
}

Aparentemente a simple vista puede parecernos que la herencia es correcta, al menos desde el punto de vista técnico su implementación lo es, sin embargo el comportamiento es bien distinto. Mientras que en un Rectangulo el Ancho y el Alto pueden contener cualquier valor, un Cuadrado, por definición, el Ancho y el Alto debe ser del mismo valor, de otra forma seria no seria un cuadrado. Fijémonos en el setter de las propiedades Ancho y Alto de la clase Cuadrado; ambas se anulan entre sí. Podemos verlo más claro con un Test Unitario.

[TestFixture]
public class Test
{
    [Test]
    public void AreaRectangulo()
    {
        Rectangulo r = new Cuadrado
                            {
                                Ancho = 5,
                                Alto = 2
                            };
        Assert.AreEqual(10.0f, r.Area());
    }
}

Basicamente comprobamos que, si un objecto Cuadrado con Ancho = 5 y Alto = 2, su Area, ya que asumimos que es un Rectangulo, es Ancho * Alto, es decir igual 10. El Test falla pues el setter de Alto impone además de éste el Ancho a 2, con lo cual el Area es 4.

Diseño por Contratos

Por otro lado, Bertrand Meyer acuñó el Diseño por Contratos (DbC) en el que se especifica un contrato a nivel de método para establecer los valores/tipos aceptables de entrada y de retorno, las condiciones de valor o de tipo para los errores y excepciones que puedan ocurrir, la precondición y postcondición y la invariantes.

Para cumplir con el Principio de Substitución de Liskov, la implementación de la clase derivada debe:

• Ser menos restrictivas en la precondición.
• Ser más restrictivas en la postcondición.
• Preservar la invariancia.

En nuestro ejemplo podriamos decir que el contrato de las propiedad Ancho de Rectangulo seria:

[Precondicion(Ancho > 0)]
[Poscondicion("$after(Ancho)>0")]
[Poscondicion("$after(Alto)=$before(Alto)")]

Y el de Cuadrado:

[Precondicion(Ancho > 0)]
[Poscondicion("$after(Ancho)>0")]

En primer lugar, la propia naturaleza de la clase Cuadrado implica, precisamente para preservar la Invariancia, que la propiedad Ancho modifique, además, la propiedad Alto y esto deriva en que la postcondición de Cuadrado para el setter sea menos restrictiva que en Rectangulo y por tanto no cumpla con El Principio de Substitución de Liskov.

Conclusión

El Principio de Substitución de Liskov no dicta tanto el qué sino el cómo debe heredarse tipos. El uso de DbC está estrechamente ligado y puede ser de utilidad en herencias de tipos más complejos para preservar el comportamiento en la tipo derivado. El impacto de este principio en los nuevos lenguajes de desarrollo los podemos ver por ejemplo en el contravariancia de los argumentos de métodos para los subtipos o la covariancia para el retorno, tanto en delegados como en interfaces como es el caso de C#.

I have to recognize that I really like Lambda Expression (LE) since this feature appeared with .NET Framework 3.5 release. I actually use to apply it in a wide variety of aspects into my developments. I think that it becomes clearly useful when I have to hand some event or async call that involves just one or two statements.

However, and as often happens in these scenarios, what begins being just a single statement becomes a entire method with a bunch of statements. It arises then in something ugly, such code becomes hard to maintain. The code in question could be like this:

 1: var _watcher = new GeoCoordinateWatcher(GeoPositionAccuracy.Default)

 2: {

 3:     MovementThreshold = 20

 4: };

 5:

 6: _watcher.PositionChanged += (((s, p) =>

 7:                                     {

 8:                                         if (!p.Position.Location.IsUnknown)

 9:                                             App.ViewModel.Pushpins[0].Location =

 10:                                             p.Position.Location;

 11:                                         else

 12:                                             PerformeSomeAction();

 13:                                     }

 14:                                 ));

Which PositionChanged event initial implementation was:

 1: _watcher.PositionChanged += ((s, p) => App.ViewModel.Pushpins[0].Location =

 2:                                         p.Position.Location);

Now, let’s come across Single Responsability Principle (SRP). In my opinion SRP is one of the most relevant principles not just in OO but in other fields of software engineering thus I use to take it into consideration before starting to write code. After I wrote this code, I went back to it two weeks later and realized that the meaning of having an Lambda Expression there was no longer reasonable. The modification of this code made me spend some additional time refactoring and I decided to move it entirely to a classic method.

Beyond theory, whether it violates or not the SRP, I took a pragmatic point of view that made me realize about the requirement of turning the anonymous method into a classic method, and it was to make this method more maintainable, cointaining just one responsability, however, SRP states that a class or interface, method or package may contain two different responsibilities if, and only if, there is no coupling between them. See Uncle Bob’s Modem Interface sample. That rule did not fit into my code.

I don’t want to coin a rule about using either Lambda Expression or anonymous methods in your code regarding to the accomplishment of SRP but I would say that if you write more than one or two statements into an anonymous method or Lambda Expression it’s likely that you are violating, in some way or another, the SRP and if so then the benefits of anonymous methods or Lambda Expression  clearly have no sense.

Obviously, that was in my case and it’s my honest opinion. I’m sure you may have your own about it based on your own experience. That’s why SRP is just it, a Principle.

Artículo con copyright. Se permite su reproducción citando al autor. Publicado en dotNetMania

Este es el segundo de un total de cinco artículos sobre programación con los principio SOLID. Después de ver en profundidad el Principio de Responsabilidad Única, vamos a adentrarnos en conocer otro de los principios que además guarda una estrecha relación con el primero: el Principio Open/Closed.

Introducción

Todas las aplicaciones cambian durante su ciclo de vida y siempre vendrán nuevas versiones tras la primera release y no por ello debemos adelantarnos a desarrollar características que el cliente podría necesitar en el futuro; si nos pusiéramos en el papel de adivinos fallaríamos seguro y probablemente desarrollaríamos características que el cliente nunca necesitaría. El principio YAGNI (You aint’t gonna to need it) o “No vas a necesitarlo” utilizado en la Programación Extrema, previene de implementar nada más que lo que realmente se requiera. La idea es desarrollar ahora sobre los actuales requisitos funcionales, no sobre los que supongamos que aparecerán dentro de un mes. La actitud de adelantarnos a los acontecimientos es un mecanismo de defensa que en ocasiones acusamos los desarrolladores para prevenir lo que tarde o temprano será inevitable: la modificación.

Lo único que podemos hacer es minimizar el impacto de una modificación en nuestro sistema y para ello es imprescindible empezar con un buen diseño ya que la modificación de una clase o módulo de una aplicación mal diseñada generará unos cambios en cascada sobre las clases dependientes que derivará en unos efectos indeseables. La aplicación se convierte, así, en rígida, impredecible y no reutilizable.

Ahora bien, ¿cómo debemos plantear nuestras aplicaciones para que se mantengan estables ante cualquier modificación?

El Principio de Open/Closed

El Principio Open/Closed u Open/Closed Principle en inglés, OCP en adelante, fue acuñado por el Dr. Bertrand Meyer en el año 1988 en su libro Object Oriented Software Construction y afirma que:

Una clase debe estar abierta a extensiones pero cerrada a las modificaciones.

OCP es la respuesta a la pregunta que hacíamos anteriormente ya que argumenta que deberíamos diseñar clases que nunca cambien, y cuando un requisito lo hace debemos extender el comportamientos de dichas clases añadiendo código, no modificando el existente.

Las clases que cumplen con OCP tienen dos características:

• Son Abiertas para la extensión, es decir que la lógica o el comportamiento de la clase pueden ser extendidas en nuevas clases.
• Son Cerradas para la modificación y por tanto el código fuente de dicha clase debería permanecer inalterado.

Sin embargo, y aparentemente, parece que ambas características sean incompatibles y eso no es así. Veamos un ejemplo de clase que rompe con OCP.

Supongamos un sistema de gestión de proyectos estilo Microsoft Project. Obviemos la complejidad real que existe en dicho sistema y centrémonos únicamente en la entidad Tareas tal y como muestra la Figura 1. Dicha clase viene determinada por los estados: Pendiente, Finalizada o Cancelada representados por el enumerador TareasEstadosEnum. Además implementa dos métodos Cancelar y Finalizar que cambian, si es posible, el nuevo estado de la tarea. En la Fuente 2 podemos la implementación del método Finalizar.

Figura 1.

1:
public
void Finalizar()

2: {

3:
switch (_estadoTarea)

4: {

5:
case TareasEstadosEnum.Pendiente:

6:
//finalizamos

7:
break;

8:
case TareasEstadosEnum.Finalizada:

9:
throw
new ApplicationException(“Ya esta finalizada”);

10:
case TareasEstadosEnum.Cancelada:

11:
throw
new ApplicationException(“Imposible finalizar. Tarea cancelada”);

12:
default:

13:
throw
new ArgumentOutOfRangeException();

14: }

15: }

Fuente 2.

Un cambio típico solicitado por el cliente de la aplicación seria la agregación de un nuevo estado para controlar las tareas que se han pospuesto, con lo que la adaptación a esta modificación seria la expuesta en la Fuente 3.

   1:
						public
								void Finalizar()

   2: {

   3:
						switch (_estadoTarea)

   4:     {

   5:
						case TareasEstadosEnum.Pendiente:

   6:
						//finalizamos
							

   7:
						break;

   8:
						case TareasEstadosEnum.Finalizada:

   9:
						throw
								new ApplicationException("Ya esta finalizada");

  10:
						case TareasEstadosEnum.Cancelada:

  11:
						throw
								new ApplicationException("Imposible finalizar. Tarea cancelada");

  12:
						case TareasEstadosEnum.Pospuesta:

  13:
						throw
								new ApplicationException("Imposible finalizar. Tarea no completada");

  14:
						default:

  15:
						throw
								new ArgumentOutOfRangeException();

  16:     }

  17: }

Fuente 3.

Aparentemente parece una modificación trivial, sin embargo este cambio puede replicarse en otros métodos o clases que utilicen el enumerador TareasEstadosEnum de forma que en nuestro caso también deberíamos modificar el método Cancelar (ver Fuente 4).

   1:
						public
								void Cancelar()

   2: {

   3:
						switch (_estadoTareas)

   4:     {

   5:
						case TareasEstadosEnum.Pendiente:

   6:
						//cancelamos
							

   7:             _estadoTareas = TareasEstados.Cancelada;

   8:
						break;

   9:
						case TareasEstadosEnum.Finalizada:

  10:
						throw
								new ApplicationException("Imposible cancelar. Tarea finalizada");

  11:
						case TareasEstadosEnum.Cancelada:

  12:
						throw
								new ApplicationException("Tarea ya cancelada");

  13:
						case TareasEstadosEnum.Pospuesta:

  14:
						//cancelamos
							

  15:             _estadoTareas = TareasEstados.Cancelada;

  16:
						break;

  17:
						default:

  18:
						throw
								new ArgumentOutOfRangeException();

  19:     }

  20: }

Fuente 4.

En definitiva, por cada nuevo estado que implementemos tenemos que identificar todas las clases que lo implementan y modificarlas tanto en la clase Tareas como en las clases lógicamente involucradas violando no únicamente OCP sino también el DRY (Don’t Repeat Yourself) “No te repitas”, otro principio que pretende reducir al máximo cualquier tipo de duplicación. En este tipo de modificaciones existe una alta probabilidad de olvidar modificar algún método relacionado con el nuevo estado implementado en el enumerador TareasEstadosEnum, lo que elevaría la probabilidad de aparición de un nuevo bug.

Fundamentos de la Orientación a Objetos

La cuestión se centra en cómo minimizamos el impacto de una modificación en nuestro sistema, sin comprometer OCP, esto es, manteniendo la “simbiosis” entre las dos características del principio: abierto en extensión y cerrado en modificación.

Volvamos a la entidad Tareas del ejemplo anterior. Por lo que hemos podido ver, los métodos dependen en gran medida del estado de la tarea. Así, una tarea podrá finalizarse o cancelarse dependiendo de su estado previo, pues no podremos cancelar una tarea que haya sido finalizada. De la misma forma, introduciendo el nuevo estado TareasEstadoEnum.Pospuesta implementaríamos un nuevo método llamado Posponer. La lógica del método sería obvia: únicamente podría posponerse una tarea que estuviera en estado pendiente. En definitiva todo gira alrededor del estado de la tarea y por tanto el comportamiento de la misma dependerá del estado en que se encuentre. Una opción sería encapsular dicho estado e implementar los métodos (Finalizar, Cerrar y Posponer) mediante los cuales definimos el comportamiento y por otro lado delegamos los métodos del objeto Tarea hacia dicha clase tal y como se muestra en la Fuente 5.

   1:
						class EstadosTareas

   2: {

   3:
						public
								virtual
										void Finalizar(EstadoTareasEnum estadoTareasEnum)

   4:     {

   5:
						switch (estadoTareasEnum) {

   6:
						case EstadoTareasEnum.Pendiente:

   7:
						//finalizamos
							

   8:
						case EstadoTareasEnum.Pospuesta:

   9:
						throw
								new ApplicationException("Imposible finalizar. Tarea no completada");

  10:                 . . . .

  11:
						default:

  12:
						throw
								new ArgumentOutOfRangeException();

  13:         }

  14:     }

  15:
					

  16:
						public
								virtual
										void Cancelar(EstadoTareasEnum estadoTareasEnum)

  17:     {

  18:
						switch (estadoTareasEnum){

  19:                 . . . .

  20:
						//cancelamos
							

  21:         }

  22:     }

  23:
					

  24:
						public
								virtual
										void Posponer(EstadoTareasEnum estadoTareasEnum)

  25:     {

  26:
						switch (estadoTareasEnum){

  27:                 . . . .

  28:
						//posponemos
							

  29:         }

  30:     }

  31: }

Fuente 5.

Pese a que hayamos extraído y aislado el estado de la entidad Tareas aún no hemos resuelto el problema; de hecho ahora hemos aislado la responsabilidad a la clase EstadosTareas, sin embargo estamos algo más cerca de la solución. Estudiemos de nuevo los estados -métodos- de la clase EstadoTareas; la lógica de cada uno está escrita en todos los métodos y por tanto se repite, es decir, todos los estados -métodos- contemplan la opción de Finalizar una tarea y en base a ello actúa de una forma y otra. La operación Posponer no podrá ejecutarse si el estado de la tarea es cancelado o la operación Cancelar únicamente podrá ejecutarse si el estado es Pendiente. A través de este razonamiento hemos detectado un patrón: un mismo contrato -los métodos- y diferentes comportamientos en base un estado. Esto en OO puede ser solucionado mediante polimorfismo. (Ver Fuente 6)

   1:
						abstract
								class EstadosTareasBase

   2: {

   3:
						protected Tareas _tarea;

   4:
					

   5:
						public
								abstract
										void Finalizar();

   6:
						public
								abstract
										void Cancelar();

   7:
						public
								abstract
										void Posponer();

   8: }

   9:
					

  10:
						class EstadoTareaPendiente : EstadosTareasBase

  11: {

  12:
					

  13:
						public
								override
										void Finalizar()

  14:     {

  15:
						//finalizamos
							

  16:     }

  17:
					

  18:
						public
								override
										void Cancelar()

  19:     {

  20:
						//cancelamos
							

  21:     }

  22:
					

  23:
						public
								override
										void Posponer()

  24:     {

  25:
						//posponemos
							

  26:     }

  27: }

  28:
					

  29:
						class EstadoTareaFinalizada : EstadosTareasBase

  30: {

  31:
					

  32:
						public
								override
										void Finalizar()

  33:     {

  34:
						throw
								new ApplicationException("Tarea ya Finalizada");

  35:     }

  36:
					

  37:
						public
								override
										void Cancelar()

  38:     {

  39:
						throw
								new ApplicationException("Imposible cancelar. Tarea finalizada");

  40:     }

  41:
					

  42:
						public
								override
										void Posponer()

  43:     {

  44:
						throw
								new ApplicationException("Imposible posponer. Tarea finalizada");

  45:     }

  46: }

  47:
					

  48:
						class EstadoTareaCancelada : EstadosTareasBase

  49: {

  50:
					

  51:
						public
								override
										void Finalizar()

  52:     {

  53:
						throw
								new ApplicationException("Imposible finalizar. Tarea Cancelada");

  54:     }

  55:
					

  56:
						public
								override
										void Cancelar()

  57:     {

  58:
						throw
								new ApplicationException("Tarea ya Cancelada");

  59:     }

  60:
					

  61:
						public
								override
										void Posponer()

  62:     {

  63:
						throw
								new ApplicationException("Imposible posponer. Tarea Cancelada");

  64:     }

  65: }

  66:
					

  67:
						class EstadoTareaPospuesta : EstadosTareasBase

  68: {

  69:
						public
								override
										void Finalizar()

  70:     {

  71:
						throw
								new ApplicationException("Imposible posponer. Tarea finalizada");

  72:     }

  73:
					

  74:
						public
								override
										void Cancelar()

  75:     {

  76:
						//cancelamos
							

  77:     }

  78:
					

  79:
						public
								override
										void Posponer()

  80:     {

  81:
						throw
								new ApplicationException("Tarea ya Pospuesta");

  82:     }

  83: }

  84:
					

  85:
						class Tareas

  86: {

  87:
						private EstadosTareasBase _estadosTareas;

  88:
					

  89:
						public Tareas()

  90:     {

  91:         _estadosTareas = new EstadoTareaPendiente();

  92:     }

  93:
					

  94:
						public
								void Finalizar()

  95:     {

  96:         _estadosTareas.Finalizar();

  97:     }

  98:
					

  99:
						public
								void Cancelar()

 100:     {

 101:         _estadosTareas.Cancelar();

 102:     }

 103:
					

 104:
						public
								void Posponer()

 105:     {

 106:         _estadosTareas.Posponer();

 107:     }

 108: }

Fuente 6.

Básicamente lo que hemos hecho es crear una clase por cada estado en lugar de tener una única clase cuyos métodos están basados en sentencias condicionadas por el estado de la tarea (con Switch o if). Además, con esta nueva implementación hemos delegado la responsabilidad de Finalizar, Cancelar o Posponer a una nueva clase EstadosTareasBase y la hemos marcado como abstracta. La clase Tareas implementará sus propios métodos y delegará la responsabilidad a través de las clases estados que implementan EstadosTareasBase. Debido a que la clase Tarea gira en torno a un estado, asumimos que el estado inicial por defecto es Pendiente y así lo especificamos en el constructor instanciando EstadoTareaPendiente.

En realidad, hemos aplicado un patrón ya conocido, el patrón de diseño State, ya que el comportamiento de la clase cambia dependiendo del estado -en este caso de la tarea- y por lo tanto hemos abstraído cada una de los estados como entidades independientes. Ante un nuevo requisito en la que intervenga un nuevo estado, lo único que deberemos hacer es crear una nueva clase que herede de EstadosTareasBase e implementar las acciones, extendiendo el comportamiento de la aplicación si comprometer el código existente.

Conclusión

Cuando hablamos del Principio de Responsabilidad Única, argumentamos la importancia de que cada clase tuviera una y solo una responsabilidad dentro del sistema, de forma que cuanto menos impacto tenga una clase en el conjunto global del sistema, menos repercusión global tendrá una modificación en dicho sistema y este mismo argumento es la línea que pretende seguir el Principio Open/Closed. La clave para la correcta aplicación de este principio es la abstracción y el polimorfismo, como hemos podido ver en el ejemplo. Pese a que conceptualmente es relativamente sencillo de comprender, no sucede lo mismo cuando se aplica.

Para los que no la conozcáis, SoapUI es una herramienta que se utiliza típicamente para el test de servicios Web y brilla por su alta versatilidad en cualquier tipo de plataforma y protocolos. Desarrollada en Java y OpenSource (aunque tiene una versión Pro de paganini), la utilizo para el test de comportamiento y de carga dado un WSDL.

En este post pretendo mostrar un par de “errores” típicos de SoapUI cuando testeamos un servicio WCF, en mi caso WCF 4.0.

“The message could not be processed” con wsHttpBinding

El primer error da como resultado de hacer un Request al método expuesto Method del servicio IService y es el siguiente:

   1: <s:Envelope xmlns:s="http://www.w3.org/2003/05/soap-envelope" xmlns:a="http://www.w3.org/2005/08/addressing">

   2:    <s:Header>

   3:       <a:Action s:mustUnderstand="1">http://www.w3.org/2005/08/addressing/soap/fault</a:Action>

   4:    </s:Header>

   5:    <s:Body>

   6:       <s:Fault>

   7:          <s:Code>

   8:             <s:Value>s:Sender</s:Value>

   9:             <s:Subcode>

  10:                <s:Value xmlns:a="http://schemas.xmlsoap.org/ws/2005/02/sc">a:BadContextToken</s:Value>

  11:             </s:Subcode>

  12:          </s:Code>

  13:          <s:Reason>

  14:             <s:Text xml:lang="es-ES">The message could not be processed. This is most likely because the action 

  15: 'http://tempuri.org/IService/Method' is incorrect or because the message contains an invalid or 

  16: expired security context token or because there is a mismatch between bindings. The security context token would 

  17: be invalid if the service aborted the channel due to inactivity. To prevent the service from aborting idle sessions 

  18: prematurely increase the Receive timeout on the service endpoint's binding.</s:Text>

  19:          </s:Reason>

  20:       </s:Fault>

  21:    </s:Body>

  22: </s:Envelope>

   1: <bindings>

   2:   <wsHttpBinding>

   3:     <binding name="wsHttpBindingConfig">

   4:       <security mode="None">

   5:         <transport clientCredentialType="None" />

   6:         <message establishSecurityContext="false" />

   7:       </security>

   8:     </binding>

   9:   </wsHttpBinding>

  10: </bindings>

Consideraciones con el WS-Addressing

Otro de los quebraderos de cabeza es si tenemos habilitado el WS-Addressing. En este caso el header del mensaje únicamente contiene el valor de Action (no el To)con lo que al ejecutar el Request desde SoapUI nos encontramos con el siguiente error.

   1: <s:Envelope xmlns:s="http://www.w3.org/2003/05/soap-envelope" xmlns:a="http://www.w3.org/2005/08/addressing">

   2:    <s:Header>

   3:       <a:Action s:mustUnderstand="1">http://www.w3.org/2005/08/addressing/soap/fault</a:Action>

   4:    </s:Header>

   5:    <s:Body>

   6:       <s:Fault>

   7:          <s:Code>

   8:             <s:Value>s:Sender</s:Value>

   9:             <s:Subcode>

  10:                <s:Value>a:DestinationUnreachable</s:Value>

  11:             </s:Subcode>

  12:          </s:Code>

  13:          <s:Reason>

  14:             <s:Text xml:lang="es-ES">The message with To '' cannot be processed at the receiver, due to 

  15: an AddressFilter mismatch at the EndpointDispatcher.  Check that the sender and receiver's EndpointAddresses agree.</s:Text>

  16:          </s:Reason>

  17:       </s:Fault>

  18:    </s:Body>

  19: </s:Envelope>

Si nos dirigimos al apartado de WS-A Setting desde el “Request 1” en cuestión se desplegará las diferentes opciones habilitadas. Una de ellas está desactivada por defecto y es precisamente la que hace referencia a wsa:to, podemos seleccionar “Add default wsa:to” (como he hecho yo en este ejemplo) mediante el check correspondiente o bien podemos añadir directamente la dirección del servicio hospedado.

Espero que sea de utilidad.

Autores: Hadi Hariri, José Miguel Torres
Artículo con copyright. Se permite su reproducción citando al auto. Publicado en dotNetMania

Entradilla

El Principio de Responsabilidad Única pretende ser el primero de un total de cinco artículos que responden a las siglas de S.O.L.I.D. y que descubren cinco principios fundamentales en el paradigma de la Programación Orientado a Objetos.

Introducción

Fue en los preparativos del Code Camp de Tarragona cuando Hadi propuso una sesión acerca de programación SOLID y pese a que en mayor o menor medida muchos de nosotros hemos sentido hablar de, sino todos, la mayoría de estos principios nunca los había visto –al menos yo- bajo dichas siglas.

Y es que la comprensión de dichos principios nos permitirá mejorar la percepción del no siempre fácil campo de la programación orientada a objetos y evitar así las malas prácticas que la flexibilidad de esta metodología otorga a través de los lenguajes que la soportan. Las herramientas de desarrollo rápido (Rapid ApplicationDevelopment –RAD-), como Visual Studio, ofrecen al desarrollador un conjunto de funcionalidades que aumentan, ya sea a través de asistentes o Drag’n'Drop, la productividad en el desarrollo de aplicaciones y permiten focalizarse únicamente en el desarrollo de las propiedades o eventos específicos sin tener que preocuparse, en muchas ocasiones, del código generado “por debajo”.

Sin embargo acabamos pagando un precio en ocasiones muy elevado ya que estas herramientas dejan cajas negras lógicas de código tras de sí y cualquier modificación o reutilización de un componente se traduce en un elevado coste de desarrollo ya que los conceptos clave de la Orientación a Objetos son sacrificados por la productividad, y hablar de productividad es hablar del mantenimiento y calidad del software con lo que dicho sacrificio, sencillamente, no tiene o debería tener cabida.

Cohesión

Para tratar de comprender el término de nivel de cohesión vamos a utilizar el ejemplo del teléfono móvil. Como todos sabéis, un dispositivo móvil está compuesto de una serie de componentes tales como la pantalla, el teclado, la radio GPRS/3G, el módulo Bluetooth, etc. Todos estos componentes 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étera 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 la de otros componentes ni ninguna función básica que no quede descubierta por un determinado componente. A la hora de buscar un nuevo móvil miraremos las características y especificaciones técnicas del dispositivo y además de contemplar las especificaciones que deseamos también esperamos que los componentes sean de alta calidad; no es viable que un móvil esté compuesto con 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 tenga 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 responsabilidad dentro del sistema. Pensemos pues en el nivel de cohesión de una aplicación no como una suma de los componentes sino como el conjunto de los mismo.

Acoplamiento

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 los fabricantes que optan por adaptadores de corriente estándar en lugar de crear adaptadores propietarios que casi siempre acaban tirados en el contenedor de reciclaje cuando sustituimos el móvil. Se entiende que se opta por la universalidad de los dispositivos de corriente para su reaprovechamiento en otros dispositivos, incluso de diferentes fabricantes. En la ingeniería del software, el acoplamiento entre módulo, clases o cualquier otro tipo de entidad lógica es el grado de dependencia entre ellos. Cuán más estándar sea la relación de una entidad lógica con otras mayor reaprovechamiento podremos hace de ella.

Encapsulación

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

Aplicaciones SOLIDas

Siguiendo el modelo del teléfono móvil y siguiendo la idea subyacente de estos tres aspectos afirmamos que mi teléfono ideal sería aquél que estuviera compuesto por los mejores componentes del mercado, aquél cuyas interfaces de conexión para la sincronización de datos y recarga de la batería fuera estándar y aquél cuyas funcionalidades conozca en profundidad sin la necesidad de tener que consultar la documentación técnica para saber cómo ha sido diseñado y así poder sacar el máximo provecho.

Extrapolando este ejemplo a nuestro mundo, el mundo del software, tenemos que tener siempre presente estos tres aspectos fundamentales desde el mismo momento que empezamos con un diseño de una nueva aplicación y es ahí donde entran a escena los cinco principios descritos por el acrónimo mnemotécnico SOLID y presentados a principio de esta década por Robert C. Martin. (Ver Figura 1)

Figura 1. Los cinco principios SOLID

Los principios SOLID pretenden ser una guía a seguir durante la fase de desarrollo para facilitar el mantenimiento de aplicaciones y tratar de eliminar el impacto de las inevitables modificaciones que sufren durante el ciclo de vida de la aplicación además de facilitar el uso de las unidades de testeo, entre las más destacadas.

Principio de Responsabilidad Única

El Principio de Responsabilidad Única o Single Responsability Principle en inglés (SRP en adelante), fue acuñado por Robert C. Martin a través de un artículo del mismo título y popularizado a través de su libro Agile Software Development: Principles, Patterns, and Practices. SRP está basado en el Principio de Cohesión y describe el nivel de acoplamiento ordinal entre módulos dentro de la ingeniería del Software.

En términos prácticos, Robert C. Martin declara a través de SRP que:

Una clase debe tener una y sólo una única causa por la cual puede ser modificada

Si una clase tiene dos responsabilidades entonces asume dos motivos por los cuales puede ser modificada. Por ejemplo, supongamos una clase llamada Factura, la cual dentro de un contexto determinado ofrecerá un método para calcular el total de una factura tal y como muestra la Figura 2.

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 responsabilidad es “un motivo de cambio”, sin embargo es difícil de ver ya que estamos acostumbrados a pensar un conjunto de operaciones como una sola responsabilidad.

Si implementamos la clase Factura tal y como muestra la Fuente 1 podríamos decir que la responsabilidad de esta clase es la de calcular el total de la factura -y efectivamente cumple con su cometido-, sin embargo no es cierto que contenga una única responsabilidad. Si nos fijamos detenidamente en la implementación del método CalcularTotal() podemos 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 de impuestos. 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 deberíamos modificar la clase Factura por cada una de las razones y por lo tanto las responsabilidades quedan acopladas entre sí y disminuye la cohesión. La clase Factura pues violaría el principio SRP.

public
class Factura

{

public
string _codigo;

public
DateTime _fechaEmision;

public
decimal _importeFactura;

public
decimal _importeIVA;

public
decimal _importeDeducir;

public
decimal _importeTotal;

public
ushort _porcentageDeduccion;

//método que calcula el Total de la factura

public
void CalcularTotal()

{

//Calculamos la deducción

_importeDeducir = (_importeFactura*_porcentageDeduccion)/100;

//Calculamos el IVA

_importeIVA = _importeFactura * 0.16m;

//calculamos el total

_importeTotal = (_importeFactura – _importeDeducir) + _importeIVA;

}

}

Fuente 1. Clase Factura.

Separando responsabilidades

El primer paso para solucionarlo es separar las responsabilidades y para separarlas primero hay que identificarlas.

Enumeremos de nuevos los pasos que realiza el método CalculaTotal():

• Aplica una deducción. En base a la base imponible se calcula un descuento porcentual.
• 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 responsabilidades. Recordamos, una responsabilidad no es una acción, es un motivo de cambio y por lo tanto deberían extraer las responsabilidades de deducción e impuestos en dos clases específicas para ambas operaciones estableciendo por un lado la clase IVA y por otro la clase Deduccion tal y como muestra la Fuente 2.

public
class IVA

{

public
readonly
decimal _iva = 0.16m;

public
decimal CalcularIVA(decimal importe)

{

return importe*_iva;

}

}

public
class Deduccion

{

public
readonly
decimal _deduccion;

public Deduccion(ushort porcentage)

{

_deduccion = porcentage;

}

public
decimal CalcularDeduccion(decimal importe)

{

return (importe*_deduccion)/100;

}

}

Fuente 2.

Ambas clases contienen datos y un método y se responsabilizan únicamente en calcular el IVA y la deducción de un importe, es decir existe una encapsulación pese a lo trivial del ejemplo. Además, con esta separación obtenemos una mayor cohesión y un menor acoplamiento al aumentar la granularidad de la solución.

Las ventajas de la correcta aplicación del SRP simplifica el código y se traduce en facilidad en el mantenimiento, permite la reutilización de clases y nos permite crear unidades de testeo específicas orientadas a dicha clase/responsabilidad.

public
class Factura

{

public
string _codigo;

public
DateTime _fechaEmision;

public
decimal _importeFactura;

public
decimal _importeIVA;

public
decimal _importeDeducir;

public
decimal _importeTotal;

public
ushort _porcentageDeduccion;

public
void CalcularTotal()

{

//calculamos el IVA

IVA iva = new IVA();

_importeIVA = iva.CalcularIVA(_importeFactura);

//calculamos la deducción a aplicar

Deduccion deduccion = new Deduccion(_porcentageDeduccion);

_importeDeducir = deduccion.CalcularDeduccion(_importeFactura);

//calculamos el total

_importeTotal = (_importeFactura – _importeDeducir) + _importeIVA;

}

}

Fuente 3. Clase Factura definitiva.

Ampliando el abanico de “responsabilidades”

Comentábamos anteriormente que no es fácil detectar las responsabilidades ya que siempre tendemos a agruparlas, sin embargo existen escenarios o casuísticas en las que “se permite” cierta flexibilidad. Robert C. Martin expone un ejemplo a través de la interfaz Modem (Fuente 3).

interface Modem
{
void dial(int pNumber);
void hangup();
void send(char[] data);
char[] receive();
}

Fuente 3.

En este ejemplo se detectan dos responsabilidades, las relacionadas con la gestión de la comunicación (dial y hangup) y la comunicación de datos (send y receive). Efectivamente cada una de las funciones pueden cambiar por diferentes motivos pero sin embargo ambas funciones se llamaran desde distintos puntos de la aplicación y no existe una dependencia entre ellas con lo que no perderíamos la cohesión del sistema.

Conclusión

Pensemos en el ciclo de vida de una aplicación, no únicamente en su diseño y desarrollo. La aplicación sufre modificaciones a causa de los cambios de requisitos o arreglo de fallos existentes, el equipo de desarrollo puede variar y si a ello le sumamos que el código es poco mantenible los costes de mantenimiento se disparan y cualquier modificación se presenta como un causa potencial de errores en entidades relacionadas dentro del sistema.