Является ли изменение входящего параметра антипаттерном? [закрыто]

Я программирую на Java, и я всегда делаю конвертеры вроде этого:

public OtherObject MyObject2OtherObject(MyObject mo){
    ... Do the conversion
    return otherObject;
}

На новом рабочем месте шаблон:

public void MyObject2OtherObject(MyObject mo, OtherObject oo){
    ... Do the conversion
}

Для меня это немного вонючий, так как я привык не менять входящие параметры. Является ли это изменение входящего параметра антипаттерном или это нормально? Есть ли у него серьезные недостатки?

Это не антипаттерн, это плохая практика.

Разница между антипаттерном и простой плохой практикой здесь: определение анти-паттерна .

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

Аргументы наиболее естественно интерпретируются как входные данные для функции.

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

Цитирую знаменитую книгу Роберта К. Мартина «Чистый код»:

Выходных аргументов следует избегать

Функции должны иметь небольшое количество аргументов

Второй шаблон нарушает оба правила, в частности правило «выходной аргумент». В этом смысле он хуже первого паттерна.

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

Я бы вообще не использовал его, но например. в программировании игр это имеет свое место. Например, посмотрите на множество операций JavaMonkey Vector3f, позволяющих передать экземпляр, который должен быть изменен и возвращен как результат.

Я не думаю, что это две эквивалентные части кода. В первом случае вы должны создать otherObject. Вы можете изменить существующий экземпляр во втором. У обоих есть его использование. Кодовый запах предпочтет один другому.

Это действительно зависит от языка.

В Java вторая форма может быть антишаблоном, но некоторые языки по-разному обрабатывают передачу параметров. В Ada и VHDL, например, вместо того , чтобы проход по значению или по ссылке, параметры могут иметь режимы in, out, или in out.

Изменение inили чтение outпараметра является ошибкой , но любые изменения in outпараметра передаются обратно вызывающей стороне.

Таким образом, две формы в Аде (это также законные VHDL)

function MyObject2OtherObject(mo : in MyObject) return OtherObject is
begin
    ... Do the conversion
    return otherObject;
end MyObject2OtherObject;

а также

procedure MyObject2OtherObject(mo : in MyObject; oo : out OtherObject) is
begin
    ... Do the conversion
    oo := ... the conversion result;
end MyObject2OtherObject;

Оба имеют свое применение; процедура может возвращать несколько значений в нескольких Outпараметрах, а функция может возвращать только один результат. Поскольку назначение второго параметра четко указано в объявлении процедуры, не может быть никаких возражений против этой формы. Я склонен предпочесть функцию для удобочитаемости. но будут случаи, когда процедура лучше, например, когда вызывающий объект уже создал объект.

Это действительно кажется вонючим, и, не видя больше контекста, невозможно сказать наверняка. Может быть две причины для этого, хотя есть альтернативы для обоих.

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

public void ConvertFoo(Foo from, Foo to) {
    if (can't convert) {
        return;
    }
    ...
}

Foo a;
Foo b = DefaultFoo();
ConvertFoo(a, b);
// If conversion fails, b is unchanged

Конечно, обычно это обрабатывается с использованием исключений. Однако, даже если по какой-либо причине необходимо избегать исключений, есть лучший способ сделать это - шаблон TryParse является одним из вариантов.

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

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

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

• Возможно, стилевые копы на вашем рабочем месте (или в вашей кодовой базе) происходят из не Java-среды и неохотно меняются.
• Ваш код мог быть портом с языка, где этот стиль более идиоматичен.
• Вашей организации может потребоваться поддерживать согласованность API на разных языках, и это был стиль с наименьшим общим знаменателем (это глупо, но это происходит даже для Google ).
• Или, возможно, стиль имел больше смысла в далеком прошлом и трансформировался в его текущую форму (например, это мог быть шаблон TryParse, но какой-то благими намерениями предшественник удалил возвращаемое значение после того, как обнаружил, что никто его вообще не проверял).

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

Недостатками этого способа являются:

1. Не может использоваться в качестве заводского метода, вызывающая сторона должна знать точный подтип, который OtherObjectему нужен, и составить его заранее.
2. Не может использоваться с объектами, которые требуют параметров в своем конструкторе, если эти параметры получены MyObject. OtherObjectдолжен быть конструируемым, не зная о MyObject.

Ответ основан на моем опыте в C #, я надеюсь, что логика переводит на Java.

Учитывая свободную семантику - это myObjectToOtherObjectможет означать, что вы перемещаете некоторые данные из первого объекта во второй или полностью преобразуете его, второй метод кажется более подходящим.

Однако, если бы имя метода было Convert(как и должно быть, если мы посмотрим на часть «... сделать преобразование»), я бы сказал, что второй метод не имеет никакого смысла. Вы не конвертируете значение в другое значение, которое уже существует, IMO.