Ist das Ändern eines eingehenden Parameters ein Gegenmuster? [geschlossen]

Ich programmiere in Java und mache Konverter immer so:

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

Am neuen Arbeitsplatz lautet das Muster:

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

Für mich ist es ein bisschen stinkend, da ich mich daran gewöhnt habe, die eingehenden Parameter nicht zu ändern. Handelt es sich bei dieser Änderung des eingehenden Parameters um ein Antimuster oder ist dies in Ordnung? Hat es einige gravierende Nachteile?

Es ist kein Gegenmuster, es ist eine schlechte Praxis.

Der Unterschied zwischen einem Antimuster und einer schlechten Praxis ist hier: Anti-Muster-Definition .

Der neue Arbeitsplatzstil, den Sie zeigen, ist nach dem Clean Code von Uncle Bob eine schlechte Praxis , egal ob es sich um eine Zeit vor oder nach dem OOP handelt.

Argumente werden am natürlichsten als Eingaben in eine Funktion interpretiert.

Alles, was Sie dazu zwingt, die Funktionssignatur zu überprüfen, entspricht einem Double-Take. Es ist eine kognitive Unterbrechung und sollte vermieden werden. In den Tagen vor der objektorientierten Programmierung war es manchmal erforderlich, Ausgabeargumente zu haben. In OO-Sprachen entfällt jedoch ein Großteil des Bedarfs an Ausgabeargumenten

Zitat von Robert C. Martins berühmtem Buch "Clean Code":

Ausgabeargumente sollten vermieden werden

Funktionen sollten eine kleine Anzahl von Argumenten haben

Das zweite Muster verletzt beide Regeln, insbesondere das "Ausgabeargument". In diesem Sinne ist es schlimmer als das erste Muster.

Das zweite Idiom kann schneller sein, da der Aufrufer eine Variable über eine lange Schleife wiederverwenden kann, anstatt bei jeder Iteration eine neue Instanz zu erstellen.

Ich würde es im Allgemeinen nicht verwenden, aber zB. In der Spielprogrammierung hat es seinen Platz. Wenn Sie sich beispielsweise die vielen Operationen von JavaMonkey Vector3f ansehen, können Sie Instanzen übergeben, die geändert und als Ergebnis zurückgegeben werden sollen.

Ich denke nicht, dass dies zwei gleichwertige Codeteile sind. Im ersten Fall müssen Sie die erstellen otherObject. Sie können die vorhandene Instanz in der zweiten ändern. Beide haben ihren Nutzen. Code-Geruch würde einander vorziehen.

Es kommt wirklich auf die Sprache an.

In Java kann die zweite Form ein Anti-Pattern sein, aber einige Sprachen behandeln die Parameterübergabe unterschiedlich. In Ada und VHDL beispielsweise anstelle von Pass Wert oder als Referenz, können Parameter haben Modi in, outoder in out.

Es ist ein Fehler, einen inParameter zu ändern oder zu lesen out, aber alle Änderungen an einem in outParameter werden an den Aufrufer zurückgegeben.

Also die beiden Formen in Ada (diese sind auch legale VHDL) sind

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

und

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

Beide haben ihren Nutzen; Eine Prozedur kann mehrere Werte in mehreren OutParametern zurückgeben, während eine Funktion nur ein einziges Ergebnis zurückgeben kann. Da der Zweck des zweiten Parameters in der Verfahrenserklärung eindeutig angegeben ist, kann gegen dieses Formular kein Einwand erhoben werden. Ich bevorzuge die Funktion für die Lesbarkeit. Es wird jedoch Fälle geben, in denen die Prozedur besser ist, z. B. wenn der Aufrufer das Objekt bereits erstellt hat.

Es scheint in der Tat stinkend, und ohne mehr Kontext ist es unmöglich, sicher zu sagen. Dies könnte zwei Gründe haben, obwohl es für beide Alternativen gibt.

Erstens ist dies eine übersichtliche Methode, um eine teilweise Konvertierung durchzuführen oder das Ergebnis mit Standardwerten zu belassen, wenn die Konvertierung fehlschlägt. Das heißt, Sie könnten dies haben:

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

Natürlich wird dies normalerweise mit Ausnahmen behandelt. Auch wenn Ausnahmen aus irgendeinem Grund vermieden werden müssen, gibt es eine bessere Möglichkeit, dies zu tun - das TryParse-Muster ist eine Option.

Ein weiterer Grund ist, dass dies aus rein konsistenten Gründen sein könnte, zum Beispiel als Teil einer öffentlichen API, in der diese Methode für alle Konvertierungsfunktionen aus beliebigen Gründen verwendet wird (zum Beispiel für andere Konvertierungsfunktionen mit mehreren Ausgängen).

Java kann nicht gut mit mehreren Ausgaben umgehen - es kann nicht nur Ausgabeparameter wie einige Sprachen oder mehrere Rückgabewerte wie andere haben - aber Sie können auch Rückgabeobjekte verwenden.

Der Konsistenzgrund ist eher lahm, aber leider ist er der häufigste.

• Vielleicht stammen die Stilpolizisten an Ihrem Arbeitsplatz (oder in Ihrer Codebasis) aus Ländern ohne Java und wollten sich nur ungern ändern.
• Ihr Code ist möglicherweise ein Port aus einer Sprache, in der dieser Stil idiomatischer ist.
• Möglicherweise muss Ihre Organisation die API-Konsistenz über verschiedene Sprachen hinweg aufrechterhalten. Dies war der Stil mit dem niedrigsten gemeinsamen Nenner (dumm, aber auch für Google ).
• Oder vielleicht machte der Stil in der fernen Vergangenheit mehr Sinn und verwandelte sich in seine aktuelle Form (es könnte beispielsweise das TryParse-Muster gewesen sein, aber ein wohlmeinender Vorgänger hat den Rückgabewert entfernt, nachdem festgestellt wurde, dass er überhaupt nicht überprüft wurde).

Der Vorteil des zweiten Musters besteht darin, dass der Aufrufer gezwungen wird, das Eigentum und die Verantwortung für das erstellte Objekt zu übernehmen. Es steht außer Frage, ob die Methode das Objekt erstellt oder aus einem wiederverwendbaren Pool abgerufen hat. Der Anrufer weiß, dass er für die Lebensdauer und Entsorgung des neuen Objekts verantwortlich ist.

Die Nachteile dieser Methode sind:

1. Kann nicht als Factory-Methode verwendet werden, muss der Aufrufer den genauen Untertyp kennen OtherObjectund ihn im Voraus konstruieren.
2. Kann nicht mit Objekten verwendet werden, die Parameter in ihrem Konstruktor benötigen, wenn diese Parameter von stammen MyObject. OtherObjectmuss konstruierbar sein, ohne zu wissen MyObject.

Die Antwort basiert auf meinen Erfahrungen in C #. Ich hoffe, die Logik wird in Java übersetzt.

Angesichts der losen Semantik - myObjectToOtherObjectkönnte dies auch bedeuten, dass Sie einige Daten vom ersten zum zweiten Objekt verschieben oder dass Sie sie komplett neu konvertieren - ist die zweite Methode angemessener.

Wenn jedoch der Methodenname wäre Convert(der sollte es sein, wenn wir uns den Teil "... do the conversion" ansehen), würde ich sagen, dass die zweite Methode keinen Sinn ergibt. Sie konvertieren keinen Wert in einen anderen bereits vorhandenen Wert, IMO.