Principio abierto cerrado (OCP) Parte II

0 comentarios
Teniendo en cuenta los comentarios recibidos en la entrada anterior y en forma personal, paso a comentar otra forma de poder cumplir con este principio abierto y cerrado (OCP): la implementación del patrón de diseño strategy.
Este patrón de diseño, establece que los comportamientos no deben heredarse. En su lugar, se deben encapsular usando interfaces.
Para dar un ejemplo, me remitiré a uno ya existente en el libro Head first design patterns.
Debemos programar una simulación de un pato, para ello, creamos una clase abstracta denominada Pato, la cual posee los métodos (o comportamientos) Cuac(), Nadar() y Mostrar(). Todos los patos hacen cuac y nadan, por lo que esta clase implementa dichos métodos. Pero, como todos los patos lucen diferentes, el método Mostrar será abstracto, es decir, se implementará en cada subclase.

Principio Abierto Cerrado (OCP)

4 comentarios
La segunda letra del acrónimo S.O.L.I.D., representa al principio Abierto Cerrado. El cuál establece que "Las entidades de software (clases, módulos, funciones, etc.) deben estar abiertas para extensión pero cerradas para modificación". Esto básicamente significa que debemos ser capaces de cambiar el comportamiento externo o las dependencias externas de una clase, sin tener que cambiar físicamente la clase en sí misma. Este tipo de comportamiento nos habilita a cambiar una parte del código sin estar obligado a cambiar otras partes del mismo, siempre y cuando nos mantengamos dentro de los límites del contrato existente.
Suena fácil, pero muchos desarrolladores podemos perder el norte durante la implementación de este enfoque de extensibilidad. No se trata necesariamente por una cuestión de habilidades, sino más bien, que no se nos ha enseñado a abordar este principio en el diseño de clases.

Principio de responsabilidad única (SRP)

0 comentarios
El principio de responsabilidad única (SRP) es el primer principio del acrónimo SOLID y establece que "Nunca debe haber más de una razón para que una clase cambie".
Algo con un propósito, una responsabilidad, siempre va a resultar mucho más fácil de cambiar. Esto es simplemente porque se puede ver mucho más claramente lo que hace y lo que no. Además, como tiene una única responsabilidad, no hay chance de que el cambio en el código pueda afectar a otro código, comportamiento quizás, pero código, no. Y mejora en gran medida la reutilización de código.
Finalmente, el código se hace mucho más fácil de probar ya que se puede realizar el test de una responsabilidad en forma aislada de las demás.

Los principios S.O.L.I.D.

0 comentarios
Toda aplicación nace de los requisitos de una persona que los realiza. Si dichos requisitos fueran inamovibles e inmutables a lo largo del tiempo, las modificaciones de software nunca serían necesarias.
Lamentablemente, esto es sólo una utopía para los programadores y con el correr del tiempo hemos tratado de no caer en las trampas que nosotros mismos nos creamos cuando programamos sin pensar en los cambios que los requerimientos pueden sufrir a lo largo del tiempo.
Entra tantas mejoras que se han ido agregando al desarrollo de software, la programación orientada a objetos (P.O.O.) se ha convertido en un conocimiento que hoy se considera muy importante para esta tarea.
Implementar los principios S.O.L.I.D., nos redundará en una mejora sustancial del diseño y arquitectura de nuestras aplicaciones, haciendo que las mismas sean mucho más flexibles y extensibles.
Este acrónimo mnemotécnico surge de la unión de varios principios básicos de la programación orientada a objetos, explicados en el libro "Agile software development: Principles, Patterns and Practices" por uno de los grandes exponentes de la Artesanía del software: el famoso Uncle Bob (Robert Cecil Martin).

Principio K.I.S.S. ( parte II )

0 comentarios
Habiendo desarrollado en la última entrada de este blog el concepto del principio K.I.S.S. y sus beneficios, veremos a continuación la segunda y última entrega de este principio.


Cómo aplicarlo al trabajo diario
Son muchos pasos los que se deben llevar a cabo, muy simples, pero pueden resultar un reto para algunos.
Tan fácil como suena, mantenerlo simple, es sólo cuestión de paciencia. Sobretodo, con uno mismo.
A continuación, veremos los puntos a tener en cuenta para llevarlo a cabo:

  • Ser humilde. No pensar en uno mismo como un super genio. Este es el primer error. Siendo humilde, es muy posible alcanzar el estatus de super genio. Pero, aunque así no se lograse, a quién le importa?! El código es simple y estúpido, por lo que no hay que ser un genio para trabajar con él.
  • Dividir las tareas en subtareas que, en principio, no deben llevar más de 4-12 horas de codificación.
  • Dividir los problemas en pequeños problemas. Cada problema se debe poder resolver dentro de una o muy pocas clases.
  • Mantener los métodos pequeños. Cada método no debe tener nunca más de 10-20 líneas y sólo debe resolver un (y sólo un) problema. Si contiene muchas condiciones, hay que dividirlo en métodos más pequeños. (Esto no sólo los hace más legibles y mantenibles, sino que además, encontrar errores es mucho más rápido.
  • Mantener las clases pequeñas. Aplicar la misma metodología que con los métodos.

Principio K.I.S.S. ( parte I )

0 comentarios
K.I.S.S. es la abreviatura de Keep It Simple, Stupid (mantenlo simple, estúpido).
Un problema común entre los ingenieros y desarrolladores de software hoy en día, es que tendemos a complicar más los problemas.
Normalmente, cuando nos enfrentamos a un problema, dividimos en trozos más pequeños que pensamos que entendemos y luego tratamos de implementar la solución en el código. Yo diría que 8 o 9 de cada 10 desarrolladores cometemos el error de no descomponer el problema en trozos suficientemente pequeños o suficientementes comprensibles. Esto se traduce en implementaciones muy complejas de los problemas más simples.
Otro efecto secundario es el llamado: código spagetthi. Algo que creíamos que sólo en BASIC podía hacerse con sus sentencias GOTO. Pero no, en lenguajes modernos como C# o Java, se traduce en clases de 500-1000 líneas de código (decenas de métodos con decenas de líneas).
Este desorden de código es el resultado de la realización de casos de excepción, por parte nuestra, a la solución original mientras que se está escribiendo el código.
Dichos casos se hubieran resuelto si hubiéramos descompuesto aún más el problema.

Beneficios de aplicar este principio:
  • Resolver más problemas, más rápido.
  • Resolver problemas en pocas líneas de código.
  • Producir código de mejor calidad.
  • Construir sistemas muy grandes, fáciles de mantener.
  • Lograr un framework propio más flexible y más fácil de ampliar, modificar o refactorizar cuando lleguen nuevos requerimientos.
  • Se podrá trabajar en grandes equipos de desarrollo y grandes proyectos ya que el código será simple y estúpido.
Fuente: The Kiss principle (Grupo Apache)

POO vs POP

2 comentarios

Programación Orientada a Objetos o Programación Orientada a Parches. 
Este es un dilema que se nos presenta a diario cuando se requiere extender la funcionalidad de una clase o modificar el diseño para agregar funcionalidad. Para muchos, el tiempo apremia y lo más evidente es resolver las cosas de una manera que, a priori, parece la más sencilla: un parche (*).
Pero cuidado, resulta muy fácil caer en una trampa que nos armamos nosotros mismos. Muchas veces, la solución más sencilla en tiempo, resulta una contra,  ya que la misma, no es escalable y el tiempo que no gastamos hoy haciendo un refactoring “complejo”, lo gastamos más adelante (multiplicado por N) debido a que esa lógica ya esta muy arraigada en la aplicación.
Un caso común, resulta del agregado de métodos o propiedades en clases a las que no les corresponde esa responsabilidad. Esto puede pasar por varios motivos:
  • Desconocimiento del framework propio: Se desconoce la existencia de otra clase que ya posee esa responsabilidad.
  • Falta de tiempo: Para no buscar en todo el framework si ya existe una clase a quién agregarle esta funcionalidad, se agrega en otra que podría soportarla.

Hola mundo

0 comentarios

Uff... Otro blog de un tipo que cree que tiene la verdad sobre la programación. El verdadero dueño del Tao.
Bueno, no es mi intención.
Como todo blog, simplemente pretendo volcar acá, en la medida de lo posible, mi opinión sobre algunos temas que atañen al diseño y desarrollo de software.
Trataré sobre metodologías ágiles y otras yerbas visto siempre desde la óptica de los principios S.O.L.I.D.
Espero que esto nos sirva a todos para tratar de mejorar día a día en esta profesión que nos une.
Y como el debate amplía las ideas, pues eso, que todos podamos aportar opiniones y sacar cada quien su propia conclusión.
Nos leemos, hasta la próxima entrada.

Política de cookies

¿QUÉ SON LAS COOKIES?

Una cookie es un archivo que se descarga en su ordenador al acceder a determinadas páginas web. Las cookies permiten a una página web, entre otras cosas, almacenar y recuperar información sobre los hábitos de navegación de un usuario o de su equipo y, dependiendo de la información que contengan y de la forma en que utilice su equipo, pueden utilizarse para reconocer al usuario.

¿QUÉ TIPOS DE COOKIES UTILIZAN ESTA PÁGINA WEB?

  • Google Analytics: Cookies analiticas, son aquéllas que bien tratadas por nosotros o por terceros, nos permiten cuantificar el número de usuarios y así realizar la medición y análisis estadístico de la utilización que hacen los usuarios del servicio ofertado. Para ello se analiza su navegación en nuestra página web con el fin de mejorar la oferta de productos o servicios que le ofrecemos. 
  • Google Adsense: Cookies publicitarias, son aquéllas que, bien tratadas por nosotros o por terceros, nos permiten gestionar de la forma más eficaz posible la oferta de los espacios publicitarios que hay en la página web, adecuando el contenido del anuncio al contenido del servicio solicitado o al uso que realice de nuestra página web. Para ello podemos analizar sus hábitos de navegación en Internet y podemos mostrarle publicidad relacionada con su perfil de navegación. 

REVOCACIÓN Y ELIMINACIÓN DE COOKIES

Puedes permitir, bloquear o eliminar las cookies instaladas en tu ordenador mediante la configuración de las opciones del navegador instalado en tu ordenador.
  • Para más información sobre el navegador Firefox pulse aquí
  • Para más información sobre el navegador Chrome pulse aquí.
  • Para más información sobre el navegador Explorer pulse aquí.
  • Para más información sobre el navegador Safari desde aquí.
  • Para más información sobre el navegador OperaOpera.
 
Copyright 2009 Programación SOLIDa
BloggerTheme by BloggerThemes | Design by 9thsphere