Especialmente para el inicio de clases en la nueva corriente del curso "Arquitectura y Patrones de Diseño" he preparado un material de autor más.
Introducción
Cuando se trata de patrones de diseño clásicos, uno no puede evitar pensar en la programación orientada a objetos en sí. Después de todo, los patrones de GoF son exactamente patrones de programación orientados a objetos. La programación funcional tiene sus propios patrones.
En general, todo está organizado de la siguiente manera: existe la propia programación orientada a objetos. Tiene principios. A partir de los principios de la programación orientada a objetos, se siguen los patrones GRASP que analizamos (como opción, principios SOLID), de los cuales, a su vez, se siguen los patrones GoF. De ellos se derivan una serie de cosas interesantes, por ejemplo, patrones empresariales.
Paradigma orientado a objetos
La definición establece que "La programación orientada a objetos es un paradigma de programación en el que el concepto básico es la noción de un objeto que se identifica con el dominio".
Así, el sistema se representa como un conjunto de objetos del área temática, que interactúan entre sí de alguna manera. Cada objeto tiene tres componentes: identidad, estado y comportamiento.
El estado de un objeto es una colección de todos sus campos y sus valores.
El comportamiento de un objeto es la colección de todos los métodos de la clase de un objeto.
La identidad de objeto es lo que distingue a un objeto de clase de otro objeto de clase. Desde una perspectiva de Java, es por identidad que se define el método de igualdad.
Principios de programación orientada a objetos
La programación orientada a objetos tiene varios principios. La idea de su número es diferente. Alguien afirma que hay tres (antigua escuela de programadores), alguien afirma que hay cuatro (nueva escuela de programadores):
- Abstracción
- Encapsulamiento
- Herencia
- Polimorfismo
Propongo hablar sobre ellos con más detalle. Lo único es que sugiero no considerar la abstracción, porque me considero en la vieja escuela de programadores.
Encapsulamiento
Contrario a la opinión de muchos entrevistados (ya veces entrevistados), la encapsulación no es "cuando todos los campos son privados". La encapsulación es el principio más fundamental del diseño de software, sus rastros se observan solo a nivel micro, pero también a nivel de diseño macro.
La definición científica dice que "la encapsulación es el principio de que cualquier clase y, en un sentido más amplio, cualquier parte del sistema debe considerarse como una" caja negra ": el usuario de una clase o subsistema solo debe ver la interfaz (es decir, una lista de propiedades y métodos declarados ) y no ahondar en la implementación interna ".
Así, resulta que si la clase A accede directamente a los campos de la clase B, esto no conduce al hecho de que "se viola la seguridad de la información", sino al hecho de que la clase A está ligada al dispositivo interno de la clase B, y un intento de cambiar la estructura interna de la clase B dará lugar a un cambio en la clase A. Además, la clase A no solo funciona con campos de la clase B, funciona de acuerdo con alguna lógica empresarial. Es decir, la lógica para trabajar con el estado de la clase B está en la clase A, y cuando queremos reutilizar la clase B, esto no se puede hacer, porque sin una pieza de la clase A, la clase B puede ser inútil, lo que llevará a que la clase B se tenga que dar junto con clase A. Extrapolando esto a todo el sistema, resulta que solo se puede reutilizar todo el sistema.
La encapsulación es el principio que más se pasa por alto y, lamentablemente, pocas personas lo interpretan correctamente. Le permite minimizar el número de enlaces entre clases y subsistemas y, en consecuencia, simplificar la implementación y modificación independiente de clases y subsistemas.
Herencia
La herencia es la capacidad de derivar una clase de otra conservando todas las propiedades y métodos de la clase antecesora (superclase), agregando nuevas propiedades y
métodos si es necesario .
La herencia es el principio más sobrevalorado. Alguna vez se creyó que "Para un programador ideal, el árbol de herencia va al infinito y termina en un objeto absolutamente vacío", porque una vez la gente no entendía muy bien que la herencia es una forma de expresar una propiedad del mundo real como la jerarquía, y no una forma reutiliza el código heredando la máquina del frigorífico, porque ambos elementos tienen un asa. Es deseable evitar la herencia siempre que sea posible, porque la herencia es una relación muy fuerte. Para reducir el número de niveles de herencia, se recomienda construir un árbol "de abajo hacia arriba".
Polimorfismo
El polimorfismo es la capacidad de utilizar clases descendientes en un contexto destinado a la clase antecesora.
Detrás de la definición más sádica se encuentra la capacidad del lenguaje de programación para descomponer una tarea y refactorizar if's y switches.
