{"id":19925,"date":"2023-07-25T12:52:39","date_gmt":"2023-07-25T12:52:39","guid":{"rendered":"https:\/\/devologyx.io\/patrones-de-diseno-elementos-de-software-reutilizable-orientado-a-objetos\/"},"modified":"2024-10-31T17:54:22","modified_gmt":"2024-10-31T17:54:22","slug":"patrones-de-diseno-elementos-de-software-reutilizable-orientado-a-objetos","status":"publish","type":"post","link":"https:\/\/devologyx.io\/es\/patrones-de-diseno-elementos-de-software-reutilizable-orientado-a-objetos\/","title":{"rendered":"PATRONES DE DISE\u00d1O: ELEMENTOS DE SOFTWARE REUTILIZABLE ORIENTADO A OBJETOS"},"content":{"rendered":"\n

Cap\u00edtulo uno: Introducci\u00f3n<\/strong><\/p>\n\n

\"\"<\/figure>\n\n

Dise\u00f1ar software orientado a objetos es complejo, y el software orientado a objetos reutilizable es a\u00fan m\u00e1s dif\u00edcil. Debe encontrar los objetos pertinentes, factorizarlos en clases con la granularidad adecuada, definir interfaces de clase y jerarqu\u00edas de herencia, y establecer relaciones clave entre ellos. Su dise\u00f1o debe ser espec\u00edfico para el problema y lo suficientemente general como para abordar problemas y requisitos futuros. <\/p>\n\n

\u00bfQu\u00e9 es un patr\u00f3n de dise\u00f1o?<\/strong><\/p>\n\n

Un patr\u00f3n de dise\u00f1o nombra, abstrae e identifica los aspectos cr\u00edticos de una estructura de dise\u00f1o est\u00e1ndar que la hacen \u00fatil para crear un dise\u00f1o orientado a objetos reutilizable. El patr\u00f3n de dise\u00f1o identifica las clases e instancias participantes, sus funciones y colaboraciones, y la distribuci\u00f3n de responsabilidades. Los patrones de dise\u00f1o describen problemas de su entorno y explican lo esencial de la soluci\u00f3n a ese problema para que pueda utilizar esta soluci\u00f3n de forma iterativa. Un patr\u00f3n de dise\u00f1o tiene cuatro elementos cr\u00edticos; <\/p>\n\n

    \n
  1. El nombre de un patr\u00f3n es un asidero para describir un problema de dise\u00f1o, sus soluciones y consecuencias en una o dos palabras. Poner nombre a un patr\u00f3n le permite dise\u00f1ar a un mayor nivel de abstracci\u00f3n. <\/li>\n\n\n\n
  2. El problema: explica cu\u00e1ndo aplicar el patr\u00f3n. Explica la situaci\u00f3n y su contexto. Describe problemas de dise\u00f1o espec\u00edficos como la forma de representar algoritmos como objetos. <\/li>\n\n\n\n
  3. La soluci\u00f3n: ilustra los elementos que componen el dise\u00f1o, sus relaciones, colaboraciones y responsabilidades.<\/li>\n\n\n\n
  4. Las consecuencias: son los resultados y contrapartidas de aplicar el patr\u00f3n.<\/li>\n<\/ol>\n\n

    Patrones de dise\u00f1o en Smalltalk MVC<\/strong><\/p>\n\n

    La tr\u00edada de clases Modelo\/Vista\/Controlador (MVC) [KP88] se utiliza para construir interfaces de usuario en Smalltalk-80. El Modelo Vista Controlador tiene tres clases de objetos. El Modelo es el objeto de la aplicaci\u00f3n, la Vista es su presentaci\u00f3n en pantalla y el Controlador define c\u00f3mo reacciona la interfaz de usuario a la entrada del usuario. Antes del MVC, los dise\u00f1os de interfaz de usuario tend\u00edan a agrupar estos objetos. Despu\u00e9s, el MVC los desacopla para mejorar la flexibilidad y la reutilizaci\u00f3n. MVC desacopla las vistas y los modelos estableciendo un protocolo de suscripci\u00f3n\/notificaci\u00f3n. Una vista debe asegurarse de que su apariencia refleja el estado del modelo. Cada vez que los datos del modelo cambian, se lo comunica a las vistas que dependen de \u00e9l. En respuesta, cada vista tiene la oportunidad de actualizarse. Este enfoque le permite adjuntar varias vistas a un modelo para ofrecer diferentes presentaciones. Tambi\u00e9n puede crear nuevas vistas para un modelo sin reescribirlo. <\/p>\n\n

    MVC le permite cambiar la forma en que una vista responde a la entrada del usuario sin cambiar su presentaci\u00f3n visual. Es posible que desee cambiar la forma en que responde al teclado, por ejemplo, o utilizar un men\u00fa emergente en lugar de teclas de comando. MVC encapsula el mecanismo de respuesta en un objeto controlador. Una jerarqu\u00eda de clases de controladores facilita la creaci\u00f3n de un nuevo controlador como variaci\u00f3n de uno ya existente. <\/p>\n\n

    Descripci\u00f3n de patrones de dise\u00f1o<\/strong><\/p>\n\n

    Los patrones de dise\u00f1o se definen utilizando un formato coherente. Cada patr\u00f3n se divide en secciones de acuerdo con la siguiente plantilla. La plantilla confiere una estructura uniforme a la informaci\u00f3n, lo que facilita el aprendizaje, la comparaci\u00f3n y el uso de los patrones de dise\u00f1o. <\/p>\n\n

      \n
    • Nombre y clasificaci\u00f3n del patr\u00f3n: El nombre transmite sucintamente la esencia del patr\u00f3n. Una buena reputaci\u00f3n es vital porque pasar\u00e1 a formar parte de su vocabulario de dise\u00f1o. La clasificaci\u00f3n del patr\u00f3n refleja el esquema que introducimos en la secci\u00f3n 1.5. <\/li>\n\n\n\n
    • Intenci\u00f3n: Una breve declaraci\u00f3n que responda a las siguientes preguntas: \u00bfQu\u00e9 hace el patr\u00f3n de dise\u00f1o? \u00bfCu\u00e1l es su raz\u00f3n de ser y su objetivo? \u00bfQu\u00e9 cuesti\u00f3n o problema de dise\u00f1o concreto aborda? <\/li>\n\n\n\n
    • Tambi\u00e9n conocido como Otros nombres conocidos para el patr\u00f3n, si los hay. <\/li>\n\n\n\n
    • Motivaci\u00f3n: Un escenario que ilustra un problema de dise\u00f1o y c\u00f3mo las estructuras de clases y objetos del patr\u00f3n resuelven el problema. El sistema le ayudar\u00e1 a comprender la descripci\u00f3n m\u00e1s abstracta del siguiente patr\u00f3n. <\/li>\n\n\n\n
    • Aplicabilidad: \u00bfEn qu\u00e9 situaciones puede aplicarse el patr\u00f3n de dise\u00f1o? \u00bfCu\u00e1les son los ejemplos de dise\u00f1os deficientes que el patr\u00f3n puede solucionar? \u00bfC\u00f3mo puede reconocer estas situaciones? <\/li>\n\n\n\n
    • Estructura: Una representaci\u00f3n gr\u00e1fica de las clases del patr\u00f3n utilizando una notaci\u00f3n basada en la T\u00e9cnica de Modelado de Objetos (OMT) [RBP+91]. Tambi\u00e9n utilizamos diagramas de interacci\u00f3n [JCJO92, Boo94] para ilustrar secuencias de peticiones y colaboraciones entre objetos. El ap\u00e9ndice B describe estas notaciones en detalle. <\/li>\n\n\n\n
    • Participantes: Las clases y\/u objetos que participan en el patr\u00f3n de dise\u00f1o y sus responsabilidades.<\/li>\n\n\n\n
    • Colaboraciones: C\u00f3mo colaboran los participantes para llevar a cabo sus responsabilidades. <\/li>\n\n\n\n
    • Consecuencias: \u00bfC\u00f3mo apoya el patr\u00f3n sus objetivos? \u00bfCu\u00e1les son las contrapartidas y los resultados de utilizar el patr\u00f3n? \u00bfQu\u00e9 aspecto de la estructura del sistema le permite variar de forma independiente? <\/li>\n\n\n\n
    • Implementaci\u00f3n: \u00bfQu\u00e9 escollos, pistas o t\u00e9cnicas debe conocer a la hora de aplicar el patr\u00f3n? \u00bfExisten problemas espec\u00edficos del lenguaje? <\/li>\n\n\n\n
    • C\u00f3digo de ejemplo: Fragmentos que ilustran c\u00f3mo podr\u00eda implementar el patr\u00f3n en C++ o Smalltalk.<\/li>\n\n\n\n
    • Usos conocidos: Ejemplos del patr\u00f3n encontrados en sistemas reales. Incluimos al menos dos ejemplos de dominios diferentes. <\/li>\n\n\n\n
    • Patrones relacionados: \u00bfQu\u00e9 patrones de dise\u00f1o est\u00e1n estrechamente relacionados con \u00e9ste? \u00bfCu\u00e1les son las diferencias esenciales? \u00bfQu\u00e9 otros patrones deber\u00edan utilizarse con \u00e9ste? <\/li>\n<\/ul>\n\n

      C\u00f3mo resuelven los patrones de dise\u00f1o los problemas de dise\u00f1o<\/strong><\/p>\n\n

      Los patrones de dise\u00f1o resuelven los problemas de dise\u00f1o encontrando los objetos apropiados; los patrones de dise\u00f1o le ayudan a identificar las abstracciones menos obvias y los objetos que pueden capturarlas. Los patrones de dise\u00f1o tambi\u00e9n determinan la granularidad de los objetos; los patrones de dise\u00f1o describen c\u00f3mo representar subsistemas completos como objetos y soportar un gran n\u00famero de objetos en las granularidades m\u00e1s finas. Los patrones de dise\u00f1o le ayudan a definir las interfaces identificando sus elementos esenciales y los tipos de datos que se env\u00edan a trav\u00e9s de una interfaz. Un patr\u00f3n de dise\u00f1o tambi\u00e9n puede indicarle lo que no debe poner en la interfaz. <\/p>\n\n

      Cita favorita del cap\u00edtulo: \u00abLos patrones de clase Creativos difieren alguna parte de la creaci\u00f3n del objeto a las subclases, mientras que los patrones de objeto Creativos la difieren a otro objeto. Los patrones de clase Estructurales utilizan la herencia para componer clases, mientras que los patrones de objetos Estructurales describen formas de ensamblar objetos. Los patrones de clase Comportamiento utilizan la herencia para describir algoritmos y flujos de control, mientras que los patrones de objeto Comportamiento describen c\u00f3mo coopera un grupo de objetos para realizar una tarea que ning\u00fan objeto por s\u00ed solo puede llevar a cabo <\/em><\/strong><\/p>\n\n

      solo\u00bb.<\/em><\/strong><\/p>\n\n

      Cap\u00edtulo 2: Un estudio de caso: Dise\u00f1ar un editor de documentos<\/strong><\/p>\n\n

      \"\"<\/figure>\n\n

      Estructura del documento<\/strong><\/p>\n\n

      Un documento dispone elementos gr\u00e1ficos esenciales como caracteres, l\u00edneas, pol\u00edgonos y otras formas. Estos elementos capturan el contenido total de informaci\u00f3n del documento. Sin embargo, estos elementos no se ven en t\u00e9rminos gr\u00e1ficos sino en t\u00e9rminos de la estructura f\u00edsica del documento: l\u00edneas, columnas, figuras, tablas y otras subestructuras. A su vez, estas subestructuras tienen sus subestructuras, y as\u00ed sucesivamente. La interfaz de usuario de Lexi debe permitir a los usuarios manipular directamente estas subestructuras. Por ejemplo, un usuario deber\u00eda poder tratar un diagrama como una unidad en lugar de como una colecci\u00f3n de primitivas gr\u00e1ficas individuales. El usuario deber\u00eda poder referirse a una tabla como un todo, no como una masa informe de texto y gr\u00e1ficos. Eso ayuda a que la interfaz sea sencilla e intuitiva. <\/p>\n\n

      Formateo<\/strong><\/p>\n\n

      Tras encontrar una forma de representar la estructura f\u00edsica del documento, debe averiguar c\u00f3mo construir una estructura f\u00edsica determinada. Una que se corresponda con un documento formateado correctamente. La representaci\u00f3n y el formateo son distintos: la capacidad de captar la estructura f\u00edsica del documento no nos dice c\u00f3mo llegar a un sistema concreto. Esta responsabilidad recae principalmente en Lexi. <\/p>\n\n

      Encapsular el algoritmo de formateo:<\/strong> Con todas sus limitaciones y detalles, el proceso de formateo no es f\u00e1cil de automatizar. Hay muchos enfoques del problema, y la gente ha desarrollado varios algoritmos de formateo con diferentes puntos fuertes y d\u00e9biles. Dado que Lexi es un editor \u00ablo que ves es lo que obtienes\u00bb, una compensaci\u00f3n necesaria a tener en cuenta es el equilibrio entre la calidad del formateo y la velocidad de formateo. Dado que los algoritmos de formateo tienden a ser complejos, es deseable mantenerlos bien contenidos o -mejor a\u00fan- completamente independientes de la estructura del documento. Lo ideal ser\u00eda poder a\u00f1adir un nuevo tipo de subclase Glifo sin tener en cuenta el algoritmo de formateo. A la inversa, a\u00f1adir un nuevo algoritmo de formateo no deber\u00eda requerir modificar los glifos existentes. <\/p>\n\n

      Patr\u00f3n Estrategia:<\/strong> Encapsular un algoritmo en un objeto es la intenci\u00f3n del patr\u00f3n Estrategia. Los participantes clave en el patr\u00f3n son los objetos Estrategia, que encapsulan diferentes algoritmos y el contexto en el que operan. Los compositores son estrategias; encapsulan diferentes algoritmos de formato. La composici\u00f3n es el contexto de una estrategia de compositor. La clave para aplicar el patr\u00f3n Estrategia es dise\u00f1ar interfaces para el sistema y su contexto que sean lo suficientemente generales como para admitir una serie de algoritmos. <\/p>\n\n

      Embellecer la interfaz de usuario<\/strong><\/p>\n\n

      Considere dos adornos en la interfaz de usuario de Lexi. El primero a\u00f1ade un borde alrededor del \u00e1rea de edici\u00f3n de texto para delimitar la p\u00e1gina de texto. El segundo a\u00f1ade barras de desplazamiento que permiten al usuario ver distintas partes de la p\u00e1gina. Para facilitar la adici\u00f3n y eliminaci\u00f3n de estos adornos (especialmente en tiempo de ejecuci\u00f3n), no debe utilizar la herencia para a\u00f1adirlos a la interfaz de usuario. Conseguiremos la m\u00e1xima flexibilidad si otros objetos de la interfaz de usuario ni siquiera saben que los adornos est\u00e1n ah\u00ed. Eso nos permitir\u00e1 a\u00f1adir y eliminar los adornos sin cambiar otras clases. <\/p>\n\n

      Desde el punto de vista de la programaci\u00f3n, embellecer la interfaz de usuario implica ampliar el c\u00f3digo existente. Utilizar la herencia para realizar dicha ampliaci\u00f3n impide reordenar los embellecimientos en tiempo de ejecuci\u00f3n, pero un problema igualmente grave es la explosi\u00f3n de clases resultante de un enfoque basado en la herencia. <\/p>\n\n

      Patr\u00f3n Decorador:<\/strong> El patr\u00f3n Decorador (196) captura las relaciones entre clases y objetos que admiten el embellecimiento mediante el cerramiento transparente. El t\u00e9rmino \u00abembellecimiento\u00bb tiene un significado m\u00e1s amplio del que hemos considerado aqu\u00ed. En el patr\u00f3n Decorador, el embellecimiento se refiere a cualquier cosa que a\u00f1ada responsabilidades a un objeto. <\/p>\n\n

      Cita favorita: \u00abLa elecci\u00f3n de la representaci\u00f3n interna del documento afecta a casi todos los aspectos del dise\u00f1o de Lexi\u00bb.<\/em><\/strong><\/p>\n\n

      Cap\u00edtulo 3: Patrones de creaci\u00f3n<\/strong><\/p>\n\n

      \"\"<\/figure>\n\n

      Los patrones de dise\u00f1o de creaci\u00f3n abstraen el proceso de instanciaci\u00f3n. Ayudan a que un sistema sea independiente de c\u00f3mo se crean, componen y representan sus objetos. Un patr\u00f3n de creaci\u00f3n de clases utiliza la herencia para variar la clase instanciada, mientras que un patr\u00f3n de creaci\u00f3n de objetos delegar\u00e1 la instanciaci\u00f3n en otro objeto. <\/p>\n\n

      Los patrones de creaci\u00f3n se vuelven esenciales a medida que los sistemas dependen m\u00e1s de la composici\u00f3n de objetos que de la herencia de clases. A medida que eso sucede, el \u00e9nfasis se desplaza de la codificaci\u00f3n r\u00edgida de un conjunto fijo de comportamientos hacia la definici\u00f3n de un grupo m\u00e1s peque\u00f1o de comportamientos fundamentales que pueden componerse de otros m\u00e1s complejos. As\u00ed, la creaci\u00f3n de objetos con comportamientos espec\u00edficos requiere algo m\u00e1s que la simple instanciaci\u00f3n de una clase. <\/p>\n\n

      Hay dos temas recurrentes en estos patrones. En primer lugar, todos ellos encapsulan el conocimiento sobre las clases concretas que utiliza el sistema. En segundo lugar, ocultan c\u00f3mo se crean y juntan las instancias de estas clases. Todo lo que el sistema en general sabe sobre los objetos son sus interfaces definidas por clases abstractas. Los patrones creativos a veces pueden ser competidores. Es decir, hay casos en los que tanto Prototipo como F\u00e1brica Abstracta podr\u00edan utilizarse de forma provechosa. Otras veces son complementarios: El constructor puede utilizar uno de los distintos patrones para implementar qu\u00e9 componentes se construyen. El prototipo puede utilizar Singleton en su implementaci\u00f3n. Los patrones creativos incluyen; <\/p>\n\n

      F\u00e1brica abstracta:<\/strong> Proporcionan una interfaz para crear familias de objetos relacionados o dependientes sin especificar sus clases concretas.<\/p>\n\n

      Constructor: Separe la construcci\u00f3n de un objeto complejo de su representaci\u00f3n para que el mismo proceso de construcci\u00f3n pueda crear expresiones diferentes.<\/p>\n\n

      M\u00e9todo de f\u00e1brica:<\/strong> Define una interfaz para crear un objeto pero deja que las subclases decidan qu\u00e9 clase instanciar. El m\u00e9todo de f\u00e1brica permite a una clase diferir la instanciaci\u00f3n a las subclases. <\/p>\n\n

      Prototipo:<\/strong> Especifique los tipos de objetos a crear utilizando una instancia protot\u00edpica, y cree cosas nuevas copiando este prototipo.<\/p>\n\n

      Singleton:<\/strong> Garantizar que una clase s\u00f3lo tiene una instancia y proporcionar un punto de acceso global a la misma.<\/p>\n\n

      Cita favorita del cap\u00edtulo: \u00abHay dos temas recurrentes en estos patrones. En primer lugar, todos ellos encapsulan conocimientos sobre las clases concretas que utiliza el sistema. En segundo lugar, ocultan c\u00f3mo se crean y se juntan las instancias de estas clases\u00bb.<\/em><\/strong><\/p>\n\n

      Cap\u00edtulo 4: Patrones estructurales<\/strong><\/p>\n\n

      Los patrones estructurales se ocupan de c\u00f3mo se componen las clases y los objetos para formar estructuras mayores. Los patrones estructurales de clases utilizan la herencia para reunir interfaces o implementaciones. Como ejemplo sencillo, considere c\u00f3mo <\/p>\n\n

      Los estamentos m\u00faltiples mezclan dos o m\u00e1s clases en una. El resultado es una clase que combina las propiedades de sus clases padre. Este patr\u00f3n es \u00fatil para hacer que bibliotecas de clases desarrolladas de forma independiente funcionen juntas. Otro ejemplo es la forma de clase del patr\u00f3n Adaptador. Generalmente, un adaptador hace que una interfaz se ajuste a otra, proporcionando una abstracci\u00f3n uniforme de diferentes interfaces. Un adaptador de clase lo consigue heredando de forma privada de una clase adaptadora. El adaptador expresa entonces su interfaz en t\u00e9rminos de los adaptados. Los patrones de objetos estructurales describen formas de componer objetos para realizar nuevas funcionalidades. La flexibilidad a\u00f1adida de la composici\u00f3n de objetos proviene de la capacidad de cambiar el documento en tiempo de ejecuci\u00f3n, lo que es imposible con la composici\u00f3n de clases est\u00e1ticas. Un patr\u00f3n de objeto estructural describe la construcci\u00f3n de una jerarqu\u00eda de clases para dos tipos de objetos: primitivos y compuestos. Los objetos compuestos le permiten componer objetos primitivos y otros objetos compuestos en estructuras arbitrariamente complejas. A continuaci\u00f3n se detallan los patrones estructurales que debe conocer; <\/p>\n\n

      Adaptador:<\/strong> Convierte la interfaz de una clase en otra interfaz que esperan los clientes. El adaptador permite que funcionen juntas clases que de otro modo no podr\u00edan debido a interfaces incompatibles. <\/p>\n\n

      Puente:<\/strong> Desacoplar una abstracci\u00f3n de su implementaci\u00f3n para que ambas puedan variar de forma independiente.<\/p>\n\n

      Componer:<\/strong> Componga objetos en estructuras de \u00e1rbol para representar jerarqu\u00edas parte-todo. Composite permite a los clientes tratar de manera uniforme los objetos individuales y las composiciones de objetos. <\/p>\n\n

      Decorador: Adjunta responsabilidades adicionales a un objeto de forma din\u00e1mica. Los decoradores proporcionan una alternativa flexible a la subclase para ampliar la funcionalidad. <\/p>\n\n

      Fachada:<\/strong> Proporcionar una interfaz unificada a un conjunto de interfaces de un subsistema. Una fachada define una interfaz de nivel superior que facilita el uso del subsistema. <\/p>\n\n

      Peso mosca:<\/strong> Utilice la compartici\u00f3n para soportar un gran n\u00famero de objetos de grano fino de forma eficiente.<\/p>\n\n

      Proxy:<\/strong> Proporcionar un sustituto o marcador de posici\u00f3n de otro objeto para controlar el acceso al mismo.<\/p>\n\n

      \n Cita favorita: \u00abEn lugar de componer interfaces o implementaciones, los patrones de objetos estructurales describen formas de componer objetos para realizar nuevas funcionalidades<\/em>\n<\/strong>.\u00bb<\/p>\n\n

      Cap\u00edtulo 5: Patrones de comportamiento<\/strong><\/p>\n\n

      \"\"<\/figure>\n\n

      Los patrones de comportamiento tienen que ver con los algoritmos y la asignaci\u00f3n de responsabilidades entre objetos.<\/p>\n\n

      Los patrones de comportamiento no s\u00f3lo describen patrones de objetos o clases, sino tambi\u00e9n los patrones de comunicaci\u00f3n entre ellos. Estos patrones caracterizan el flujo de control complejo que es dif\u00edcil de seguir en tiempo de ejecuci\u00f3n. Desv\u00edan su atenci\u00f3n del flujo de control para permitirle concentrarse s\u00f3lo en c\u00f3mo est\u00e1n interconectados los objetos. Los patrones de clases de comportamiento utilizan la herencia para distribuir el comportamiento entre las clases. Este cap\u00edtulo incluye dos de estos patrones. El m\u00e9todo de plantilla (360) es el m\u00e1s sencillo y com\u00fan de los dos. Un m\u00e9todo de plantilla es una definici\u00f3n abstracta de un algoritmo. Define el algoritmo paso a paso. Cada paso invoca una operaci\u00f3n abstracta o una operaci\u00f3n primitiva. Una subclase da cuerpo al algoritmo definiendo las operaciones abstractas. El otro patr\u00f3n de clase conductual es Int\u00e9rprete (274), que representa la gram\u00e1tica como una jerarqu\u00eda de clases e implementa un int\u00e9rprete como una operaci\u00f3n sobre instancias de estas clases. Los patrones de comportamiento de objetos utilizan la composici\u00f3n de objetos en lugar de la herencia. Algunos describen c\u00f3mo un grupo de objetos pares coopera para realizar una tarea que ning\u00fan objeto por s\u00ed solo puede llevar a cabo. Una cuesti\u00f3n importante aqu\u00ed es c\u00f3mo los objetos pares se conocen entre s\u00ed. Los pares podr\u00edan mantener referencias expl\u00edcitas entre s\u00ed, lo que aumentar\u00eda su acoplamiento. En el extremo, cada objeto sabr\u00eda de todos los dem\u00e1s. El patr\u00f3n Mediador (305) evita esto introduciendo un objeto mediador entre los pares. El mediador proporciona la indirecci\u00f3n necesaria para un acoplamiento laxo. Estos son algunos de los patrones de comportamiento; <\/p>\n\n

      Int\u00e9rprete: Dado un lenguaje, defina una representaci\u00f3n para su gram\u00e1tica y un int\u00e9rprete que utilice la representaci\u00f3n para interpretar las frases del lenguaje.<\/p>\n\n

      Petici\u00f3n:<\/strong> Encapsula una solicitud como un objeto, lo que le permite parametrizar clientes con diferentes solicitudes, poner en cola o registrar solicitudes y admitir operaciones que se pueden deshacer.<\/p>\n\n

      Iterador:<\/strong> Proporcionan una forma de acceder secuencialmente a los elementos de un objeto agregado sin exponer su representaci\u00f3n subyacente.<\/p>\n\n

      Mediador: Define un objeto que encapsula c\u00f3mo interact\u00faa un conjunto de objetos. Mediador promueve el acoplamiento suelto al evitar que los objetos se refieran expl\u00edcitamente entre s\u00ed y permitirle variar su interacci\u00f3n de forma independiente. <\/p>\n\n

      Memento:<\/strong> Sin violar la encapsulaci\u00f3n, capturar y externalizar el estado interno de un objeto para que el objeto pueda ser restaurado a este estado m\u00e1s tarde.<\/p>\n\n

      Observador: Define una dependencia de uno a muchos entre objetos, de modo que cuando un objeto cambia de estado, todos sus dependientes son notificados y actualizados autom\u00e1ticamente.<\/p>\n\n

      Estado:<\/strong> Permite que un objeto altere su comportamiento cuando cambia su estado interno. El objeto parecer\u00e1 cambiar de clase. <\/p>\n\n

      Estrategia:<\/strong> Definir una familia de algoritmos, encapsular cada uno de ellos y hacerlos intercambiables. La estrategia permite que el algoritmo var\u00ede independientemente de los clientes que lo utilicen. <\/p>\n\n

      Favorito del cap\u00edtulo: Una cuesti\u00f3n importante aqu\u00ed es c\u00f3mo los objetos pares se conocen entre s\u00ed\u00bb.<\/em><\/strong><\/p>\n\n

      C\u00d3MO PUEDE AYUDAR ESTE LIBRO A LOS DESARROLLADORES DE SOFTWARE<\/strong><\/p>\n\n

      El libro \u00abPatrones de dise\u00f1o: Elements of Reusable Object-Oriented Software\u00bb de Erich Gamma, Richard Helm, Ralph Johnson y John Vlissides es una obra seminal en ingenier\u00eda de software que describe 23 patrones de dise\u00f1o para la programaci\u00f3n orientada a objetos. es un libro que puede ayudar a los desarrolladores de software proporcion\u00e1ndoles soluciones reutilizables a problemas de dise\u00f1o comunes en el desarrollo de software orientado a objetos. Estos patrones resuelven problemas comunes de dise\u00f1o y promueven un c\u00f3digo flexible, reutilizable y mantenible. Al comprender y aplicar estos patrones, los desarrolladores de software pueden escribir un c\u00f3digo m\u00e1s eficiente, modular y extensible, m\u00e1s f\u00e1cil de comprender, modificar y mantener a lo largo del tiempo. <\/p>\n","protected":false},"excerpt":{"rendered":"

      Cap\u00edtulo uno: Introducci\u00f3n Dise\u00f1ar software orientado a objetos es complejo, y el software orientado a objetos reutilizable es a\u00fan m\u00e1s dif\u00edcil. Debe encontrar los objetos pertinentes, factorizarlos en clases con la granularidad adecuada, definir interfaces de clase y jerarqu\u00edas de herencia, y establecer relaciones clave entre ellos. Su dise\u00f1o debe ser espec\u00edfico para el problema […]<\/p>\n","protected":false},"author":1,"featured_media":17499,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"_themeisle_gutenberg_block_has_review":false,"_jet_sm_ready_style":"","_jet_sm_style":"","_jet_sm_controls_values":"","_jet_sm_fonts_collection":"","_jet_sm_fonts_links":"","footnotes":""},"categories":[101],"tags":[],"writer":[],"class_list":["post-19925","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-club-del-libro"],"_links":{"self":[{"href":"https:\/\/devologyx.io\/es\/wp-json\/wp\/v2\/posts\/19925","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/devologyx.io\/es\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/devologyx.io\/es\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/devologyx.io\/es\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/devologyx.io\/es\/wp-json\/wp\/v2\/comments?post=19925"}],"version-history":[{"count":1,"href":"https:\/\/devologyx.io\/es\/wp-json\/wp\/v2\/posts\/19925\/revisions"}],"predecessor-version":[{"id":19928,"href":"https:\/\/devologyx.io\/es\/wp-json\/wp\/v2\/posts\/19925\/revisions\/19928"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/devologyx.io\/es\/wp-json\/wp\/v2\/media\/17499"}],"wp:attachment":[{"href":"https:\/\/devologyx.io\/es\/wp-json\/wp\/v2\/media?parent=19925"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/devologyx.io\/es\/wp-json\/wp\/v2\/categories?post=19925"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/devologyx.io\/es\/wp-json\/wp\/v2\/tags?post=19925"},{"taxonomy":"writer","embeddable":true,"href":"https:\/\/devologyx.io\/es\/wp-json\/wp\/v2\/writer?post=19925"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}