Sostituzione di classi statiche con stato globale a una serie di POJO, iniziando a sentirsi come un anti-pattern

Question

Sostituzione di classi statiche con stato globale a una serie di POJO, iniziando a sentirsi come un anti-pattern

#1 da (2 voti)
#2 da (1 voti)

2

Sto tentando di ridefinire un po 'di codice e una delle principali modifiche è rimuovere l'uso (ab) di classi statiche per fornire lo stato globale.

Ho provato a suddividere parte della funzionalità "stato globale" con POJO che possono essere passati.

Ma più in basso nella tana del coniglio vado sempre più sento che questo è un Anti-Pattern.

È in grado di mantenere lo stato nei POJO e quindi passarli in cattiva forma? Significa che il profilo dei miei metodi assomiglia spesso a questo:

public MyPojo makeReport(int myInt, String pathToInput, MyPojo myPojo){
    ...
    if(myPojo.whatKindOfReport()==Reports.reportTypes){
        ...
    }
    ...
    myPojo.isWritingReportToFileSuccessful(true);
    ....
    return myPojo;
}

Dove lo "stato" POJO è impostato dalla GUI con cui l'utente interagisce. Ad esempio con caselle di spunta per i tipi di rapporto ecc.

Ma questo blocca altri tipi di ritorno, e sembra eccessivamente complicato.

Ho adottato questo approccio perché l'applicazione ha diversi "percorsi" (vedi whatAmIDoing ) che l'utente può utilizzare per eseguirlo, ognuno dei quali ha diverse fasi. Le opzioni che l'utente ha dipende in gran parte dal percorso che scelgono e da lì, il risultato di quella scelta (normalmente, successo o fallimento, vedi myPojo.isSomethingSuccessful(true) ). Sto cercando di codificare tali informazioni in un POJO piuttosto che in una Global State Class.

Questo è un anti-modello? Come posso aggirare questo?

Modifica: penso che quello che sto cercando sia qualcosa come Chain of Responsibility. Dopo aver letto questa risposta non ne sono sicuro.

globals refactoring data-structures

posta Pureferret 12.01.2014 - 18:30

fonte

2 risposte

Leggi altre domande sui tag globals refactoring data-structures

Come evitare la duplicazione del codice relativo alle entità condivise nel modello di repository? Numero di build quando si supporta la versione precedente

score 2 · Answer 1

Sembra che il metodo doSomething debba essere membro di MyPojo class. Ottenere oggetto come parametro e quindi restituirlo? Sicuramente non ha un bell'aspetto.

Il modo in cui descrivi il tuo codice sembra essere ancora più indicativo di un qualche tipo di struttura di classe. L'uso di enum come descrittore di ciò che viene fatto è un odore chiaro che dovrebbe essere sostituito con una gerarchia di classi in cui ogni classe rappresenta un percorso che il codice può assumere. Come descritto qui .

E come diceva Idan, rendere l'oggetto un campo di classe che contiene il metodo doSomething invece del parametro per il metodo stesso può essere migliore. Inoltre, puoi creare l'oggetto come parametro costruttore, quindi puoi usare dependency injection.

score 1 · Answer 2

Smetti di pensare in termini di operazioni e inizia a pensare in termini di dati.

doSomething non è un metodo statico, quindi appartiene a un oggetto che può contenere lo stato - consente di chiamare la classe di tale oggetto Foo e di aver creato un'istanza denominata foo .

Ora, invece di dire che foo.doSomething ha bisogno di un'istanza di MyPojo , dovresti dire che foo deve fare qualcosa con MyPojo . Quindi, puoi fare foo.setMyPojo(myPojo); e quindi puoi chiamare foo.doSomething senza l'argomento MyPojo - perché già ce l'ha. Inoltre, quando chiami altri metodi di foo , ha già impostato myPojo ! E la cosa migliore: questo ti permette di disegnare un grafico delle dipendenze basato sugli oggetti, non sui metodi.