Implementando SOLID - OCP

Ahora vamos con el segundo principio, conocido como open/closed o abierto/cerrado. Que dice que una clase tiene que ser abierta para extensión y cerrada para modificación.

Esta es la solución de Nelo: http://nelopauselli.blogspot.com.ar/2012/07/implementando-solidocp.html
y la de Martín: http://blog.martincoll.com.ar/refactorizando-para-cumplir-con-ocp/

A veces, cuando miramos / escribimos código, lo hacemos mirando dentro del método. Pero que pasa si esta vez nos paramos fuera del método, del lado de quien usa el código? El amigo Carlos Peix escribió un muy buen post al respecto.

	[TestFixture]
	class FilterTest
	{
	[Test]
	public void filterByBlue_return_2()
	{
	// arrange
	ProductFilter filter = new ProductFilter();
	IList<Product> products = BuildProducts();
	// act
	var result = filter.ByColor(products, ProductColor.Blue);
	// assert
	Assert.That(result.Count(), Is.EqualTo(2));
	Assert.That(result, Has.All.Matches<Product>(x => x.Color == ProductColor.Blue));
	}
	[Test]
	public void filterBySmall_return_2()
	{
	// arrange
	ProductFilter filter = new ProductFilter();
	IList<Product> products = BuildProducts();
	// act
	var result = filter.BySize(products, ProductSize.Small);
	// assert
	Assert.That(result.Count(), Is.EqualTo(2));
	Assert.That(result, Has.All.Matches<Product>(x => x.Size == ProductSize.Small));
	}
	[Test]
	public void filterByBlueAndSmall_return_1()
	{
	// arrange
	ProductFilter filter = new ProductFilter();
	IList<Product> products = BuildProducts();
	// act
	var result = filter.ByColorAndSize(products, ProductColor.Blue, ProductSize.Small);
	// assert
	Assert.That(result.Count(), Is.EqualTo(1));
	Assert.That(result, Has.All.Matches<Product>(x => x.Size == ProductSize.Small));
	}
	private IList<Product> BuildProducts()
	{
	return new List<Product> {
	new Product(ProductColor.Blue, ProductSize.Small),
	new Product(ProductColor.Yellow, ProductSize.Small),
	new Product(ProductColor.Yellow, ProductSize.Medium),
	new Product(ProductColor.Red, ProductSize.Large),
	new Product(ProductColor.Blue, ProductSize.ReallyBig)
	};
	}
	}

view raw FilterTest.cs hosted with ❤ by GitHub

En este caso vemos que se trata de un filtro que permite:

• filtrar por color
• filtrar por talle
• filtrar por color y talle

Si tuviese que agregar otro criterio p/filtrar, entonces tengo que agregar un nuevo método, lo que implica modificar la clase y por lo tanto no cumple con ser cerrada para modificación.

Para agregar criterios sin tener que modificar la clase existente, una posible solución es tener una clase por criterio (especificación). En este caso estamos dando a la clase una única razón para cambiar y aplicando también el principio de responsabilidad única.

	[TestFixture]
	class FilterTest
	{
	[Test]
	public void filterByBlue_return_2()
	{
	// arrange
	ProductFilter filter = new ProductFilter();
	IList<Product> products = BuildProducts();
	// act
	var result = filter.By(products, new FilterSpecificationColor(ProductColor.Blue));
	// assert
	Assert.That(result.Count(), Is.EqualTo(2));
	Assert.That(result, Has.All.Matches<Product>(x => x.Color == ProductColor.Blue));
	}
	[Test]
	public void filterBySmall_return_2()
	{
	// arrange
	ProductFilter filter = new ProductFilter();
	IList<Product> products = BuildProducts();
	// act
	var result = filter.By(products, new FilterSpecificationSize(ProductSize.Small));
	// assert
	Assert.That(result.Count(), Is.EqualTo(2));
	Assert.That(result, Has.All.Matches<Product>(x => x.Size == ProductSize.Small));
	}
	[Test]
	public void filterByBlueAndSmall_return_1()
	{
	// arrange
	ProductFilter filter = new ProductFilter();
	IList<Product> products = BuildProducts();
	// act
	var result = filter.By(products, new FilterSpecificationColorAndSize(ProductColor.Blue, ProductSize.Small));
	// assert
	Assert.That(result.Count(), Is.EqualTo(1));
	Assert.That(result, Has.All.Matches<Product>(x => x.Size == ProductSize.Small));
	}
	private IList<Product> BuildProducts()
	{
	return new List<Product> {
	new Product(ProductColor.Blue, ProductSize.Small),
	new Product(ProductColor.Yellow, ProductSize.Small),
	new Product(ProductColor.Yellow, ProductSize.Medium),
	new Product(ProductColor.Red, ProductSize.Large),
	new Product(ProductColor.Blue, ProductSize.ReallyBig)
	};
	}
	}

view raw FilterTest.cs hosted with ❤ by GitHub

Ahora, para agregar un criterio (extender), no es necesario modificar las clases existentes.

Se dice que la decisión qué parte es fija (dura de cambiar) y cual es móvil (fácil de cambiar / extender) en una aplicación es una decisión estratégica. No puedo hacer todo open / closed, ya que con eso pago un costo de complejidad. La parte que me conviene encapsular p/hacer movil es la que varía.

Implementando SOLID - SRP

Como parte del taller de principios solid que hicimos con los amigos de Kleer, junto con Nelo y Juan nos propusimos explicar paso por paso como implementamos los principios tomando los ejemplos de http://solidexamples.codeplex.com/

Así que vamos a empezar por el principio de responsabilidad única (single responsability / SRP), que nos dice que una clase debe tener una única razón para cambiar.

Esta es la resolución de Nelo: http://nelopauselli.blogspot.com.ar/2012/07/implementado-solid-srp.html
la de Martín Coll: http://blog.martincoll.com.ar/refactorizando-para-cumplir-con-srp/
la de Juan Tripode: http://altaprogramacion.blogspot.com.ar/2012/08/srp-single-responsibility-principle.html

El ejemplo trata de una aplicación winform que permite abrir un xml de productos y mostrarlos en una grilla. En este se programa todo "atrás del botón"

	private void btnLoad_Click(object sender, EventArgs e)
	{
	listView1.Items.Clear();
	var fileName = txtFileName.Text;
	using (var fs = new FileStream(fileName, FileMode.Open))
	{
	var reader = XmlReader.Create(fs);
	while (reader.Read())
	{
	if (reader.Name != "product") continue;
	var id = reader.GetAttribute("id");
	var name = reader.GetAttribute("name");
	var unitPrice = reader.GetAttribute("unitPrice");
	var discontinued = reader.GetAttribute("discontinued");
	var item = new ListViewItem(new string[] { id, name, unitPrice, discontinued });
	listView1.Items.Add(item);
	}
	}
	}

view raw form.cs hosted with ❤ by GitHub

El formulario es responsable de la persistencia, de recuperar la información (de un archivo) y de conocer el formato (xml). El primer paso que proponemos es encapsular esto en un repositorio, por lo que nos quedaría algo así:

	private void btnLoad_Click(object sender, EventArgs e)
	{
	listView1.Items.Clear();
	var fileName = txtFileName.Text;
	foreach (Product product in productRepository.GetByFileName(fileName))
	{
	var item = new ListViewItem(new[] {
	product.Id.ToString(),
	product.Name,
	product.UnitPrice.ToString(),
	product.Discontinued.ToString()
	});
	listView1.Items.Add(item);
	}
	}

view raw form.cs hosted with ❤ by GitHub

	class ProductRepository : IProductRepository
	{
	public IEnumerable<Product> GetByFileName(string fileName)
	{
	var products = new List<Product>();
	using (var fs = new FileStream(fileName, FileMode.Open))
	{
	var reader = XmlReader.Create(fs);
	while (reader.Read())
	{
	if (reader.Name != "product") continue;
	var product = new Product();
	product.Id = int.Parse(reader.GetAttribute("id"));
	product.Name = reader.GetAttribute("name");
	product.UnitPrice = decimal.Parse(reader.GetAttribute("unitPrice"));
	product.Discontinued = bool.Parse(reader.GetAttribute("discontinued"));
	products.Add(product);
	}
	}
	return products;
	}
	}

view raw ProductRepository.cs hosted with ❤ by GitHub

Ahora el repositorio es responsable de recuperar datos, abrir el archivo y convertir de xml a objetos. Vamos a quitarle la responsabilidad de abrir el archivo:

	class FileLoader : IFileLoader
	{
	public Stream Load(string fileName)
	{
	return new FileStream(fileName, FileMode.Open);
	}
	}

view raw FileLoader.cs hosted with ❤ by GitHub

	class ProductRepository : IProductRepository
	{
	private readonly IFileLoader loader;
	public ProductRepository()
	{
	loader = new FileLoader();
	}
	public IEnumerable<Product> GetByFileName(string fileName)
	{
	var products = new List<Product>();
	using (Stream input = loader.Load(fileName))
	{
	var reader = XmlReader.Create(input);
	while (reader.Read())
	{
	if (reader.Name != "product") continue;
	var product = new Product();
	product.Id = int.Parse(reader.GetAttribute("id"));
	product.Name = reader.GetAttribute("name");
	product.UnitPrice = decimal.Parse(reader.GetAttribute("unitPrice"));
	product.Discontinued = bool.Parse(reader.GetAttribute("discontinued"));
	products.Add(product);
	}
	}
	return products;
	}
	}

view raw ProductRepository.cs hosted with ❤ by GitHub

Y la responsabilidad de convertir xml a objetos:

	class ProductRepository : IProductRepository
	{
	private readonly IFileLoader loader;
	private readonly IProductsMapper mapper;
	public ProductRepository()
	{
	loader = new FileLoader();
	mapper = new ProductsMapper();
	}
	public IEnumerable<Product> GetByFileName(string fileName)
	{
	IEnumerable<Product> products;
	using (Stream file = loader.Load(fileName)) {
	products = mapper.Map(file);
	}
	return products;
	}
	}

view raw ProductRepository.cs hosted with ❤ by GitHub

	class ProductsMapper : IProductsMapper
	{
	private Product MapItem(XmlReader reader)
	{
	if (reader.Name != "product") throw new InvalidOperationException("XML reader is not on a product fragment.");
	var product = new Product();
	product.Id = int.Parse(reader.GetAttribute("id"));
	product.Name = reader.GetAttribute("name");
	product.UnitPrice = decimal.Parse(reader.GetAttribute("unitPrice"), CultureInfo.InvariantCulture);
	product.Discontinued = bool.Parse(reader.GetAttribute("discontinued"));
	return product;
	}
	public IEnumerable<Product> Map(Stream stream)
	{
	if (stream == null) throw new ArgumentNullException("Stream used when mapping cannot be null.");
	var reader = XmlReader.Create(stream);
	var products = new List<Product>();
	while (reader.Read())
	{
	if (reader.Name != "product") continue;
	var product = MapItem(reader);
	products.Add(product);
	}
	return products;
	}
	}

view raw ProductsMapper.cs hosted with ❤ by GitHub

Ahora el repositorio tiene otra responsabilidad, la de conocer sus dependencias. Pero esto es otro principio. saludos!

Compartiendo lo aprendido en SOLID

Ya les conté sobre el taller de SOLID aprendiendo y compartiendo. Esta vez quiero contarles sobre algunas cosas que probamos y me resultaron interesantes desde el punto de vista del aprendizaje. Dado que participé del taller, también me toca devolver lo que aprendí.

Sobre los primeros minutos antes de empezar

En general, cuando empezamos una actividad, las personas no llegan todas al mismo horario. A veces proponemos alguna actividad para que vayan empezando a hacer algo. Esta vez se nos ocurrió pegar 3 preguntas en distintas paredes:

• Porqué es importante aprender principios de diseño?
• A quién puede interesarle?
• Cómo podemos enseñarlo?

Le dimos la bienvenida a los primeros 2 participantes, les propusimos que elijan una pregunta y se pongan a conversar sobre la misma (podían hacer anotaciones en el afiche). Y una cosa más, tenían que darle la bienvenida a otra persona de la misma manera.

Esto de que los participantes se den la bienvenida entre si fue algo muy bueno, desdé que ponían un pie en el taller ya se estaban conectando entre ellos y con el tema.

Sobre la conexión

Por cada tema hicimos actividades de conexión. La primera fue conversar de a pares haciendo 3 preguntas:

• Nombre
• Qué te gusta hacer?
• Qué te gustaría aprender?

Luego, cada uno tenía que presentarse como si fuese su compañero. Esta es una actividad que en la retrospectiva final nos dijeron estuvo buena. Creó un buen ambiente para enseñar y aprender.

Sobre el concepto

Para aprender los principios de diseño nos dividimos en grupos donde teníamos que leer un material del tema y hacer una presentación a los demás. Además, por cada tema teníamos anotado en un afiche preguntas disparadoras que nos cuestionaban lo que leímos.


Lo bueno de esto es que el concepto se construye a partir del aporte de todos. Al final de cada presentación se hacían preguntas que a veces respondían los presentadores, pero a veces otras personas. Dado que aprendemos de distintas maneras, es útil poder escuchar distintas miradas de un tema, contadas por distintas personas y dar mi mirada también.

El primer día cada grupo presentó distintos materiales del mismo tema. Pero el segundo día hicimos algo más desafiante, cada grupo presentó temas distintos. Nos pasó que una presentación no les dejó claro el principio a todos. Lo interesante fue que entre ellos empezaron a hacer preguntar, a responderse y describieron el principio que estábamos tratando de una manera muy clara. La presentación no tiene que ser perfecta y se completa con el aporte de los demás.

Sobre la práctica

Hicimos prácticas de casi todos los principios. La práctica es fundamental, porque es ahi donde nos encontramos con las dudas. El concepto que aprendimos es el mapa y la práctica el terreno. Tenemos que recorrer el terreno para para ajustar el nuevo mapa.

Acá Carlos hizo un muy buen aporte, sugiriendo pasos de refactor muy chicos, baby steps. La práctica la hacíamos en grupo y una cosa interesante es que valía copiarse. Entonces veíamos no solo nuestra solución, sino también la de los demás.

Sobre la conclusión

En general la conclusión la hacíamos a partir de la conexión. Por ej. si arrancamos escribiendo que me gustaría aprender en un post it, al final del día cada uno tenía que revisar lo que había puesto y si sentía que había avanzado un paso en eso que escribió, entonces sacaba el post it y nos contaba cual había sido ese paso.

Sobre facilitar de a dos

Esto de facilitar un espacio de aprendizaje es para mi un desafío. Algo que empiezo sin saber como va a terminar. Cuando me toca hacerlo con otra persona, en este caso Carlos, me doy cuenta que la paso mejor y el resultado es mejor también. Además, aprendo de la otra persona.

Sobre pagar enseñando a otros

Esto creo que es lo más interesante. Primero porque para mi es algo nuevo hacer algo así en el mundo del software, un experimento, algo que me da curiosidad saber que puede salir. En la retrospectiva final los participantes nos dijeron que la idea les resultó novedosa también y que desde el punto de vista del aprendizaje los lleva a seguir aprendiendo.

Es interesante porque nos hace desafiarnos. Puede ser algo tan gran o tan chico como quisiéramos, cada uno elije el desafío a su medida. Y porque sin querer, tiene un efecto multiplicativo. Lo que se aprende sale de las paredes del taller.

Sobre preparar la devolución a la comunidad en el mismo taller

En la última hora nos dedicamos a decir que íbamos a hacer cada uno para devolver lo que aprendimos a la comunidad y armar un pequeño entregable de la actividad. Por ej. si dijimos de hacer un post, entonces elaborábamos el título y cómo íbamos a presentar el tema. Algunos decidieron hacer cosas solos, otros se juntaron en grupo.

Aca seguimos aprendiendo. Cuando tenemos que pensar cómo vamos a usar el nuevo conocimiento, eso nos lleva a seguir descubriendo. No es lo mismo aprender un nro de memoria porque sí, que aprenderlo porque es la clave secreta de algo. La diferencia está en la motivación. Darle un propósito a lo que aprendemos mejora el aprendizaje también.

Creo que si me voy del taller con al menos un borrador de una idea y si además conversé de esa idea con otras personas, entonces tengo muchas más chances de hacer algo que si me voy a mi casa sin pensar nada. Además, las grandes ideas se generan por colisión de corazonadas.

Sobre las gracias

Finalmente, tengo que agradecer a la gente de Kleer por la colaboración para llevar este experimento adelante. Y Carlos con quien estuvimos facilitando este espacio, un gusto trabajar con él. Personalmente cada vez valoro más trabajar con buenos compañeros, de esos con quienes comerías un asado también.