Czy modyfikowanie przychodzącego parametru jest antypatrakiem? [Zamknięte]

Programuję w Javie i zawsze tworzę konwertery w taki sposób:

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

W nowym miejscu pracy wzór jest następujący:

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

Dla mnie jest to trochę śmierdzące, ponieważ przyzwyczaiłem się nie zmieniać przychodzących parametrów. Czy ta przychodząca zmiana parametru jest antypatternem, czy jest w porządku? Czy ma jakieś poważne wady?

To nie jest antypattern, to zła praktyka.

Różnica między antypatternem a zwykłą złą praktyką jest tutaj: definicja anty-wzorca .

Nowy styl pracy, który pokazujesz, to zła praktyka , czas szczątkowy lub czas przed OOP, zgodnie z Clean Code wuja Boba.

Argumenty są najbardziej naturalnie interpretowane jako dane wejściowe do funkcji.

Wszystko, co zmusza cię do sprawdzenia podpisu funkcji, jest równoważne podwójnemu podejściu. Jest to przerwa poznawcza i należy jej unikać. W czasach poprzedzających programowanie obiektowe czasami konieczne były argumenty wyjściowe. Jednak większość potrzeby argumentów wyjściowych znika w językach OO

Cytując słynną książkę Roberta C. Martina „Clean Code”:

Należy unikać argumentów wyjściowych

Funkcje powinny mieć małą liczbę argumentów

Drugi wzorzec narusza obie reguły, szczególnie „argument wyjściowy”. W tym sensie jest gorszy niż pierwszy wzór.

Drugi idiom może być szybszy, ponieważ program wywołujący może ponownie użyć jednej zmiennej w długiej pętli, zamiast każdej iteracji tworząc nową instancję.

Na ogół nie używałbym tego, ale np. w programowaniu gier ma swoje miejsce. Na przykład spójrz na wiele operacji Java3Mon Vector3f pozwala na przekazanie instancji, którą należy zmodyfikować i zwrócić jako wynik.

Nie sądzę, że są to dwa równoważne fragmenty kodu. W pierwszym przypadku musisz utworzyć otherObject. Możesz zmodyfikować istniejącą instancję w drugim. Oba mają swoje zastosowania. Zapach kodu wolałby jeden od drugiego.

To naprawdę zależy od języka.

W Javie druga postać może być anty-wzorcem, ale niektóre języki traktują przekazywanie parametrów inaczej. Ada i VHDL na przykład, zamiast przejść obojętnie wartość lub przez odwołanie, parametry mogą mieć tryby in, outalbo in out.

Błędem jest zmodyfikowanie inparametru lub odczytanie outparametru, ale wszelkie zmiany in outparametru są przekazywane z powrotem do programu wywołującego.

Tak więc dwie formy w Adzie (są to również legalne VHDL)

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

i

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

Oba mają swoje zastosowania; procedura może zwrócić wiele wartości w wielu Outparametrach, podczas gdy funkcja może zwrócić tylko jeden wynik. Ponieważ cel drugiego parametru jest jasno określony w deklaracji procedury, nie można wnieść sprzeciwu wobec tego formularza. Wolę tę funkcję ze względu na czytelność. ale będą przypadki, w których procedura jest lepsza, np. gdy obiekt wywołujący już utworzył obiekt.

Rzeczywiście wydaje się śmierdzący i bez większego kontekstu nie można tego powiedzieć na pewno. Mogą to być dwa powody, chociaż istnieją alternatywy dla obu.

Po pierwsze, jest to zwięzły sposób na implementację częściowej konwersji lub pozostawienie wyniku z wartościami domyślnymi, jeśli konwersja się nie powiedzie. Oznacza to, że możesz mieć to:

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

Oczywiście zwykle odbywa się to za pomocą wyjątków. Jednak nawet jeśli z jakiegokolwiek powodu należy unikać wyjątków, istnieje na to lepszy sposób - wzorzec TryParse jest jedną z opcji.

Innym powodem może być czysta spójność, na przykład jest to część publicznego interfejsu API, w którym ta metoda jest używana do wszystkich funkcji konwersji z dowolnego powodu (takich jak inne funkcje konwersji posiadające wiele danych wyjściowych).

Java nie jest świetna w radzeniu sobie z wieloma wyjściami - nie może mieć parametrów tylko wyjściowych, takich jak niektóre języki, ani mieć wielu wartości zwracanych, jak inne - ale nawet można użyć obiektów zwracanych.

Powód spójności jest raczej kiepski, ale niestety może być najczęstszy.

• Być może stylowi gliniarze w twoim miejscu pracy (lub twojej bazie kodu) pochodzą z środowisk innych niż Java i niechętnie się zmieniają.
• Twój kod mógł być portem z języka, w którym ten styl jest bardziej idiomatyczny.
• Twoja organizacja może być zmuszona do zachowania spójności interfejsu API w różnych językach, a był to styl o najniższym wspólnym mianowniku (to głupie, ale zdarza się nawet w Google ).
• A może styl był bardziej sensowny w odległej przeszłości i przekształcił się w obecną formę (na przykład mógł to być wzór TryParse, ale jakiś dobrze intonowany poprzednik usunął wartość zwracaną po odkryciu, że nikt jej wcale nie sprawdził).

Zaletą drugiego wzorca jest to, że zmusza on osobę dzwoniącą do przejęcia odpowiedzialności za utworzony obiekt. Nie ma wątpliwości, czy metoda utworzyła obiekt, czy pobrała go z puli wielokrotnego użytku. Dzwoniący wie, że jest odpowiedzialny za czas życia i utylizację nowego obiektu.

Wady tej metody to:

1. Nie może być użyty jako metoda fabryczna, osoba dzwoniąca musi znać dokładny jej podtyp OtherObjecti musi go wcześniej zbudować.
2. Nie można go używać z obiektami, które wymagają parametrów w ich konstruktorze, jeśli te parametry pochodzą MyObject. OtherObjectmusi być możliwy do zbudowania bez wiedzy o nim MyObject.

Odpowiedź oparta jest na moim doświadczeniu w c #, mam nadzieję, że logika przełoży się na Javę.

Biorąc pod uwagę luźną semantykę - myObjectToOtherObjectmoże również oznaczać, że przenosisz niektóre dane z pierwszego obiektu do drugiego lub że przekształcisz je całkowicie od nowa, druga metoda wydaje się bardziej odpowiednia.

Gdyby jednak nazwa metody to Convert(co powinno być, jeśli spojrzymy na część „... wykonaj konwersję”), powiedziałbym, że druga metoda nie miałaby żadnego sensu. Nie zamieniasz wartości na inną wartość, która już istnieje, IMO.