Fig 1. Veh\u00edculo<\/figcaption><\/figure>\nLo m\u00e1s recomendable separar las responsabilidades con el fin de que cada clase posea una responsabilidad, por lo cual se quitar\u00eda de Veh\u00edculo el m\u00e9todo \u201cimprimir\u201d y se trasladar\u00eda a una nueva clase denominada VehiculoImpresor.<\/p>\nFig 2. Veh\u00edculoImpresor<\/dd>\n<\/p>\n
<\/figcaption><\/figure>\n<\/span>O-Abierto\/Cerrado (Open\/Closed)<\/span><\/h3>\nPrincipio atribuido a Bertrand Meyer que habla de crear clases extensibles sin necesidad de entrar al c\u00f3digo fuente a modificarlo [3]. Es decir, el dise\u00f1o debe ser abierto para extenderse pero cerrado para modificarse. Lo complicado es predecir por donde se debe extender sin tener que modificarse. Para conseguir este principio hay que tener muy claro c\u00f3mo va a funcionar la aplicaci\u00f3n, por donde se puede extender y como van a interactuar las clases.<\/p>\n
El uso m\u00e1s com\u00fan de extensi\u00f3n es mediante la herencia y la reimplementaci\u00f3n de m\u00e9todos. Existe otra alternativa, que consiste en utilizar m\u00e9todos que acepten una interface de manera que podemos ejecutar cualquier clase que implemente ese interface. En todos los casos, el comportamiento de la clase cambia sin que hayamos tenido que tocar c\u00f3digo interno.<\/p>\n
Siguiendo con el ejemplo anterior, si se debe imprimir en HTML el veh\u00edculo no ser\u00eda correcto implementar un nuevo m\u00e9todo en VehiculoImpresor, es posible definir una interfaz que permita ampliar en el tiempo las funcionalidades de cada clase que se va creando.<\/p>\nFig 3. Interface para VehiculoImpresor<\/dd>\n<\/p>\n
<\/figcaption><\/figure>\n<\/span>L-Sustituci\u00f3n Liskov (Liskov substitution)<\/span><\/h3>\nEste principio fue creado por Barbara Liskov y habla de la importancia de originar todas las clases derivadas para que tambi\u00e9n puedan ser tratadas como la propia clase base. Cuando se crean clases derivadas, se debe asegurar de no re-implementar m\u00e9todos que hagan que los m\u00e9todos de la clase base no funcionar\u00e1n si se tratan como un objeto de esa clase base.<\/p>\n
Con el ejemplo de la Figura 3,\u00a0con las clases VehiculoImpresorConsola y VehiculoImpresorHTML puede sustituirse sin problema con la interface IVehiculoImpresor.<\/p>\n
<\/span>I-Segregaci\u00f3n del interface (Interface segregation)<\/span><\/h3>\nEste principio fue formulado por Robert C. Martin y trata de algo parecido al primer principio. Cuando se definen interfaces, estos deben ser espec\u00edficos a una finalidad concreta. Por ello, si tenemos que definir una serie de m\u00e9todos abstractos que debe utilizar una clase a trav\u00e9s de interfaces, es preferible tener muchas interfaces que definan pocos m\u00e9todos que tener un interface con muchos m\u00e9todos.<\/p>\n
El objetivo de este principio es principalmente seguir aprovechando los interfaces en otras clases. Si tenemos un interface que compara y clona en el mismo interface, de manera m\u00e1s complicada se podr\u00e1 utilizar en una clase que solo debe comparar o en otra que solo debe clonar.<\/p>\n
En la figura 4, se establecen demasiadas responsabilidades para la interface ITrasporte, con el consiguiente problema que las clases que implementen dicha interfaz est\u00e1n obligados a implementar los tres m\u00e9todos descritos. Lo cual es err\u00f3neo.<\/p>\nFig 4. Interface con varias responsabilidades<\/strong><\/em><\/figcaption><\/figure>\nPara solucionar esto se debe separar cada responsabilidad. Tal como la figura 5.<\/p>\nFig 5. Interfaces separadas<\/em><\/strong><\/dd>\n<\/p>\n
<\/figcaption><\/figure>\n<\/span>D-Inversi\u00f3n de dependencias (Dependency inversion)<\/span><\/h3>\nTambi\u00e9n fue definido por Robert C. Martin. El objetivo de este principio es conseguir desacoplar las clases. En todo dise\u00f1o existe un acoplamiento, pero debe evitarse en la medida de lo posible. Un sistema no acoplado no hace nada, pero un sistema altamente acoplado es muy dif\u00edcil de mantener.<\/p>\n
El objetivo de este principio es el uso de abstracciones para conseguir que una clase interact\u00fae con otras clases sin que las conozca directamente. Es decir, las clases de nivel superior no deben conocer las clases de nivel inferior. Dicho de otro modo, no debe conocer los detalles. Existen diferentes patrones como la inyecci\u00f3n de dependencias o service locator que nos permiten invertir el control.<\/p>\n
Fig. 6 Direcci\u00f3n est\u00e1 fuertemente acoplada<\/figcaption><\/figure>\nFig 7. Se\u00a0logra la inversi\u00f3n de dependencia<\/dd>\n<\/p>\n
<\/figcaption><\/figure>\n<\/span>Glosario<\/span><\/h2>\nAcoplamiento:<\/strong>\u00a0Grado de dependencia que tienen dos unidades de software. Si hablamos de funciones, el acoplamiento nos da una idea de lo dependientes que son dos funciones entre s\u00ed. Es decir, en qu\u00e9 grado una funci\u00f3n puede hacer su trabajo sin la otra. Si hablo del m\u00e1s bajo nivel de acoplamiento cuando dos unidades de software son totalmente independientes.[2]<\/p>\nUn bajo acoplamiento permite:<\/p>\n
\nEntender una clase sin leer otras<\/li>\n Cambiar una clase sin afectar a otras<\/li>\n Mejora la mantenibilidad del c\u00f3digo<\/li>\n<\/ul>\nCohesi\u00f3n:\u00a0<\/strong>La cohesi\u00f3n mide el costo del cambio dentro de un elemento. Un elemento es cohesivo a medida que cambia el elemento entero cuando el sistema necesita cambiar.[4]<\/p>\n<\/span>Bibliograf\u00eda<\/span><\/h2>\n[1] http:\/\/www.genbetadev.com\/paradigmas-de-programacion\/solid-cinco-principios-basicos-de-diseno-de-clases<\/p>\n
[2]\u00a0http:\/\/latecladeescape.com\/h\/2015\/07\/acoplamiento-y-cohesion#<\/p>\n
[3]\u00a0https:\/\/devexperto.com\/principio-open-closed\/<\/p>\n
[4]\u00a0https:\/\/dosideas.com\/noticias\/java\/502-acoplamiento-y-cohesion<\/p>\n","protected":false},"excerpt":{"rendered":"
Acr\u00f3nimo inventado por Robert C. Martin para establecer 5 principios b\u00e1sicos en la programaci\u00f3n orientada a objetos. El objetivo de tener un buen dise\u00f1o de programaci\u00f3n es abarcar la fase de mantenimiento de una manera m\u00e1s legible y sencilla, as\u00ed como conseguir crear nuevas funcionalidades sin tener que modificar en gran medida c\u00f3digo antiguo. Los […]<\/p>\n","protected":false},"author":2,"featured_media":0,"comment_status":"closed","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"_jetpack_memberships_contains_paid_content":false,"footnotes":""},"categories":[45],"tags":[56,125,135],"class_list":["post-324","post","type-post","status-publish","format-standard","hentry","category-objetos","tag-buenas-practicas","tag-principios","tag-solid"],"jetpack_sharing_enabled":true,"jetpack_featured_media_url":"","jetpack-related-posts":[],"_links":{"self":[{"href":"https:\/\/iscodigo.com\/blog\/wp-json\/wp\/v2\/posts\/324","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/iscodigo.com\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/iscodigo.com\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/iscodigo.com\/blog\/wp-json\/wp\/v2\/users\/2"}],"replies":[{"embeddable":true,"href":"https:\/\/iscodigo.com\/blog\/wp-json\/wp\/v2\/comments?post=324"}],"version-history":[{"count":2,"href":"https:\/\/iscodigo.com\/blog\/wp-json\/wp\/v2\/posts\/324\/revisions"}],"predecessor-version":[{"id":1644,"href":"https:\/\/iscodigo.com\/blog\/wp-json\/wp\/v2\/posts\/324\/revisions\/1644"}],"wp:attachment":[{"href":"https:\/\/iscodigo.com\/blog\/wp-json\/wp\/v2\/media?parent=324"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/iscodigo.com\/blog\/wp-json\/wp\/v2\/categories?post=324"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/iscodigo.com\/blog\/wp-json\/wp\/v2\/tags?post=324"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}