Ir al contenido principal

Entradas

Mostrando las entradas etiquetadas como Ley de Demeter

Programación asíncrona con async/await en .Net

Introducción A partir de la versión 4.5 de .Net framework se ha simplificado de forma considerable la forma en que podemos trabajar con código asíncrono. Con los anteriores frameworks, si queríamos contar con los beneficios de una programación asíncrona nos veíamos obligados a lidiar con una gran complejidad en nuestro código. Esto nos hacía evitar su uso en lo posible a pesar de perder esta importante característica. Stephen Cleary , un MVP especializado en concurrencia define la programación asíncrona como: Una forma de concurrencia que utiliza futuros o "callbacks" para evitar hilos innecesarios. La programación moderna con async y await nos abstrae de la utilización de "callbacks" y nos permite utilizar futuros (Tasks) que se encargarán de notificar al llamante cuando el método asíncrono se complete. async y await Las palabras async y await son las palabras clave que .Net ha introducido en el lenguaje para que podamos implementar métodos asíncronos co...

Interfaces fluidas

Introducción Martin Fowler definió la técnica Interfaz fluida (Fluent Interface) como un estilo para construir interfaces (APIs) orientadas a objetos que nos permite escribir un código fácilmente leíble . A continuación, mostraré como se implementa esta técnica con el encadenamiento de métodos (Method Chaining) . Después ampliaré el post para ver esta misma técnica con métodos que aceptan como parámetros a delegados ( Actions o Functions ), dando una mayor flexibilidad y expresividad a esta técnica. Son muchos los frameworks que implementan esta técnica y muchos de ellos empleando delegados. Muchos de ellos los utilizamos a diario como consumidores y poco a poco nos hemos acostumbrado a ellos. Ahora veremos como implementarlos nosotros mismos para nuestras propias interfaces. Suelen emplearse para realizar acciones secuenciales sobre un mismo objeto. Tal es el caso de las parametrizaciones y transformaciones de los objetos complejos. Encadenamiento de métodos Esta técnica ...

Composición o herencia: Ser o tener

Introducción El diseño de una solución software basado en objetos requiere que los objetos se relacionen entre sí. Cuando una clase necesita utilizar el código de otra clase necesitamos relacionar estas dos clases. Esta relación la podemos establecer de varias formas y dos de las más importantes en POO son: heredando de una clase base: el objeto adquiere todas las propiedades y comportamientos del objeto base; por composición: conteniendo instancias de otros objetos que implementen esa funcionalidad. Un principio de diseño en POO dice que ante la posibilidad de resolver un problema con cualquiera de estas dos soluciones deberíamos "favorecer" la composición sobre la herencia . Hay que remarcar que la palabra "favorecer" sólo significa eso: "favorecer". No se trata de una imposición. Más bien es una recomendación cuando ambas posibilidades son aplicables. Existen muchos escenarios en los que nos encontraremos en que las dos soluciones son fácilmente ...