{"id":34855,"date":"2019-10-31T22:00:51","date_gmt":"2019-10-31T19:00:51","guid":{"rendered":"https:\/\/prohoster.info\/blog\/10-printsipov-obektno-orientirovannogo-programmirovaniya-o-kotoryh-dolzhen-znat-kazhdyj-razrabotchik\/"},"modified":"2019-10-31T22:00:51","modified_gmt":"2019-10-31T19:00:51","slug":"10-printsipov-obektno-orientirovannogo-programmirovaniya-o-kotoryh-dolzhen-znat-kazhdyj-razrabotchik","status":"publish","type":"post","link":"https:\/\/prohoster.info\/es\/blog\/news\/10-printsipov-obektno-orientirovannogo-programmirovaniya-o-kotoryh-dolzhen-znat-kazhdyj-razrabotchik","title":{"rendered":"10 principios de programaci\u00f3n orientada a objetos que todo desarrollador debe conocer","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

\"10
\n
\nMe encuentro con frecuencia desarrolladores que no han o\u00eddo hablar de los principios SOLID (hemos hablado de ellos en detalle aqu\u00ed<\/a><\/noindex>. \u2014 Nota del editor) o de la programaci\u00f3n orientada a objetos (POO), o han o\u00eddo sobre ellos pero no los aplican en la pr\u00e1ctica. Este art\u00edculo describe las ventajas de los principios de la POO que ayudan al desarrollador en su trabajo diario. Algunos son bien conocidos, otros no tanto, as\u00ed que el art\u00edculo ser\u00e1 \u00fatil tanto para principiantes como para programadores experimentados.
\n<\/a><\/noindex><\/p>\n

Recordamos:<\/b> Para todos los lectores de \u00abHabr\u00bb \u2014 descuento de 10,000 rublos al inscribirse en cualquier curso de Skillbox con el c\u00f3digo promocional \u00abHabr\u00bb.<\/i><\/p>\n

Skillbox recomienda:<\/b> Curso en l\u00ednea educativo Desarrollador Java<\/a><\/noindex>.<\/p><\/blockquote>\n

<\/p>\n

DRY (No te repitas)<\/h3>\n

\nUn principio bastante simple, cuya esencia es clara por su nombre: \u00abNo te repitas\u00bb. Para un programador, esto significa la necesidad de evitar c\u00f3digo duplicado, as\u00ed como la posibilidad de utilizar abstracci\u00f3n en su trabajo.<\/p>\n

Si hay dos fragmentos repetidos en el c\u00f3digo, deben combinarse en un solo m\u00e9todo. Si un valor fijo se utiliza m\u00e1s de una vez, debe convertirse en una constante p\u00fablica.<\/p>\n

Esto es necesario para simplificar el c\u00f3digo y facilitar su mantenimiento, que es el objetivo principal de la POO. Sin embargo, tampoco se debe abusar de la combinaci\u00f3n, ya que el mismo c\u00f3digo no puede pasar la verificaci\u00f3n tanto con OrderId como con SSN.<\/p>\n

Encapsulamiento de cambios<\/h3>\n

\nLos productos de software de la mayor\u00eda de las empresas est\u00e1n en constante evoluci\u00f3n. Por lo tanto, es necesario realizar cambios en el c\u00f3digo y mantenerlo. Puedes simplificar tu vida mediante el encapsulamiento. Esto permitir\u00e1 probar y mantener de manera m\u00e1s efectiva la base de c\u00f3digo existente. Aqu\u00ed hay un ejemplo<\/a><\/noindex>.<\/p>\n

Si est\u00e1s programando en Java, asigna por defecto a m\u00e9todos y variables el modificador private<\/a><\/noindex>.<\/p>\n

Principio de apertura\/cierre<\/h3>\n

\nEste principio se puede recordar f\u00e1cilmente al leer la siguiente afirmaci\u00f3n: \u00abLas entidades de software (clases, m\u00f3dulos, funciones, etc.) deben estar abiertas a la extensi\u00f3n, pero cerradas a la modificaci\u00f3n\u00bb. En la pr\u00e1ctica, esto significa que pueden permitir cambios en su comportamiento sin modificar el c\u00f3digo fuente original.<\/p>\n

El principio es importante cuando los cambios en el c\u00f3digo fuente requieren revisiones, pruebas unitarias y otros procedimientos. El c\u00f3digo que se adhiere al principio de apertura\/cierre no se modifica al ser ampliado, por lo que presenta muchos menos problemas.<\/p>\n

Aqu\u00ed hay un ejemplo de c\u00f3digo que viola este principio.<\/p>\n

\"10
\n
\nSi se necesita cambiar algo, tomar\u00e1 mucho tiempo, ya que habr\u00e1 que modificar todas las secciones del c\u00f3digo relacionadas con el fragmento necesario.<\/p>\n

Por cierto, la apertura y el cierre son uno de los principios SOLID.<\/p>\n

Principio de Responsabilidad \u00danica (SRP)<\/h3>\n

\nOtro principio del conjunto SOLID. Establece que \"solo existe una raz\u00f3n para cambiar una clase\". Una clase solo debe abordar una tarea. Puede tener varios m\u00e9todos, pero cada uno se utiliza \u00fanicamente para resolver la tarea general. Todos los m\u00e9todos y propiedades deben servir solo a esto. <\/p>\n

\"10
\n
\nEl valor de este principio radica en que debilita la conexi\u00f3n entre un componente de software y el c\u00f3digo. Si se agrega m\u00e1s de una funcionalidad a una clase, se introduce una conexi\u00f3n entre dos funciones. As\u00ed, si se modifica una de ellas, hay una alta posibilidad de afectar la otra, que est\u00e1 relacionada con la primera. Esto significa un aumento en los ciclos de prueba para identificar todos los problemas de antemano.<\/p>\n

Principio de Inversi\u00f3n de Dependencias (DIP)<\/h3>\n

\n\"10
\n
\nEn el ejemplo de c\u00f3digo anterior, AppManager depende de EventLogWriter, que, a su vez, est\u00e1 estrechamente relacionado con AppManager. Si se necesita otra forma de mostrar una notificaci\u00f3n, ya sea un push, SMS o email, hay que modificar la clase AppManager.<\/p>\n

El problema puede resolverse utilizando DIP. As\u00ed, en lugar de AppManager, se solicita EventLogWriter, que ser\u00e1 introducido mediante el marco de trabajo.<\/p>\n

DIP permite reemplazar m\u00f3dulos individuales por otros sin problemas, cambiando el m\u00f3dulo de dependencia. Esto permite modificar un m\u00f3dulo sin afectar a los dem\u00e1s.<\/p>\n

Composici\u00f3n en lugar de herencia<\/h3>\n

\n\"10Las principales formas de reutilizaci\u00f3n de c\u00f3digo son la herencia y la composici\u00f3n, cada una con sus ventajas y desventajas. Por lo general, se prefiere la segunda, ya que es m\u00e1s flexible.<\/p>\n

La composici\u00f3n permite modificar el comportamiento de una clase en tiempo de ejecuci\u00f3n ajustando sus propiedades. Al implementar interfaces se utiliza el polimorfismo, lo que proporciona una implementaci\u00f3n m\u00e1s flexible.<\/p>\n

Incluso \"Effective Java\" de Joshua Bloch aconseja preferir la composici\u00f3n en lugar de la herencia.<\/p>\n

Principio de Sustituci\u00f3n de Barbara Liskov (LSP)<\/h3>\n

\nOtro principio del conjunto de herramientas SOLID. Establece que los subtipos deben ser reemplazables por su supertipo. Es decir, los m\u00e9todos y funciones que trabajan con la superclase deben poder funcionar sin problemas tambi\u00e9n con sus subclases.<\/p>\n

El LSP est\u00e1 relacionado tanto con el principio de responsabilidad \u00fanica como con el principio de segregaci\u00f3n de interfaces. Si una clase ofrece m\u00e1s funcionalidad que su subclase, esta \u00faltima no podr\u00e1 mantener algunas funciones, violando as\u00ed este principio.<\/p>\n

Aqu\u00ed hay un fragmento de c\u00f3digo que contradice el LSP.<\/p>\n

\"10
\n
\nEl m\u00e9todo area(Rectangle r) calcula el \u00e1rea de un Rectangle. El programa fallar\u00e1 al ejecutar Square, ya que Square no se considera un Rectangle aqu\u00ed. Seg\u00fan el principio LSP, las funciones que utilizan referencias a clases base deben poder usar objetos de clases derivadas sin instrucciones adicionales.<\/p>\n

Este principio, que es una definici\u00f3n espec\u00edfica de subtipo, fue propuesto por Barbara Liskov en 1987 en una conferencia durante una ponencia titulada 'Abstracci\u00f3n de datos e jerarqu\u00eda', de ah\u00ed su nombre.<\/p>\n

Principio de segregaci\u00f3n de interfaces (ISP)<\/h3>\n

\nOtro principio SOLID. Seg\u00fan \u00e9l, una interfaz que no se utiliza no debe ser implementada. Seguir este principio ayuda a que el sistema se mantenga flexible y adecuado para refactorizaciones al introducir cambios en la l\u00f3gica de funcionamiento.<\/p>\n

Esta situaci\u00f3n ocurre con mayor frecuencia cuando una interfaz contiene varias funcionalidades y el cliente solo necesita una de ellas.<\/p>\n

Dado que escribir una interfaz es una tarea complicada, despu\u00e9s de completar su trabajo, cambiarla sin romper nada ser\u00e1 un desaf\u00edo.<\/p>\n

La ventaja del principio ISP en Java es que primero se deben implementar todos los m\u00e9todos, y solo despu\u00e9s pueden ser utilizados por las clases. Por lo tanto, el principio permite reducir el n\u00famero de m\u00e9todos.<\/p>\n

\"10
\n <\/p>\n

Programar para una interfaz, no para una implementaci\u00f3n<\/h3>\n

\nAqu\u00ed queda claro por el nombre. La aplicaci\u00f3n de este principio conduce a la creaci\u00f3n de c\u00f3digo flexible que podr\u00e1 trabajar con cualquier nueva implementaci\u00f3n de la interfaz.<\/p>\n

Se debe utilizar el tipo de interfaz para variables, tipos de retorno o tipos de argumento de m\u00e9todo. Un ejemplo es utilizar SuperClass en lugar de SubClass.<\/p>\n

Es decir:<\/p>\n

List numbers = getNumbers();<\/i><\/p>\n

Y no:<\/p>\n

ArrayList numbers = getNumbers();<\/i><\/p>\n

Aqu\u00ed hay una implementaci\u00f3n pr\u00e1ctica de lo que se menciona arriba.<\/p>\n

\"10
\n <\/p>\n

El principio de delegaci\u00f3n<\/h3>\n

\nUn ejemplo com\u00fan son los m\u00e9todos equals() y hashCode() en Java. Cuando se necesita comparar dos objetos, esta acci\u00f3n se delega a la clase correspondiente en lugar del cliente.<\/p>\n

La ventaja del principio es la ausencia de duplicaci\u00f3n de c\u00f3digo y la relativa facilidad para modificar el comportamiento. Tambi\u00e9n se aplica a la delegaci\u00f3n de eventos.<\/p>\n

\"10
\n
\nTodos estos principios permiten escribir un c\u00f3digo m\u00e1s flexible, bonito y fiable, con alta cohesi\u00f3n y bajo acoplamiento. Por supuesto, la teor\u00eda es buena, pero para que un desarrollador realmente comience a utilizar lo aprendido, se requiere pr\u00e1ctica. El siguiente paso tras dominar los principios de la POO podr\u00eda ser estudiar patrones de dise\u00f1o para resolver problemas comunes en el desarrollo de software.<\/p>\n

Skillbox recomienda:<\/b><\/p>\n