{"id":2362,"date":"2020-09-19T20:06:01","date_gmt":"2020-09-20T00:06:01","guid":{"rendered":"http:\/\/leandrosepulveda.com\/site\/?p=2362"},"modified":"2020-09-19T20:09:54","modified_gmt":"2020-09-20T00:09:54","slug":"principios-solid","status":"publish","type":"post","link":"https:\/\/leandrosepulveda.com\/site\/2020\/09\/19\/principios-solid\/","title":{"rendered":"Principios SOLID"},"content":{"rendered":"<div class=\"blob js-post-images-container\">\n  <p><strong>Solid <\/strong>es un acr\u00f3nimo inventado por <strong>Robert C.Martin<\/strong> para establecer los cinco principios b\u00e1sicos de la programaci\u00f3n orientada a objetos y dise\u00f1o. Este acr\u00f3nimo tiene bastante relaci\u00f3n con los patrones de dise\u00f1o, en especial, con la <strong>alta cohesi\u00f3n<\/strong> y el <strong>bajo acoplamiento<\/strong>. <\/p>\n<!-- BREAK 1 -->\n<p>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 <strong>c\u00f3digo antiguo<\/strong>. Los costes de mantenimiento pueden abarcar el 80% de un proyecto de software por lo que hay que valorar un buen dise\u00f1o.<\/p>\n<!-- BREAK 2 --> <div id=\"div-gpt-out\" style=\"width:1px; height:1px;\" data-google-query-id=\"COy30oC39usCFTUdswAdj4oIMg\">\n  \n <div id=\"google_ads_iframe_\/1018282\/GEB-OUT-interior_0__container__\" style=\"border: 0pt none;\"><iframe id=\"google_ads_iframe_\/1018282\/GEB-OUT-interior_0\" title=\"3rd party ad content\" name=\"google_ads_iframe_\/1018282\/GEB-OUT-interior_0\" width=\"1\" height=\"1\" scrolling=\"no\" marginwidth=\"0\" marginheight=\"0\" frameborder=\"0\" srcdoc=\"\" data-google-container-id=\"7\" style=\"border: 0px; vertical-align: bottom;\" data-load-complete=\"true\"><\/iframe><\/div><\/div>\n\n<!--more-->\n\n<h2>S-Responsabilidad simple (Single responsibility)<\/h2>\n\n<p>Este principio trata de destinar cada clase a una <strong>finalidad sencilla y concreta<\/strong>. En muchas ocasiones estamos tentados a poner un m\u00e9todo reutilizable que no tienen nada que ver con la clase simplemente porque lo utiliza y nos pilla m\u00e1s a mano. En ese momento pensamos &#8220;Ya que estamos aqu\u00ed, para que voy a crear una clase para realizar esto. Directamente lo pongo aqu\u00ed&#8221;.<\/p>\n<!-- BREAK 3 -->\n<p>El problema surge cuando tenemos la necesidad de utilizar ese mismo m\u00e9todo desde otra clase. Si no se refactoriza en ese momento y se crea una clase destinada para la <strong>finalidad del m\u00e9todo<\/strong>, nos toparemos a largo plazo con que las clases realizan tareas que no deber\u00edan ser de su responsabilidad. <\/p>\n<!-- BREAK 4 -->\n<p>Con la anterior mentalidad nos encontraremos, por ejemplo, con un algoritmo de formateo de n\u00fameros en una clase destinada a leer de la base de datos porque fue el primer sitio donde se empez\u00f3 a utilizar. Esto conlleva a tener m\u00e9todos dif\u00edciles de detectar y encontrar de manera que el c\u00f3digo hay que tenerlo memorizado en la cabeza.<\/p>\n<!-- BREAK 5 -->\n<h2>O-Abierto\/Cerrado (Open\/Closed)<\/h2>\n\n<p>Principio atribuido a <strong>Bertrand Meyer<\/strong> que habla de crear clases extensibles sin necesidad de entrar al c\u00f3digo fuente a modificarlo. Es decir, el dise\u00f1o debe ser abierto para poderse extender pero cerrado para poderse modificar. Aunque dicho parece f\u00e1cil, lo complicado es predecir por donde se debe extender y que no tengamos que modificarlo. Para conseguir este principio hay que tener muy claro como va a funcionar la aplicaci\u00f3n, por donde se puede extender y como van a interactuar las clases.<\/p>\n<!-- BREAK 6 -->\n<p>El uso m\u00e1s com\u00fan de extensi\u00f3n es mediante la <strong>herencia <\/strong>y la reimplementaci\u00f3n de m\u00e9todos. Existe otra alternativa que consiste en utilizar m\u00e9todos que acepten una <strong>interface <\/strong>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<!-- BREAK 7 -->\n<p>Como ya he comentado llega un momento en que las necesidades pueden llegar a ser tan imprevisibles que nos topemos que con los m\u00e9todos definidos en el interface o en los m\u00e9todos extensibles, no sean suficientes para cubrir las necesidades. En este caso no habr\u00e1 m\u00e1s remedio que romper este principio y refactorizar.<\/p>\n<!-- BREAK 8 -->\n<h2>L-Sustitucion Liskov (Liskov substitution)<\/h2>\n\n<p>Este principio fue creado por <strong>Barbara Liskov<\/strong> y habla de la importancia de crear todas las clases derivadas para que tambi\u00e9n puedan ser tratadas como la propia clase base. Cuando creamos clases derivadas debemos asegurarnos de no reimplementar m\u00e9todos que hagan que los m\u00e9todos de la clase base no funcionases si se tratasen como un objeto de esa clase base.<\/p>\n<!-- BREAK 9 -->\n<h2>I-Segregacion del interface (Interface segregation)<\/h2>\n\n<p>Este principio fue formulado por <strong>Robert C. Martin<\/strong> 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 muchos interfaces que definan pocos m\u00e9todos que tener un interface con muchos m\u00e9todos.<\/p>\n<!-- BREAK 10 -->\n<p>El objetivo de este principio es principalmente poder <strong>reaprovechar los interfaces<\/strong> en otras clases. Si tenemos un interface que <strong>compara y clona<\/strong> 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<!-- BREAK 11 -->\n<h2>D-Inversi\u00f3n de dependencias (Dependency inversion)<\/h2>\n\n<p>Tambi\u00e9n fue definido por <strong>Robert C. Martin<\/strong>. El objetivo de este principio conseguir desacoplar las clases. En todo dise\u00f1o siempre debe existir un acoplamiento pero hay que evitarlo 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<!-- BREAK 12 -->\n<p>El objetivo de este principio es el uso de abstracciones para conseguir que una clase interactue 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<strong> inyecci\u00f3n de dependencias o service locator<\/strong> que nos permiten invertir el control.<\/p>\n<!-- BREAK 13 --> <\/div>","protected":false},"excerpt":{"rendered":"<p>Solid es un acr\u00f3nimo inventado por Robert C.Martin para establecer los cinco principios b\u00e1sicos de la programaci\u00f3n orientada a objetos [&hellip;]<\/p>\n","protected":false},"author":1,"featured_media":2364,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"_jetpack_memberships_contains_paid_content":false,"footnotes":""},"categories":[17,1],"tags":[],"class_list":["post-2362","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-development","category-sin-categoria"],"aioseo_notices":[],"jetpack_sharing_enabled":true,"jetpack_featured_media_url":"https:\/\/leandrosepulveda.com\/site\/wp-content\/uploads\/2020\/09\/clean.png","_links":{"self":[{"href":"https:\/\/leandrosepulveda.com\/site\/wp-json\/wp\/v2\/posts\/2362","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/leandrosepulveda.com\/site\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/leandrosepulveda.com\/site\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/leandrosepulveda.com\/site\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/leandrosepulveda.com\/site\/wp-json\/wp\/v2\/comments?post=2362"}],"version-history":[{"count":1,"href":"https:\/\/leandrosepulveda.com\/site\/wp-json\/wp\/v2\/posts\/2362\/revisions"}],"predecessor-version":[{"id":2363,"href":"https:\/\/leandrosepulveda.com\/site\/wp-json\/wp\/v2\/posts\/2362\/revisions\/2363"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/leandrosepulveda.com\/site\/wp-json\/wp\/v2\/media\/2364"}],"wp:attachment":[{"href":"https:\/\/leandrosepulveda.com\/site\/wp-json\/wp\/v2\/media?parent=2362"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/leandrosepulveda.com\/site\/wp-json\/wp\/v2\/categories?post=2362"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/leandrosepulveda.com\/site\/wp-json\/wp\/v2\/tags?post=2362"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}