Refactor utilizar Builder o patrón constructor telescópica

Question

Según Effective Java 2ed artículo 2

telescópico patrón constructor, en que proporcione un constructor con sólo los parámetros requeridos, otra con un solo parámetro opcional, un en tercer lugar con dos parámetros opcionales, y así sucesivamente, que culmina en un constructor con todos los parámetros opcionales .

Un ejemplo de constructores de la clase aplicando este patrón es prestado desde el código When would you use the Builder Pattern?

conjunto 1a

Pizza(int size) { ... }   
Pizza(int size, boolean cheese) { ... }  
Pizza(int size, boolean cheese, boolean pepperoni) { ... }  
Pizza(int size, boolean cheese, boolean pepperoni, boolean bacon) { ... } 

tamaño es un parámetro requerido. queso, salchichón y tocino son parámetros opcionales. Supongamos que me gustaría proporcionar el constructor como a continuación.

conjunto de códigos 1b

Pizza(int size) { ... }   
Pizza(int size, boolean cheese) { ... }  
Pizza(int size, boolean pepperoni) { ... }  
Pizza(int size, boolean cheese, boolean pepperoni, boolean bacon, int price, int) { ... } 

Otro ejemplo es que

conjunto de códigos 2

public AttributeKey(String key, Class<T> clazz) 
public AttributeKey(String key, Class<T> clazz) 
public AttributeKey(String key, Class<T> clazz, @Nullable T defaultValue, boolean isNullValueAllowed) 
public AttributeKey(String key, Class<T> clazz, @Nullable T defaultValue, boolean isNullValueAllowed, @Nullable ResourceBundleUtil labels) 

El dos último ejemplo di no seguir el característica ic de telescópico constructor como conjunto de códigos 1a hizo

1. son el código conjunto 1b y 2 incluyen en telescópico constructor? si no, ¿cómo se llama?
2. En comparación con el uso de Builder, cuál (entre el constructor y el patrón de juego de códigos 1a, 2) proporciona más beneficios

Answer 1

En este caso, yo elegiría el constructor o un mecanismo diferente donde la persona que llama puede pasar una colección de ingredientes. Si necesita validar qué toppings están permitidos, puede hacerlo en el constructor o en el setter de Toppings. El enfoque del constructor telescoping/encadenamiento puede requerir que agregue constructores adicionales en el futuro para manejar combinaciones adicionales de ingredientes, mientras que un enfoque de colección manejará cualquier escenario automáticamente. También evitaría tener propiedades específicas en la clase de pizza para diferentes tipos de ingredientes. ¿Qué pasa si necesitas manejar queso extra? Un único cheese booleano no lo manejará. La clase Topping puede ser un objeto completo con subclases, o puede reemplazarlo con solo una cadena.

public class Pizza 
{ 
    // setters don't have to be private... 
    public int Size {get; private set;} 
    private List<Topping> toppings {get; private set;} 

    public Pizza(int size) : this(size, new List<Topping>()) // call the other ctor with an empty list of toppings 
    { 
    } 

    public Pizza(int size, List<Topping> toppings) 
    { 
     Size = size; 
     Toppings = toppings; 
    } 
} 

Answer 2

¿Qué es este patrón de constructors'parameters llama?

Este no es un patrón de diseño per se, pero es una técnica de programación llamada encadenamiento de constructores.

En comparación con el uso de Builder, que se ofrece más beneficios

La misma cuestión de forma: When would you use the Builder Pattern? que ha prestado también explica la diferencia muy bien. En resumen, se prefiere el constructor sobre el encadenamiento de constructores, ya que puede dar como resultado la proliferación de constructores que pueden volverse difíciles de mantener.

Espero que ayude.