Чи зміна вхідного параметра є антипаттерном? [зачинено]

Я програмую на Java, і завжди роблю перетворювачі на зразок цього:

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

На новому робочому місці схема:

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

Для мене це трохи смердюче, оскільки я звик не змінювати вхідні параметри. Це зміна вхідних параметрів антипатернів чи це нормально? Чи є якісь серйозні недоліки?

Це не антипаттерн, це погана практика.

Тут різниця між антипатернією та просто поганою практикою: визначення антимонопольного моделювання .

Новий стиль робочого місця, який ви показуєте, - це погана практика , вестигіальні або до початку OOP, згідно з Чистим кодексом дядька Боба.

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

Все, що змушує вас перевірити підпис функції, еквівалентне подвійному прийому. Це пізнавальна перерва і цього слід уникати. За дні до об'єктно-орієнтованого програмування іноді потрібно було мати вихідні аргументи. Однак велика потреба у вихідних аргументах зникає в мовах ОО

Цитуючи відому книгу Роберта К. Мартіна "Чистий код":

Вихідних аргументів слід уникати

Функції повинні мати невелику кількість аргументів

Друга закономірність порушує обидва правила, особливо "вихідний аргумент". У цьому сенсі це гірше, ніж перший візерунок.

Друга ідіома може бути швидшою, оскільки абонент може повторно використовувати одну змінну протягом довгого циклу, а не кожну ітерацію створювати новий екземпляр.

Я б його взагалі не використовував, але, наприклад. в ігровому програмуванні воно має своє місце. Наприклад, подивіться на багато операцій Vector3f JavaMonkey дозволяє передавати екземпляр, який повинен бути змінений і повернутий як результат.

Я не думаю, що це два еквівалентні фрагменти коду. У першому випадку вам доведеться створити 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.