Ver por etiquetas

Todas las etiquetas » Languages » Arquitectura » Patterns (RSS)
@Ayende ha comenzado una serie de post en lo que revisa algunos patrones de diseño (Go4) luego de transcurridos más de 18 años desde su formalización en el libro Design Patterns: Elements of Reusable Object-Oriented Software .  Inspirado por esa serie, y por el hecho de que en mi última entrevista laboral me preguntaron sobre esto,  voy a presentar una revisión sobre el patrón visitor.   Visitor en su forma clásica La motivación detrás de este patrón es poder añadir funcionalidad a...
Pensaba acerca de las cosas que podríamos hacer si el compilador de C# fuese un assembly reutilizable (Compilar as a service). Lo primero, y menos original, que se me ocurrió es que podríamos tener algo como JSON pero para C# en lugar de Java Script. 1: class Program 2: { 3: static void Main( string [] args) 4: { 5: const string data = @"results[" "professional" "] = 6: new 7: { 8: FirstName = " "Juan Pablo" ", 9: LastName = " "Ibañez" "...
Desarrollo un sistema para la planificación, ejecución y seguimiento de encuestas en el que uno de los requerimientos es poder crear encuestas de manera sencilla y veloz. Además las mismas deben seguir un workflow (algo informal) de revisión. Otro dato importante es que el cliente diseña encuestas que van desde aquellas con solo algunas pocas preguntas hasta esas otras que nos tienen todo un domingo respondiendo acerca de alguna ginebra o algún nuevo centro comercial. Para rematar debo decir que...
En mi entrada Fluent Interfaces y TDD presentaba una prueba de concepto sobre un DSL interno que estaba desarrollando para encapsular varios detalles de la manipulación de documentos en el proyecto en el que trabajo actualmente. Luego de avanzar un tanto me doy con un problema muy común en la mayoría de las interfaces fluidas que he visto, a este patrón lo llamo sentencia única . Esto significa que una sentencia de un dsl interno no interactúa con otras del mismo. Veamos un ejemplo: Dh.Using.AnimalControl...
Hoy todos reconocemos el potencial que tiene (LOP) Language Oriented Programming, pero no solo eso sino que muchos ya están invirtiendo para hacerse con las ventajas prometidas por este paradigma(?). Muchos incluso diseñan la sintaxis de aquellos lenguajes que entienden, pueden hacerles alcanzar la productividad, calidad y mantenibilidad que buscan. Ahora bien, una vez decididos a crear el lenguaje (textual) propio para un dominio particular, hay que implementarlo. Aquí es donde deben estudiarse...
Imagina que encontramos un clase estática con varios métodos estáticos los cuales tienen una cantidad aberrante de parámetros. Queremos eliminarla pero nos damos con que está siendo usada en muchísimas partes ¿que hacemos? ¿Como lo harias vos?. Para hablar más concretamente veamos uno de esos métodos: public static void CreateActivityLog( string containerSourceId, string containerId, string action, string sourceId, string instanceId, string docNo, string notes, IFrameworkSecurityContext credentials...
Desarrollar con TDD al principio no es nada fácil pero luego se vuelve “la manera” de desarrollar. Ahora, no siempre hago TDD, si quiero probar algo tan solo tiro las lineas y listo pero, por otro lado, si quiero hacer algo bien por más que tenga algo de código hecho lo tiro y lo comienzo de nuevo con TDD (nunca he perdido mucho. Por el contrario, lo hago porque veo una diferencia). El asunto es que diseñé una interface fluida para encapsular todos los detalles indeseables de la manipulación de documentos...
Intro Como ya sabemos, un DSL es un lenguaje de programación que se construye para atacar una familia de problemas que se presentan habitualmente en un dominio particular. Aunque su denominación actual (DSL) es relativamente nueva, estos han sido utilizados desde siempre, en particular los que Martin Fowler llama “external DSL” los cuales muchas veces los utilizamos dentro de otro lenguaje huésped. Por ejemplo, es muy común encontrar SQL, XPath, RegEx, Xml...
Aprender a desarrollar y a diseñar software es una tarea en la que hay que invertir muchos años. Hay que ser obsesivo, fanático, hay que equivocarse miles de veces y aprender de esos errores. No contentarse con los aparentes aciertos porque al poco de andar se descubre que no se hizo lo mejor sino que alguien más en un blogs perdido en la web lo resolvió mucho mejor que nosotros y ese alguien también encontrará mejores maneras 10 minutos después de su posteo. Pero sobre todo, hay que leer muchísimo...