Spostare metodi in una MasterClass in modo che possa essere sovrascritto, c'è un modo migliore?

0

Sto guardando un oggetto molto grande all'interno dell'applicazione su cui sto lavorando, che è lì per contenere sostanzialmente tutti i dati insieme a un livello più ampio. Recentemente, abbiamo iniziato a spostare alcuni metodi da altri oggetti su ModelData a ModelData stesso, perché questi metodi stanno cambiando drasticamente ora che stiamo implementando il ExistingModelData ( fai riferimento al codice qui sotto se non hai già ).

public RemoveStuffAction //Called from View
{
    public void doWork(HttpServletRequest request, HttpServletResponse response)
    {
        SessionData sessionData = WebUtils.getSessionData(request);
        //We actually use contracts here for validation and such
        //Passes contract to a service - ultimately resulting in..
        ModelData modelData = sessionData.getModelData();
        modelData.removeStuff(request.getParameter("stuffID"));
        //other cleanup

        //the old Code
        //ModelData modelData = sessionData.getModelData();
        //modelData.getStuffManager().removeStuff(stuffID);
        //other cleanup

        //save of model..
        //forward mapping..
        //exception handling..
    }
}

public abstract ModelData
{
    //lots of stuff

    //Methods to modify the stuff
    public void removeStuff(String stuffID) //example
    {
        this.getStuffManager().removeTheStuffFromHere(stuffID);
    }
}

public NewModelData extends ModelData
{
    //not much stuff
}

public DuplicateModelData extends ModelData
{
    //not much stuff
}

public ExistingModelData extends ModelData
{
    //quite a bit of stuff
    //Overrides many methods to modify the stuff
    public void removeStuff(String stuffID) //example
    {
        //we need the data there because we need to know what used to be there, 
            //even though it is supposed to now be removed
        //what determines whether we need to know what was there or not is determined by 
            //whether this is ExistingData or not.
        this.getStuffManager().getStuff(stuffID).markAsRemoved();
    }
}

Fondamentalmente, invece di creare classi di override per tutti gli oggetti che potrebbero essere modificati sul modello e implementare nuovi metodi di Remove ( e quindi preoccuparci di tutte le volte anche Add di quegli oggetti così aggiungiamo il correggine uno in ciascuno di quei punti ) stiamo spostando questi metodi nella classe ModelData e lasciando che una classe sovrascritta gestisca la rimozione dei nostri oggetti tramite l'ereditarietà.

Ciò che funziona funziona bene ed è chiaro a tutti quelli della squadra che stanno andando avanti. Mi sento anche con il JavaDoc che abbiamo su ModelData che le cose sono spiegate abbastanza bene, ma inizia solo a darmi fastidio che stiamo spostando così tanti metodi per queste classi - rendendo già grandi classi ancora più grandi in termini di quantità di testo.

Ho preso in considerazione la creazione di due nuovi oggetti solo per contenere tutti questi metodi, e posto la versione originale su ModelData e una versione sostituita su ExistingModelData , ma non lo faccio perché mi sembra che sia in realtà non realizza nulla, semplicemente accorcia la quantità di codice in quella particolare classe, il che rende solo un po 'meglio il mio OCD - e poi dovrò aggiungere una chiamata di metodo in più ovunque dovremo usare i metodi nel nuovi oggetti.

Riconosco anche che potrei essere troppo vicino alla situazione in questo momento e potrebbe mancare qualcosa di ovvio.

C'è qualcosa che posso fare che ha più senso e crea un design più pulito?

    
posta DoubleDouble 17.07.2015 - 18:04
fonte

1 risposta

2

Dato che la rimozione viene gestita generalmente allo stesso modo, non c'è davvero nulla di sbagliato in questo approccio di avere una gestione predefinita nella classe genitrice e implementazioni forzate dove richiesto. L'aggiunta di altri oggetti intermediari non risolve il fatto che tu hai alcune operazioni comuni applicabili a un intervallo di classi.

Se si è preoccupati di avere classi grandi in cui vengono scaricate molte funzioni minimali, considerare la classe ModelData una facciata che contenga un certo numero di altre classi che implementano tipi specifici di operazioni. Ho utilizzato questo approccio durante la creazione di ecosistemi di elaborazione dei servizi in cui è disponibile un numero elevato di operazioni strutturate in modo simile.

    
risposta data 17.07.2015 - 20:31
fonte

Leggi altre domande sui tag