La ripetizione di un processo può rappresentare una situazione di sovraccarico del metodo?

Question

La ripetizione di un processo può rappresentare una situazione di sovraccarico del metodo?

#1 da (1 voti)

4

Sto sviluppando un convertitore da oggetti di domini diversi, che accetta entrambi, convertendo un oggetto in un altro o un elenco in un altro elenco. Si prega di considerare il seguente esempio:

public MyObject2 decode(MyObject1 originalObject) {
    String name = String.valueOf(originalObject.getId());

    return MyObject2(name);
}

public List<MyObject2> decodeList(Collection<MyObject1> originalObjectsList) {
    return originalObjectsList.stream().map(this::decode).collect(Collectors.toList());
}

La mia situazione è molto più complessa di questa, ma per amor di discussione è sufficiente.

Nel mio team, siamo venuti con il dubbio su ciò che dovrebbe essere migliore in termini di progettazione del software e futura comprensione del codice. Preferisci il metodo decodeList() con questa firma esatta, oppure modificalo in overload decode() .

Per me è difficile da dire, perché entrambi sembrano giusti. Il sovraccarico sembra più pulito, ma per me ha senso anche decodeList() se consideri che ripetere lo stesso processo più volte merita di essere trattato come una cosa diversa.

Esistono buone pratiche relative a questo tipo di situazione?

java

posta Patrick Bard 21.03.2016 - 16:53

fonte

1 risposta

Leggi altre domande sui tag java

script del driver del server sql sembrano scomodi, c'è un modo migliore per eseguire script sql batch? Quali interfacce C ++ IO per una sorgente di dati complessa, ad esempio un convertitore

score 1 · Accepted Answer

avvertenza / scusa per una risposta potenzialmente stupida: I C #.

Sovraccarico o non sovraccarico che è ... non la domanda. Il sovraccarico va bene qui, ma per "futura comprensione del codice" suggerisco che la domanda è il design di classe. Vorrei vedere la funzionalità in un unico posto.

Non so dove siano i metodi precedenti, ma mi chiedo se potrebbero essere entrambi nella stessa classe. Forse una classe di raccolta generica.

public class ObjectCollectionConverter<T, V> {
    public T decodeObject (V originalObject) {}
    public V decodeObject (T originalObject) {}

    public List<V> decodeList(Collection<T> (originalObjectList)
    public List<T> decodeList(Collection<V> (originalObjectList)
}

// The above could be static I suppose, in which case
// the class name might be 'ObjectConverter'

Rimuovi decode dalla classe Objectn . Questo è positivo in termini di principio di responsabilità singola.
Quanto sopra sembra buono se esiste una strong relazione / correlazione nei termini del dominio aziendale tra queste due, o due,% classi% co_de.
A seconda dei tuoi requisiti / dominio, la classe e / oi metodi potrebbero essere Objectn .
Questa classe del convertitore suggerisce che un static potrebbe essere al fine di garantire la presenza del metodo interface . Ma se stiamo parlando solo di decode e Object1 classi allora non è necessario.
Potresti definire un Object2 per il metodo di decodifica che potrebbe consentire una maggiore flessibilità, e in questo caso non sarebbe necessario un delegate .
flessibilità della composizione di classe.