En ingeniería de software, los patrones de diseño creacional se ocupan de los mecanismos de creación de objetos, tratando de crear objetos de una manera adecuada a la situación. La forma básica u ordinaria de creación de objetos podría dar lugar a problemas de diseño o complejidad añadida al diseño. Builder Design Pattern en C++ resuelve este problema específico al . separar la construcción de un objeto complejo de su representación Por cierto, si no ha consultado mis otros artículos sobre patrones de diseño creativo, aquí está la lista: Fábrica Constructor Prototipo único Los fragmentos de código que ve a lo largo de esta serie de artículos son simplificados, no sofisticados. Por lo tanto, a menudo me ve sin usar palabras clave como anular, final, público (mientras se hereda) solo para hacer que el código sea compacto y consumible (la mayoría de las veces) en un tamaño de pantalla estándar único. También prefiero struct en lugar de class solo para guardar la línea al no escribir "public:" a veces y también pierdo , constructor, , prefix std::, eliminando la memoria dinámica, intencionalmente. virtual destructor copy constructor También me considero una persona pragmática que quiere transmitir una idea de la manera más simple posible en lugar de la forma estándar o el uso de jergas. Nota: Si tropezó aquí directamente, le sugiero que revise primero, aunque sea trivial. Creo que te animará a explorar más sobre este tema. ¿Qué es el patrón de diseño? Todo el código que encuentra en esta serie de artículos está compilado usando C++20 (aunque en la mayoría de los casos he usado funciones de C++ hasta C++17). Entonces, si no tiene acceso al compilador más reciente, puede usar que también tiene una biblioteca boost preinstalada. moderno https://wandbox.org/ Intención Para crear/crear instancias de objetos complejos y complicados por partes y de manera sucinta al proporcionar una API en una entidad separada. Builder Design Pattern se utiliza cuando queremos construir un objeto complejo. Sin embargo, no queremos tener un miembro constructor complejo o uno que necesite muchos argumentos. El patrón de diseño del constructor construye un objeto complejo paso a paso y el paso final devolverá el objeto. El proceso de construcción de un objeto debe ser genérico para que pueda usarse para crear diferentes representaciones del mismo objeto con la ayuda de una variedad de métodos. La vida sin constructores Supongamos que tiene que crear el generador de HTML usando C ++, entonces una forma muy ingenua de hacerlo es: text = ; output; output += ; output += text; output += ; ( , text); words[] = { , }; oss; oss << ; ( w : words) oss << << w << ; oss << ; (oss.str().c_str()); // hello auto "hello" string "" "" printf "%s" // <ul><li>hello</li><li>world</li></ul> string "hello" "world" ostringstream "<ul>" for auto " <li>" "</li>" "</ul>" printf Un desarrollador sofisticado creará una clase con un montón de argumentos y métodos de construcción para agregar un nodo secundario. Sin embargo, este es un buen enfoque, pero puede complicar la representación del objeto. En general, algunos objetos son simples y se pueden crear en una sola llamada de constructor, mientras que otros objetos requieren muchas ceremonias para crear. Tener un objeto con 10 argumentos constructores no es productivo. En su lugar, deberíamos optar por la construcción por partes. Builder proporciona una API para construir un objeto paso a paso sin revelar la representación real del objeto. Ejemplo de patrón de diseño de constructor en C++ moderno m_name; m_text; <HtmlElement> m_childs; m_indent_size = ; HtmlElement() = ; HtmlElement( &name, &text) : m_name(name), m_text(text) {} : { oss; oss << (m_indent_size * indent, ) << << m_name << << ; (m_text.size()) oss << (m_indent_size * (indent + ), ) << m_text << ; ( &element : m_childs) oss << element.str(indent + ); oss << (m_indent_size * indent, ) << << m_name << << ; oss.str(); } <HtmlBuilder> build( root_name) { make_unique<HtmlBuilder>(root_name); } }; HtmlElement m_root; : HtmlBuilder( root_name) { m_root.m_name = root_name; } { m_root.m_childs.emplace_back(HtmlElement{child_name, child_text}); ; } { m_root.str(); } { m_root; } }; { builder = HtmlElement::build( ); builder->add_child( , )->add_child( , ); << builder->str() << ; EXIT_SUCCESS; } ; class HtmlBuilder { class HtmlElement string string vector constexpr static size_t 4 default const string const string friend ; class HtmlBuilder public string str ( indent = ) int32_t 0 ostringstream string ' ' "<" ">" endl if string 1 ' ' endl for auto 1 string ' ' "</" ">" endl return static unique_ptr string return { class HtmlBuilder public string HtmlBuilder * add_child ( child_name, child_text) string string return this string str () return operator HtmlElement () return int main () auto "ul" "li" "hello" "li" "world" cout endl return /* <ul> <li> hello </li> <li> world </li> </ul> */ Estamos obligando a los usuarios aquí a usar el constructor al hacer que los datos de los miembros de HtmlElements sean privados. Como puede ver, hemos declarado HtmlBuilder y HtmlElement en el mismo archivo y, para hacerlo, necesitamos una declaración directa, es decir, clase HtmlBuilder; ya que es un . Y no podemos crear el objeto de tipo incompleto antes de que el compilador analice su declaración real. La razón es simple, el compilador necesita el tamaño de un objeto para asignarle memoria. Por lo tanto, el puntero es la única forma de evitarlo, por lo que hemos tomado <HtmlBuilder>. tipo incompleto unique_ptr Ejemplo de patrón de diseño de constructor sofisticado y fluido A continuación se muestra el ejemplo más sofisticado del patrón de diseño de generador en C++ organizado en cuatro archivos diferentes (es decir, Person.h, Person.cpp, PersonBuilder.h PersonBuilder.cpp). Persona.h ; :: m_name, m_street_address, m_post_code, m_city; :: m_company_name, m_position, m_annual_income; Person( :: name) : m_name(name) {} : ostream& <<(ostream& os, Person& obj); ; }; # once pragma # include <iostream> using namespace std ; class PersonBuilder { class Person std string // Personal Detail std string // Employment Detail std string public friend ; class PersonBuilder friend operator const PersonBuilder static create ( :: name) std string Persona.cpp PersonBuilder Person::create( name) { PersonBuilder{name}; } ostream& <<(ostream& os, Person& obj) { os << obj.m_name << :: << << :: << << obj.m_street_address << << obj.m_post_code << << obj.m_city << :: << << :: << << obj.m_company_name << << obj.m_position << << obj.m_annual_income; } # include <iostream> # include "Person.h" # include "PersonBuilder.h" string return operator const return std endl "lives : " std endl "at " " with postcode " " in " std endl "works : " std endl "with " " as a " " earning " Como puede ver en el ejemplo anterior, la persona puede tener muchos detalles como Personal y Profesional. Y también lo hace el recuento de miembros de datos. En nuestro caso, hay 7 miembros de datos. Tener una sola clase para todas las acciones necesarias para crear una Persona a través del constructor podría hacer que nuestra clase se hinche y pierda su propósito original. Además, el usuario de la biblioteca debe cuidar toda la secuencia de parámetros del constructor. PersonBuilder.h Person person; : PersonBuilder( name) : person(name) {} { move(person); } ; ; ; ; ; ; ; ; }; # once pragma # include "Person.h" { class PersonBuilder public string operator Person () const return PersonBuilder& lives () PersonBuilder& at ( :: street_address) std string PersonBuilder& with_postcode ( :: post_code) std string PersonBuilder& in ( :: city) std string PersonBuilder& works () PersonBuilder& with ( company_name) string PersonBuilder& as_a ( position) string PersonBuilder& earning ( annual_income) string PersonBuilder.cpp PersonBuilder& PersonBuilder::lives() { * ; } PersonBuilder& PersonBuilder::works() { * ; } PersonBuilder& PersonBuilder::with( company_name) { person.m_company_name = company_name; * ; } PersonBuilder& PersonBuilder::as_a( position) { person.m_position = position; * ; } PersonBuilder& PersonBuilder::earning( annual_income) { person.m_annual_income = annual_income; * ; } PersonBuilder& PersonBuilder::at( :: street_address) { person.m_street_address = street_address; * ; } PersonBuilder& PersonBuilder::with_postcode( :: post_code) { person.m_post_code = post_code; * ; } PersonBuilder& PersonBuilder::in( :: city) { person.m_city = city; * ; } # include "PersonBuilder.h" return this return this string return this string return this string return this std string return this std string return this std string return this En lugar de incluir todas esas API relacionadas con la construcción en Person, podemos delegar esa tarea a una entidad separada, es decir, PersonBuilder. Principal.cpp ; { Person p = Person::create( ) .lives() .at( ) .with_postcode( ) .in( ) .works() .with( ) .as_a( ) .earning( ); < # include "Person.h" # include "PersonBuilder.h" using namespace std int main () "John" "123 London Road" "SW1 1GB" "London" "PragmaSoft" "Consultant" "10e6" cout endl return ¿No es la construcción anterior un inglés más intuitivo, natural y sencillo? Si le preocupan los métodos en blanco como vidas() y obras(), no se preocupe, se eliminarán en la optimización. También puede observar que estamos obligando a los usuarios a usar el constructor en lugar del constructor haciendo que el constructor sea privado y exponiendo solo la API de creación std::string name . ( ) No compliques demasiado las cosas diseñando una interfaz o clases abstractas a menos que lo necesites. He visto esto en muchos ejemplos de patrones de diseño de constructores en la Web. Beneficios del patrón de diseño del generador El número de líneas de código aumenta al menos al doble en el patrón de construcción. Pero el esfuerzo vale la pena en términos de flexibilidad de diseño, menos o ningún parámetro para el constructor y un código mucho más legible. Builder Design Pattern también ayuda a minimizar la cantidad de parámetros en el constructor y, por lo tanto, no es necesario pasar para los parámetros opcionales al constructor. nulo Los objetos inmutables se pueden construir sin mucha lógica compleja en el proceso de construcción de objetos. Separar la construcción de la hace que la representación de objetos se divida y sea precisa. Tener una entidad constructora separada brinda la flexibilidad de crear e instanciar diferentes representaciones de objetos. representación de objetos Resumen por preguntas frecuentes ¿Cuándo se debe utilizar el patrón de diseño del constructor? Siempre que la creación de un nuevo objeto requiera configurar muchos parámetros y algunos de ellos (o todos ellos) son opcionales. ¿Por qué necesitamos una clase Builder cuando implementamos un patrón de diseño Builder? No es necesario, pero hay algunos beneficios al hacerlo: La preocupación del objeto de construcción debe estar en la entidad separada según . SRP El objeto original no estaría hinchado. Código fácil y mantenible. Probar y comprender un constructor con muchos argumentos de entrada se vuelve exponencialmente más complicado. ¡La mayor ventaja del patrón de diseño del constructor! Código más expresivo. MiClase o = new MiClase(5, 5.5, 'A', var, 1000, obj9, "hola"); En cambio MiClase o = MiClase.builder().a(5).b(5.5).c('A').d(var).e(1000).f(obj9).g("hola"); Puede ver qué miembro de datos está siendo asignado por qué e incluso cambiar el orden de asignación. ¿Cuál es la diferencia entre Abstract Factory y Builder Design Pattern? Factory produce los objetos al por mayor que podrían ser cualquier objeto de la jerarquía de herencia (como Point, Point2D, Point3D). Mientras que Builder se ocupa de la creación de instancias de un objeto que se limita a un solo objeto (aunque esta afirmación aún es discutible). Verá que Factory tiene que ver con la creación de objetos al por mayor, mientras que el constructor es la creación de objetos por partes. En ambos patrones, puede separar el mecanismo relacionado con la creación de objetos en otras clases. Publicado anteriormente en http://www.vishalchovatiya.com/builder-design-pattern-in-modern-cpp/

BUNCH

www.vishalchovatiya.com

Read My Stories

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

Demasiado Largo; Para Leer

Making security fun one episode at a time

Patrones de diseño: patrón de constructor en C++ moderno

Demasiado Largo; Para Leer

Company Mentioned

Vishal Chovatiya

About Author

ETIQUETAS

Languages

ESTE ARTÍCULO FUE PRESENTADO EN...

Patrones de diseño: patrón de constructor en C++ moderno

Demasiado Largo; Para Leer

Company Mentioned

Vishal Chovatiya

About Author

ETIQUETAS

Languages

ESTE ARTÍCULO FUE PRESENTADO EN...

HISTORIAS RELACIONADAS