sottoclasse senza logica di classe astratta

1

Ho una classe chiamata Change che dovrebbe essere astratta e avere alcuni metodi di base. Ho classi Insert , Update e Delete che estende Change . Nel caso di Insert , Update io uso solo estendi e aggiungo no logic !

public class Insert extends Change {}

Nella classe Delete ho un metodo extra che non esiste nella classe Change (che è la classe astratta base).

Sembra un design errato, che ho classi come Insert e Update che si estendono da Change ma non fanno nulla (nessuna logica in queste classi). Cosa pensi? quale dovrebbe essere la gerarchia?

Modifica C'è un endpoint nel servizio che restituisce un oggetto denominato ChangedEntities e il consumatore di questo endpoint che è un altro servizio utilizza questo endpoint per inserire / aggiornare / eliminare entità nel DB. Quindi il consumatore di questo endpoint ottiene,

public class ChangedEntities {
    private Insert inserations;
    private Update updates;
    private Delete deletions;
}

public class Change {
    private List<Entity> entities = new ArrayList();

    public void addEntity(Entity entity) {
        entities.add(entity);
        // the logic is more complex and is common to insert/update/delete
    }
}

public class Insert extends Change {}

public class Delete extends Change {

    public void logDeletion() {
        System.out.println("Deleted successfully");
        // this should be some complex method
    }
}
    
posta T.S 20.11.2018 - 20:33
fonte

3 risposte

3

Non vorrei creare nessuna di queste sottoclassi.

Creerei un'interfaccia Loggable quale Change implementerebbe, e permetterò ai clienti della classe di decidere se vogliono registrare o separare le loro istanze Change con nomi di variabili differenti.

Hanno lo stesso identico comportamento, quindi non vedo alcun motivo per creare altre classi.

Inoltre, se pensi che Delete debba essere una classe perché log sarà complessa, il problema potrebbe essere che è troppo complesso. Concettualmente, stai registrando un cambiamento che è successo. Crea uno strumento semplice e consenti agli utenti della classe di utilizzarlo con il proprio grado di complessità.

    
risposta data 21.11.2018 - 23:32
fonte
1

Per me, è perfettamente ok avere una classe come Insert semplicemente estendere Change senza aggiungere nulla al genitore.

Mi sembra del tutto naturale avere tre classi diverse Insert , Update e Delete . Sono una parte del tuo dominio, suppongo. E probabilmente è utile se sono tutte sottoclassi o implementazioni di una comune classe o interfaccia astratta chiamata Change .

Dipende da te come sviluppatore decidere come implementarli e vedo tre diversi modi (con una strong preferenza per il secondo):

  • Ripeti le implementazioni del metodo in ogni sottoclasse: NO, NON RIPETERE TE STESSO!

  • Le classi ereditano le implementazioni da un genitore astratto come Change : lo farei in questo modo e se alcune sottoclassi possono ereditare tutto ciò di cui ha bisogno, tanto meglio!

  • I sostenitori di "Composition over Ereditarietà" potrebbero introdurre una classe come CommonChangeOperations , assegnare a ognuna delle tre classi un campo delegato di questo tipo e avere tutti i metodi delegati a queste istanze. Per me sembra una tecnica di overkill.

Quindi, per me la gerarchia

  • %codice%
    • Change
    • Insert
    • Update

è perfettamente a posto, con Delete che riporta tutti gli aspetti comuni dell'implementazione.

    
risposta data 21.11.2018 - 19:41
fonte
0

Personalmente, penso che il design sia sbagliato.

Concettualmente, le classi rappresentano oggetti, non i verbi o le azioni. Mi sembra che tu stia cercando di fare programmazione funzionale usando le risorse OOP. Chiediti, hai mai trovato un oggetto "cambiare" nella realtà?

Non so qual è il tuo obiettivo, ma "cambiare" è un'azione che esegui per qualcosa. Ad esempio, il tuo database. Ma le azioni sarebbero concrete. Non ricordo mai di aver implementato un metodo "change ()".

Prendi la java.util.list come esempio di cosa dovrebbe essere fatto. Fornisce i metodi add (), remove (), set (), ecc., Che possono essere sovrascritti. Una lista è qualcosa che puoi "cambiare".

Quindi, puoi creare i tuoi oggetti e le tue astrazioni, se necessario, come per esempio

public class MyDatabase {...

e fornire metodi come ...

public void add(SparePart part) {

per avere procedure chiare e leggibili:

Wheel w=getLastWheelModel();
db=new MyDatabase(params...);
db.add(w);

(dove Wheel estende SparePart e dove puoi aggiungere le tue astrazioni).

    
risposta data 22.11.2018 - 04:49
fonte