Los patrones creativos fueron descritos por primera vez en el famoso Gang of Four El libro presenta cada patrón en un capítulo dedicado y sigue una estructura estricta para cada uno: intención, motivación, aplicabilidad, estructura, participantes, colaboraciones, consecuencias, implementación, códigos de muestra, usos conocidos y patrones relacionados. Diseño de patrones Por ejemplo, aquí hay un resumen de la El patrón: constructor 
 
 
 
 
 
 Intento de: Separar la construcción de un objeto complejo de su representación para que el mismo proceso de construcción pueda crear diferentes representaciones. La aplicabilidad : Utilice el patrón de constructor cuando 
 
 
 El algoritmo para crear un objeto complejo debe ser independiente de las Partes que componen el objeto y de cómo están montados. El proceso de construcción debe permitir diferentes representaciones para el objeto que se construye. : Intent Separar la construcción de un objeto complejo de su representación para que el mismo proceso de construcción pueda crear diferentes representaciones. : Applicability Utilice el patrón de constructor cuando 
 
 
 El algoritmo para crear un objeto complejo debe ser independiente de las Partes que componen el objeto y de cómo están montados. El proceso de construcción debe permitir diferentes representaciones para el objeto que se construye. El GoF (Gang of Four) ha sido fundamental en el dominio de la programación orientada a objetos y ha influido en el diseño de los lenguajes de programación, incluidos los generalizados como Java. Como estoy de vuelta en una posición de ingeniería, me encuentro con código Java recién escrito que tiene mucho potencial de mejora en cuanto a mantenimiento. Funciona, pero imagino que los ingenieros tienen que actualizarlo, incluyendo el futuro yo del autor original y yo, y estoy seguro de que puedo ayudarlos. Esta semana, he refactorizado el código usando patrones creativos para mejorar su mantenimiento. Un constructor con muchos parámetros del mismo tipo. Imaginemos un constructor con muchos parámetros de String: public License (
    String id, String licenseeName,
    String licenseId, String environment,
    LocalDateTime generatedAt
)
 Al llamar a este constructor, es probable que el llamador pueda cambiar involuntariamente las órdenes de parámetros: var license = new License("My license", "XXX-123", "Customer", "User-acceptance tests", new LocalDateTime());
 Oops, he cambiado el nombre del licenciatario y el ID de la licencia. tu IDE puede ayudar aquí, pero hay otras maneras. Tipos de Wrappers Los partidarios de la OOP pura señalarán felizmente que nunca se debe usar directamente una cadena. y Java : El E.G. record public record Id(String id) { ... }
public record LicenseeName(String licenseeName) { ... }
public record LicenseeId(String licenseId) { ... }
public record Environment(String environment) { ... }
public record GeneratedAt(LocalDateTime generatedAt) { ... }
 No podemos cometer un error: var id = new Id("My license");
var licenseeName = new LicenseeName("Customer");
var licenseId = new LicenseeId("XXX-123");
var environment = new Environment("User-acceptance tests");
var generatedAt = new LocalDateTime();

var license = new License(id, licenseId, licenseName, environment, generatedAt); //1
 
 
 Error de tiempo de compilación Si bien este enfoque definitivamente mejora la mantenibilidad, el envoltorio aumenta el tamaño de la memoria. El aumento exacto depende de la implementación de JDK, pero para un único tipo, es alrededor de 5 veces mayor. Kotlin lo hace una brisa al proporcionar : el envasado es un control de tiempo de compilación, pero el bytecode apunta al tipo envasado con la siguiente limitación: Clases de valor inline 
 
 Una clase inline debe tener una única propiedad inicializada en el constructor primario. Una clase inline debe tener una única propiedad inicializada en el constructor primario. Nombres de Parámetros Java sólo ofrece llamadas de método con parámetros de posición, pero otros idiomas, , Python, Kotlin y Rust, también ofrecen parámetros nombrados. El E.G. Aquí está un constructor Kotlin que refleja la clase anterior: class License (
    val id: String, val licenseeName: String,
    val licenseId: String, val environment: String,
    val generatedAt: LocalDateTime
)
 Puede llamar al constructor nombrando los parámetros, reduciendo así los riesgos de cometer un error: val license = License(
    id = "My license", licenseeName = "Customer",
    licenseId = "XXX-123", environment = "User-acceptance tests",
    generatedAt = LocalDateTime()
)
 El patrón constructor El El patrón es otro enfoque viable, aunque no forma parte de los casos de uso descritos en el GoF. constructor Aquí está el código: public class License {

    private final String id;
    private final String licenseeName;
    private final String licenseId;
    private final String environment;
    private final LocalDateTime generatedAt;

    private License (                              //1
        String id, String licenseeName,
        String licenseId, String environment,
        LocalDateTime generatedAt
    ) { ... }
    
    public static LicenseBuilder builder() {       //2
        return new LicenseBuilder();
    }

    public static class LicenseBuilder {

        private String id;                         //3
        private String licenseeName;               //3
        private String licenseId;                  //3
        private String environment;                //3
        private LocalDateTime generatedAt;         //3

        private LicenseBuilder() {}                //1
        
        public LicenseBuilder withId(String id) {  //4
            this.id = id;                          //5
            return this;                           //4
        }
        
        // Other `withXXX` methods
        
        public License build() {                   //6
            return new License(
                id, licenseeName,
                licenseId, environment,
                generatedAt
            );
        }
    }
}
 
 
 
 
 
 
 
 Impedir la instanciación directa de objetos Crear un nuevo constructor Los campos del constructor imitan los campos del objeto Cada método devuelve el objeto del constructor Asignar el atributo Devuelve el objeto completo Ahora se puede llamar al constructor como tal: val license = License.builder()
                     .withId("My license")
                     .withLicenseName("Customer")
                     .withLicenseId("XXX-123")
                     .withEnvironment("User-acceptance tests")
                     .withGeneratedAt(new LocalDateTime())
 Crear el código del constructor es doloroso (a menos que utilice AI), pero permite una mejor legibilidad. Además, se puede añadir validación para cada llamada de método, asegurando que el objeto en construcción sea válido. . Constructor Facetado Resumen 
 
 
 
 
 
 
 
 
 
 Approach 
 Pros 
 Cons 
 
 
 
 
 Type wrappers 
 Object-Oriented Programming 
 - More verbose- Can be memory-heavy depending on the language 
 
 
 
 
 Named parameters 
 Easy 
 Not available in Java 
 
 
 
 
 Builder pattern 
 Verbose 
 - Allows creating complex objects- Allows validating Tipos de envases Programación Orientada a Objetos - Más verbose- Puede ser memoria pesada dependiendo del idioma Nombres de Parámetros fácil No está disponible en Java Construcción de patrones Verbo - Permite crear objetos complejos- Permite validar Los fabricantes lanzan excepciones En la misma base de código, encontré el siguiente código: public Stuff(UuidService uuidService, FallbackUuidService fallbackUuidService) {

    try {
        uuid = uuidService.getUuid();
    } catch(CannotGetUuidException e) {
        try {
            uuid = fallbackUuidService.getUuid();
        } catch(CannotGetUuidException e1) {
            uuid = "UUID can be fetched";
        }
    }
}
 Con un poco de experiencia, puede notar lo que está mal en el fragmento anterior. se inicia con una cadena que no es un UUID. Todo el código que depende de UUID debe tratar con posibles valores no-UUID. Uno debe fallar rápidamente. uuid public Stuff(UuidService uuidService, FallbackUuidService fallbackUuidService) {

    try {
        uuid = uuidService.getUuid();
    } catch(CannotGetUuidException e) {
        try {
            uuid = fallbackUuidService.getUuid();
        } catch(CannotGetUuidException e1) {
            throw new RuntimeException(e1);
        }
    }
}
 Ahora, cada El objeto tiene un UUID válido. Sin embargo, lanzar excepciones dentro de constructores tiene problemas potenciales: Stuff 
 
 
 
 Leaks de recursos: Si el constructor asigna recursos (por ejemplo, archivos, sockets) y lanza una excepción, esos recursos pueden no ser liberados. Herencia: Si un constructor de superclase lanza una excepción, el constructor de subclase no se ejecutará. Excepciones verificadas: es imposible utilizar excepciones verificadas en constructores, solo las de tiempo de ejecución. Por estas razones, creo que las excepciones no tienen su lugar en los constructores y los evito. patrón descrito en la primera sección, pero como se mencionó, es un montón de código; no creo que sea necesario. . constructor Método de fábrica 
 
 
 
 
 
 Intento Define una interfaz para crear un objeto, pero deje que las subclases decidan qué clase instantiar. Aplicaciones Utilice el patrón de método de fábrica cuando: 
 
 
 
 Una clase no puede predecir la clase de objetos que debe crear. una clase quiere que sus subclases especifiquen los objetos que crea. Las clases delegan la responsabilidad a una de varias subclases de ayudantes, y desea localizar el conocimiento de cuál de las subclases de ayudantes es el delegado. Intent Define una interfaz para crear un objeto, pero deje que las subclases decidan qué clase instantiar. Applicability Utilice el patrón de método de fábrica cuando: 
 
 
 
 Una clase no puede predecir la clase de objetos que debe crear. una clase quiere que sus subclases especifiquen los objetos que crea. Las clases delegan la responsabilidad a una de varias subclases de ayudantes, y desea localizar el conocimiento de cuál de las subclases de ayudantes es el delegado. Tenga en cuenta que en este caso, lo usamos por una razón diferente. Aquí está el código actualizado: public class Stuff {

    private final UUID uuid;
    
    private Stuff(UUID uuid) {                               //1
        this.uuid = uuid;
    }

    public static Stuff create(UuidService uuidService, FallbackUuidService fallbackUuidService) throws CannotGetUuidException {
    
        try {
            return new Stuff(uuidService.getUuid());
        } catch(CannotGetUuidException e) {
            return new Stuff(fallbackUuidService.getUuid()); //2
        }
    }
}
 
 
 
 Evitar la instanciación externa Si falla, lanza una nueva CannotGetUuidException Uno llama a lo anterior así: var stuff = Stuff.create(uuidService, fallbackUuidService);  //1
 
 
 Necesito capturar CannotGetUuidException En este punto, estamos seguros de que el objeto está completamente inicializado si la llamada es exitosa. Conclusión En este post, he descrito dos usos de los patrones creativos de GoF, que no se enumeran en el libro: mejorar la mantenibilidad y asegurar que los objetos se inicien completamente. To go further: 
 
 
 
 Padrones de diseño GoF Una inmersión en el patrón de constructor El patrón del constructor es una máquina de estado finito! Originalmente publicado en A Java Geek el 31 de agosto de 2025. El nuevo Java Geek

Read all my posts!

Read My Stories

Follow @nicolas_frankel on Twitter

Este audio es producido en el idioma original de la historia!

Demasiado Largo; Para Leer

Make resilience your competitive advantage

Creación de objetos: los problemas que he enfrentado y los patrones que me han ayudado

About Author

COMENTARIOS

ETIQUETAS

ESTE ARTÍCULO FUE PRESENTADO EN

Related Stories

Una breve introducción a la teoría del cerebro de Boltzmann

La guía completa para una migración exitosa a la nube: estrategias y mejores prácticas

Las capas invisibles: por qué las entrevistas con los usuarios son un activo irremplazable

Crecimiento de las criptomonedas: creación de perfiles de usuarios eficaces

Una breve introducción a la teoría del cerebro de Boltzmann

La guía completa para una migración exitosa a la nube: estrategias y mejores prácticas

Las capas invisibles: por qué las entrevistas con los usuarios son un activo irremplazable

Crecimiento de las criptomonedas: creación de perfiles de usuarios eficaces

Light-Mode

Classic

Newspaper

Dark-Mode

Neon Noir

Minty

HN StartUps