При использовании метода цепочки я повторно использую объект или создаю его?

При использовании метода цепочки, как:

var car = new Car().OfBrand(Brand.Ford).OfModel(12345).PaintedIn(Color.Silver).Create();

может быть два подхода:

• Повторно используйте тот же объект, например так:

  public Car PaintedIn(Color color)
  {
      this.Color = color;
      return this;
  }

• Создавайте новый объект типа Carна каждом шаге, например так:

  public Car PaintedIn(Color color)
  {
      var car = new Car(this); // Clone the current object.
      car.Color = color; // Assign the values to the clone, not the original object.
      return car;
  }

Первый ошибся или это скорее личный выбор разработчика?

Я считаю, что его первый подход может быстро вызвать интуитивный / вводящий в заблуждение код. Пример:

// Create a car with neither color, nor model.
var mercedes = new Car().OfBrand(Brand.MercedesBenz).PaintedIn(NeutralColor);

// Create several cars based on the neutral car.
var yellowCar = mercedes.PaintedIn(Color.Yellow).Create();
var specificModel = mercedes.OfModel(99).Create();

// Would `specificModel` car be yellow or of neutral color? How would you guess that if
// `yellowCar` were in a separate method called somewhere else in code?

Есть предположения?

Я бы поместил свободный API в его собственный класс "builder" отдельно от объекта, который он создает. Таким образом, если клиент не хочет использовать свободный API, вы все равно можете использовать его вручную, и он не загрязняет объект домена (придерживаясь принципа единой ответственности). В этом случае будет создано следующее:

• Car который является объектом домена
• CarBuilder который держит свободный API

Использование будет таким:

var car = CarBuilder.BuildCar()
    .OfBrand(Brand.Ford)
    .OfModel(12345)
    .PaintedIn(Color.Silver)
    .Build();

CarBuilderКласс будет выглядеть следующим образом (я использую C # именования , здесь):

public class CarBuilder {

    private Car _car;

    /// Constructor
    public CarBuilder() {
        _car = new Car();
        SetDefaults();
    }

    private void SetDefaults() {
        this.OfBrand(Brand.Ford);
          // you can continue the chaining for 
          // other default values
    }

    /// Starts an instance of the car builder to 
    /// build a new car with default values.
    public static CarBuilder BuildCar() {
        return new CarBuilder();
    }

    /// Sets the brand
    public CarBuilder OfBrand(Brand brand) {
        _car.SetBrand(brand);
        return this;
    }

    // continue with OfModel(...), PaintedIn(...), and so on...
    // that returns "this" to allow method chaining

    /// Returns the built car
    public Car Build() {
        return _car;
    }

}

Обратите внимание, что этот класс не будет потокобезопасным (каждому потоку потребуется собственный экземпляр CarBuilder). Также обратите внимание, что хотя свободный интерфейс API является действительно классной концепцией, он, вероятно, является излишним для создания простых доменных объектов.

Эта сделка более полезна, если вы создаете API для чего-то гораздо более абстрактного и более сложного в настройке и исполнении, поэтому он отлично работает в модульном тестировании и в структурах DI. Вы можете увидеть некоторые другие примеры в разделе Java статьи Википедии о свободном интерфейсе с объектами персистентности, обработки дат и фиктивных объектов.

РЕДАКТИРОВАТЬ:

Как отмечено в комментариях; вы можете сделать класс Builder статическим внутренним классом (внутри Car), и Car можно сделать неизменным. Этот пример того, как автомобиль был неизменным, кажется немного глупым; но в более сложной системе, где вы абсолютно не хотите изменять содержимое построенного объекта, вы можете захотеть это сделать.

Ниже приведен пример того, как сделать статический внутренний класс и обработать создание неизменного объекта, который он создает:

// the class that represents the immutable object
public class ImmutableWriter {

    // immutable variables
    private int _times; private string _write;

    // the "complex" constructor
    public ImmutableWriter(int times, string write) {
        _times = times;
        _write = write;
    }

    public void Perform() {
        for (int i = 0; i < _times; i++) Console.Write(_write + " ");
    }

    // static inner builder of the immutable object
    protected static class ImmutableWriterBuilder {

        // the variables needed to construct the immutable object
        private int _ii = 0; private string _is = String.Empty;

        public void Times(int i) { _ii = i; }

        public void Write(string s) { _is = s; }

        // The stuff is all built here
        public ImmutableWriter Build() {
            return new ImmutableWriter(_ii, _is);
        }

    }

    // factory method to get the builder
    public static ImmutableWriterBuilder GetBuilder() {
        return new ImmutableWriterBuilder();
    }
}

Использование будет следующим:

var writer = ImmutableWriter
                .GetBuilder()
                .Write("peanut butter jelly time")
                .Times(2)
                .Build();

writer.Perform();
// console writes: peanut butter jelly time peanut butter jelly time 

Редактировать 2: Пит в комментариях сделал сообщение в блоге об использовании компоновщиков с лямбда-функциями в контексте написания модульных тестов со сложными объектами домена. Это интересная альтернатива, чтобы сделать строителя немного более выразительным.

В случае, если CarBuilderвам нужен этот метод вместо:

public static Car Build(Action<CarBuilder> buildAction = null) {
    var carBuilder = new CarBuilder();
    if (buildAction != null) buildAction(carBuilder);
    return carBuilder._car;
}

Который может быть использован как это:

Car c = CarBuilder
    .Build(car => 
        car.OfBrand(Brand.Ford)
           .OfModel(12345)
           .PaintedIn(Color.Silver);

Это зависит от.

Является ли ваш автомобиль Entity или объект Value ? Если автомобиль является сущностью, то важна идентификация объекта, поэтому вы должны вернуть ту же ссылку. Если объект является объектом значения, он должен быть неизменным, то есть единственный способ - каждый раз возвращать новый экземпляр.

Примером последнего будет класс DateTime в .NET, который является объектом значения.

var date1 = new DateTime(2012,1,1);
var date2 = date1.AddDays(1);
// date2 now refers to Jan 2., while date1 remains unchanged at Jan 1.

Однако, если модель является сущностью, мне нравится ответ Спойка об использовании класса builder для построения вашего объекта. Другими словами, этот пример, который вы привели, имеет смысл только в том случае, если Car является ценным объектом.

Создайте отдельный статический внутренний конструктор.

Используйте обычные аргументы конструктора для обязательных параметров. И свободно API для необязательно.

Не создавайте новый объект при установке цвета, если вы не переименуете метод NewCarInColour или что-то подобное.

Я хотел бы сделать что-то подобное с этим брендом, как требуется, а остальное необязательно (это java, но ваш выглядит как javascript, но почти уверен, что они взаимозаменяемы с небольшим количеством выбора):

Car yellowMercedes = new Car.Builder(Brand.MercedesBenz).PaintedIn(Color.Yellow).create();

Car specificYellowModel =new Car.Builder(Brand.MercedesBenz).WithModel(99).PaintedIn(Color.Yellow).create();

Самое главное, что какое бы решение вы ни выбрали, оно четко указано в названии метода и / или комментарии.

Стандартов нет, иногда метод возвращает новый объект (большинство методов String делают это) или возвращает этот объект для целей объединения в цепочку или для повышения эффективности использования памяти).

Однажды я разработал трехмерный векторный объект, и для каждой математической операции у меня были реализованы оба метода. Для мгновенного метода шкалы:

Vector3D scaleLocal(float factor){
    this.x *= factor; 
    this.y *= factor; 
    this.z *= factor; 
    return this;
}

Vector3D scale(float factor){
    Vector3D that = new Vector3D(this); // clone this vector
    return that.scaleLocal(factor);
}

Я вижу здесь несколько проблем, которые, я думаю, могут сбить с толку ... Ваша первая строка в вопросе:

var car = new Car().OfBrand(Brand.Ford).OfModel(12345).PaintedIn(Color.Silver).Create();

Вы вызываете конструктор (new) и метод create ... Метод create () почти всегда будет статическим методом или методом построителя, и компилятор должен перехватить его в предупреждении или ошибке, чтобы вы знали, либо Кстати, этот синтаксис либо неверен, либо имеет несколько ужасных названий. Но позже вы не используете оба, так что давайте посмотрим на это.

// Create a car with neither color, nor model.
var mercedes = new Car().OfBrand(Brand.MercedesBenz).PaintedIn(NeutralColor);

// Create several cars based on the neutral car.
var yellowCar = mercedes.PaintedIn(Color.Yellow).Create();
var specificModel = mercedes.OfModel(99).Create();

Опять же, с созданием, но не с новым конструктором. Дело в том, я думаю, что вы ищете метод copy () вместо этого. Так что, если это так, и это просто плохое имя, давайте посмотрим на одну вещь ... вы называете mercedes.Paintedin (Color.Yellow) .Copy () - это должно быть легко посмотреть на это и сказать, что он «окрашен» перед копированием - просто нормальный поток логики, для меня. Поэтому поместите копию в первую очередь.

var yellowCar = mercedes.Copy().PaintedIn(Color.Yellow)

мне легко увидеть, что ты рисуешь копию, делая свою желтую машину.

Первый подход имеет тот недостаток, который вы упомянули, но до тех пор, пока вы четко дадите понять в документах, у любого некомпетентного кодера не должно быть проблем. Весь код цепочки методов, с которым я лично работал, работал таким образом.

Второй подход, очевидно, имеет тот недостаток, что требует больше работы. Вы также должны решить, будут ли возвращаемые копии делать полные или глубокие копии: что лучше всего может варьироваться от класса к классу или от метода к методу, поэтому вы будете либо вносить несогласованность, либо идти на компромисс в отношении лучшего поведения. Стоит отметить, что это единственный вариант для неизменяемых объектов, таких как строки.

Что бы вы ни делали, не смешивайте и не сочетайте в одном классе!

Я бы предпочел думать так же, как механизм «Методы расширения».

public Car PaintedIn(this Car car, Color color)
{
    car.Color = color;
    return car;
}

Это вариант вышеуказанных методов. Различия в том, что в классе Car есть статические методы, которые соответствуют именам методов в Builder, поэтому вам не нужно явно создавать Builder:

Car car = Car.builder().ofBrand(Brand.Ford).ofColor("Green")...

Вы можете использовать те же имена методов, которые вы используете при вызовах связанного компоновщика:

Car car = Car.ofBrand(Brand.Ford).ofColor("Green")...

Кроме того, в классе есть метод .copy (), который возвращает конструктор, заполненный всеми значениями из текущего экземпляра, поэтому вы можете создать вариант для темы:

Car red = car.copy().paintedIn("Red").build();

Наконец, метод .build () компоновщика проверяет, все ли требуемые значения были предоставлены, и выдает их, если они отсутствуют. Может быть предпочтительнее требовать некоторые значения в конструкторе компоновщика и позволить остальным быть необязательными; в этом случае вы захотите один из шаблонов в других ответах.

public enum Brand {
    Ford, Chrysler, GM, Honda, Toyota, Mercedes, BMW, Lexis, Tesla;
}

public class Car {
    private final Brand brand;
    private final int model;
    private final String color;

    public Car(Brand brand, int model, String color) {
        this.brand = brand;
        this.model = model;
        this.color = color;
    }

    public Brand getBrand() {
        return brand;
    }

    public int getModel() {
        return model;
    }

    public String getColor() {
        return color;
    }

    @Override public String toString() {
        return brand + " " + model + " " + color;
    }

    public Builder copy() {
        Builder builder = new Builder();
        builder.brand = brand;
        builder.model = model;
        builder.color = color;
        return builder;
    }

    public static Builder ofBrand(Brand brand) {
        Builder builder = new Builder();
        builder.brand = brand;
        return builder;
    }

    public static Builder ofModel(int model) {
        Builder builder = new Builder();
        builder.model = model;
        return builder;
    }

    public static Builder paintedIn(String color) {
        Builder builder = new Builder();
        builder.color = color;
        return builder;
    }

    public static class Builder {
        private Brand brand = null;
        private Integer model = null;
        private String color = null;

        public Builder ofBrand(Brand brand) {
            this.brand = brand;
            return this;
        }

        public Builder ofModel(int model) {
            this.model = model;
            return this;
        }

        public Builder paintedIn(String color) {
            this.color = color;
            return this;
        }

        public Car build() {
            if (brand == null) throw new IllegalArgumentException("no brand");
            if (model == null) throw new IllegalArgumentException("no model");
            if (color == null) throw new IllegalArgumentException("no color");
            return new Car(brand, model, color);
        }
    }
}