Come faccio a refactoring di una classe dati per non essere uno?

Question

Come faccio a refactoring di una classe dati per non essere uno?

#1 da (10 voti)

5

Recentemente abbiamo aggiornato a PMD 6.0.0 e stiamo ottenendo diverse classi contrassegnate come "Classi di dati"? Sostiene che rompe l'incapsulamento e crea un design fragile (comprendo che questo sito ha un'opinione diversa ).

Diciamo che il nostro team decide di procedere e di rifattorizzare la classe dati, invece di ignorare la regola PMD. Purtroppo, la documentazione di PMD per la regola non mi è chiara.

Refactoring a Data Class should focus on restoring a good data-behaviour proximity. In most cases, that means moving the operations defined on the data back into the class. In some other cases it may make sense to remove entirely the class and move the data into the former client classes.

Non capisco cosa sia "buona prossimità dati-comportamento" o cosa siano "le precedenti classi cliente". Ad esempio, abbiamo qualcosa di simile:

public class Person {
    private String name;
    private List<String> formerNames;
    private List<Food> favoriteFoods;

    //getters and setters
}

Come farei per refactoring questa classe di dati, come raccomanda PMD?

_{Mi piacerebbe concentrarmi su quale sarebbe il tipo di refactoring, piuttosto che discutere se la regola è buona o no. Al momento, non sappiamo se vogliamo consentire questa regola o escluderla.}

object-oriented code-quality refactoring data-structures code-smell

posta Thunderforge 12.01.2018 - 22:16

fonte

1 risposta

Leggi altre domande sui tag object-oriented code-quality refactoring data-structures code-smell

Come dovrei denominare i campi in una classe che rappresenta le dimensioni 2D e 3D? Ordino le mie importazioni Python per lunghezza del nome. Ha senso?

score 10 · Accepted Answer

Spostando tutti i metodi che dipendono da questi dati in questa classe. Ad esempio:

out.showlist(listNameRymes(person.getName())); // Redesign it so this
person.listNameRymes(out);                     // can be done like this

Ma capisci che questo è qualcosa di più del semplice spostamento dei metodi. È un modo completamente diverso di guardare i problemi.

Quando usi la mentalità procedurale, vuoi trascinare i dettagli verso di te e controllarli in un unico posto. Getters ti permette di farlo. Ma ora hai mescolato i dettagli di cose diverse insieme che li rende difficili da sfatare.

Quando usi la mentalità orientata agli oggetti, allontani i dettagli da te. Fai in modo che altre cose si occupino di loro. Piuttosto, chiedi cose che dici agli oggetti di fare cose e si aspettano che gestiscano i dettagli.

Questa idea ha molti nomi, ma la mia preferita è dire, non chiedere .

Questo non vuol dire che le Classi di dati non abbiano spazio. Il software comunica in lungo e in largo. A volte comunica oltre i confini. Alcuni limiti ti impediscono di spostare i metodi. Alcuni sono concettuali. Eppure hai ancora bisogno di comunicare. Questo è quando le classi di dati brillano.

Scopri quando ascoltare il tuo strumento e quando ignorarlo. Potrebbe essere meglio ricordarsi di controllare, ma sarai sempre più bravo a fare il giudizio.