La modifica di un parametro in arrivo è un antipattern? [chiuso]

Sto programmando in Java, e faccio sempre i convertitori in questo modo:

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

Nel nuovo posto di lavoro lo schema è:

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

Per me è un po 'puzzolente, dato che mi sono abituato a non modificare i parametri in arrivo. Questa modifica dei parametri in entrata è un antipattern o è OK? Ha alcuni gravi inconvenienti?

Non è un antipasto, è una cattiva pratica.

La differenza tra un antipattern e una semplice cattiva pratica è qui: definizione anti-pattern .

Il nuovo stile di lavoro che mostri è una cattiva pratica , vestigia o tempi pre-OOP, secondo il Clean Code di zio Bob.

Gli argomenti sono naturalmente interpretati come input di una funzione.

Tutto ciò che ti costringe a controllare la firma della funzione equivale a un doppio take. È una pausa cognitiva e dovrebbe essere evitata. Nei giorni precedenti la programmazione orientata agli oggetti era talvolta necessario disporre di argomenti di output. Tuttavia, gran parte della necessità di argomenti di output scompare nei linguaggi OO

Citando il famoso libro di Robert C. Martin "Clean Code":

Gli argomenti di output dovrebbero essere evitati

Le funzioni dovrebbero avere un numero limitato di argomenti

Il secondo modello viola entrambe le regole, in particolare quella "argomento di output". In questo senso è peggio del primo modello.

Il secondo linguaggio può essere più veloce, perché il chiamante può riutilizzare una variabile su un ciclo lungo, anziché ogni iterazione che crea una nuova istanza.

Non lo userei generalmente, ma ad es. nella programmazione del gioco ha il suo posto. Ad esempio, guardare molte operazioni Vector3f di JavaMonkey consente di passare istanze che dovrebbero essere modificate e restituite come risultato.

Non penso che siano due pezzi equivalenti di codice. Nel primo caso, devi creare il file otherObject. È possibile modificare l'istanza esistente nel secondo. Entrambi hanno i suoi usi. L'odore di codice preferirebbe l'uno all'altro.

Dipende davvero dalla lingua.

In Java la seconda forma può essere un anti-pattern, ma alcune lingue trattano il passaggio di parametri in modo diverso. In Ada e VHDL per esempio, invece di passaggio per valore o per riferimento, i parametri possono avere modi in, outo in out.

È un errore modificare un inparametro o leggere un outparametro, ma eventuali modifiche a un in outparametro vengono restituite al chiamante.

Quindi le due forme in Ada (anche queste sono VHDL legali) lo sono

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

e

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

Entrambi hanno i loro usi; una procedura può restituire più valori in più Outparametri mentre una funzione può restituire un solo risultato. Poiché lo scopo del secondo parametro è chiaramente indicato nella dichiarazione di procedura, non è possibile contestare questo modulo. Tendo a preferire la funzione per la leggibilità. ma ci saranno casi in cui la procedura è migliore, ad esempio dove il chiamante ha già creato l'oggetto.

Sembra davvero puzzolente e senza vedere più contesto è impossibile dirlo con certezza. Potrebbero esserci due ragioni per farlo, sebbene ci siano alternative per entrambi.

Innanzitutto, è un modo conciso di implementare la conversione parziale o di lasciare il risultato con valori predefiniti se la conversione fallisce. Cioè, potresti avere questo:

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

Naturalmente, questo di solito viene gestito utilizzando le eccezioni. Tuttavia, anche se le eccezioni devono essere evitate per qualsiasi motivo, c'è un modo migliore per farlo: il modello TryParse è un'opzione.

Un altro motivo è che potrebbe essere dovuto a motivi puramente coerenti, ad esempio fa parte di un'API pubblica in cui questo metodo viene utilizzato per tutte le funzioni di conversione per qualsiasi motivo (come altre funzioni di conversione con più output).

Java non è bravo a gestire più output - non può avere parametri di solo output come alcuni linguaggi o avere più valori di ritorno come altri - ma ancora, potresti usare oggetti return.

Il motivo della coerenza è piuttosto scadente, ma purtroppo potrebbe essere il più comune.

• Forse i poliziotti di stile sul tuo posto di lavoro (o la tua base di codice) provengono da un background non Java e sono stati riluttanti a cambiare.
• Il tuo codice potrebbe essere stato una porta da una lingua in cui questo stile è più idiomatico.
• La tua organizzazione potrebbe aver bisogno di mantenere la coerenza delle API in diverse lingue, e questo era lo stile con il minimo comune denominatore (è stupido ma succede anche per Google ).
• O forse lo stile aveva più senso in un lontano passato e si trasformava nella sua forma attuale (per esempio, avrebbe potuto essere il modello TryParse ma un predecessore ben intenzionato ha rimosso il valore di ritorno dopo aver scoperto che nessuno lo controllava affatto).

Il vantaggio del secondo modello è che forza il chiamante ad assumere la proprietà e la responsabilità per l'oggetto creato. Non vi è dubbio se il metodo abbia creato l'oggetto o lo abbia ottenuto da un pool riutilizzabile. Il chiamante sa di essere responsabile della durata e dello smaltimento del nuovo oggetto.

Gli svantaggi di questo metodo sono:

1. Non può essere utilizzato come metodo di fabbrica, il chiamante deve conoscere il sottotipo esatto di OtherObjectcui ha bisogno e costruirlo in anticipo.
2. Non può essere utilizzato con oggetti che richiedono parametri nel loro costruttore se tali parametri provengono MyObject. OtherObjectdeve essere costruibile senza saperlo MyObject.

La risposta si basa sulla mia esperienza in c #, spero che la logica si traduca in Java.

Data la semantica libera, myObjectToOtherObjectpotrebbe significare anche che si spostano alcuni dati dal primo oggetto al secondo o che li si converte completamente di nuovo, il secondo metodo sembra più adeguato.

Tuttavia, se il nome del metodo fosse Convert(come dovrebbe essere se osserviamo la parte "... esegui la conversione"), direi che il secondo metodo non avrebbe alcun senso. Non converti un valore in un altro valore già esistente, IMO.