Lección 8
jfk
subi Copia de Leccion8.txt, nada más hay que cambiar la extensión
a .rar.
Javier
Eugenia Delgado Castillo
Por: Javier Romero 3 Comments
A lo largo del camino de "aprender" todo lo involucrado al desarrollo web con Asp.net MVC, implementaremos muchos principios de programación a veces desconocidos para nosotros, o al menos "omitidos" en aras del tiempo, supuesta eficiencia o simplemente porque nos queremos ir por el camino fácil..
Pues un aspecto principal de esta "nueva teoría" a aprender son los principios S.O.L.I.D. que regirán de aquí en adelante todos los esfuerzos de diseño y codificación de las aplicaciones mvc que realicemos.
Qué es S.O.L.I.D.?
Es una colección de mejores prácticas y principios del diseño orientado a objetos que podemos aplicar a nuestros diseños para cumplir algunos objetivos como: loose-coupling, mayor mantenimiento del código, localización intiutiva de código, etc. S.O.L.I.D. es una abreviatura (acrónimo) para estos principios.
Estos principios fueron recogidos y compendiados en un trabajo escrito por Robert "Tio Bob" Martin (Uncle Bob Martin). Podemos encontrar más detalles de este trabajo en: http://butunclebob.com/ArticleS.UncleBob.PrinciplesOfOod.
Vamos a dar un pequeño resumen sobre cada uno de estos principios, pero no iré a los detalles, para no cansar con mucho texto que leer, preferiblemente enlazaré artículos y webcasts que permitan de forma práctica comprender estos principios y aplicarlos de la forma más óptima y eficiente posible.
SRP: Single Responsibility Principle
NO DEBERÍA HABER MAS QUE UNA RAZÓN PARA QUE UNA CLASE CAMBIE.
En SRP una razón para cambiar es definida como una responsabilidad, por lo tanto es considerado como un estado. Si un objeto tiene más de una razón para cambiar, entonces tiene más de una responsabilidad lo cual es una violación a SRP.
Para entender este principio, mira este webcast de DimeCast.net:
Más detalles:
- PTOM: The Single Responsibility Principle por Sean Chambers
- PTOM: The Single Responsibility Principle por Jason Meridth
OCP: Open Closed Principle
LAS ENTIDADES DE SOFTWARE(CLASSES, MODULES, FUNCIONES, ETC), DEBERIAN ESTAR DISPONIBLES PARA EXTENDERSE PERO CERRADAS PARA MODIFICACION.
Este es uno de los más antiguos principios del Diseño Orientado a Objectos. Esto se puede resumir como "Cualquier entidad, debería permitir que su comportamiento pueda ser modificado (extendido), pero sin alterar su código fuente. Suena bastante fácil para cualquier desarrollador, pero es más complicado implementarlo a gran escala.
LSO: Liskov Substitution Principle
FUNCIONES QUE USEN... REFERENCIAS A CLASES BASE, DEBEN SER CAPACES DE USAR OBJETOS DE CLASES DERIVADAS SIN EXPLICITAMENTE CONOCER ESTOS OBJETOS.
Un resumen rápido: Si tenemos una clase base BASE, y subclases SUB1 y SUB2 el resto del código debería siempre referenciar a BASE y NO a SUB1 y SUB2.
ISP: Interface Segregation Principle
LOS CLIENTES NO DEBERÍAN SER FORZADOS A DEPENDER DE INTERFACES QUE ELLOS NO USAN.
Básicamente, si tenemos una clase abstracta o una interfaz, entonces, quienes implementen estas clases no deberían ser forzados a implementar partes que para un comportamiento específico no importan. Un caso de la vida real: Intenta crear un CustomMembershipProvider, heredando de MembershipProvider, son más de 20 métodos para sobrescribir, de las cuales a lo mejor solamente necesitas 5, he ahí una violación a ISP. El éxito llega con la creación de una serie de interfaces o clases abstractas que permita la modularización de objetos, sus propiedas y/o métodos.
- WEBCAST: Interface Segregation Principle.
- PTOM: The Interface Segregation Principle por Ray Houston
- PDF: ISP por ObjectMentor
DIP: Dependency Inversion Principle
A. MODULOS DE UN NIVEL ALTO NO DEBERÍAN DEPENDER DE MODULOS DE BAJO NIVEL. LA DEPENDENCIA ENTRE AMBOS DEBE SER REALIZADA SOBRE ABSTRACCIONES.
B. LAS ABSTRACIONES NO DEBERIAN DEPENDER DE DETALLES. LOS DETALLES PODRIAN DEPENDER DE ABSTRACCIONES.
Este último principio es la evolución natural de los tres primeros, la conclusión obvia. Una ayuda para el diseño "elegante" y a la vez manejar las responsabilidades y separación a nivel de assemblies o "módulos".
Leovardo Mejia Bolaños
Ing. L.Leovardo Mejia Bolaños
Gerencia Pensiones C.C.S.S.
Javier Solis
Saludos.
Javier
--
-------------------------------------------
Ing. Javier Solís Agüero
Master Recursos Informáticos
Consultor Informático
MTC, MCSD
J2EE Developer.
--------------------------------------------------
Leovardo Mejia Bolaños
Javier Solis
Saludos.
Leovardo Mejia Bolaños
Cual era la dirección de la nueva sede?
Ayes anduve buscándola y no la encontré. Fui por el INAMU pero nada?
Javier Solis
Javier.
Leovardo Mejia Bolaños
Nos vemos gracias.