Classe anonima come singleton

Question

Classe anonima come singleton

#1 da (4 voti)
#2 da (0 voti)

-1

Durante l'implementazione di uno dei miei moduli, avevo bisogno di un singleton per una delle mie classi, ad esempio ModuleManager. Invece di creare una classe con criteri di singleton, ho creato un'interfaccia ModuleManager per definire l'API e ho implementato questa interfaccia con una classe anonima in modo che non ci possa essere un'altra implementazione o nessuna altra istanza può essere creata! Questo singleton può ancora essere rotto? Sto interpretando male questo come singleton? potrebbe essere ma mi consente di avere solo un'istanza di ModuleManager.

public interface ModuleManager{
     void manage();
 }
 public ModuleManager mgr = new ModuleManager() {
    public void manage() { s.o.p("manage"); }
 }

java

posta Tech Junkie 02.12.2016 - 19:17

fonte

2 risposte

4

Secondo questa logica, ogni classe anonima è un singleton, dal momento che non ha un nome, non è possibile creare un'istanza più di una volta.

Un problema è che devono vivere all'interno di un'altra classe.

IMHO che non è un singleton. Puoi istanziare la classe che la contiene due volte e anche se è vero che la classe anonima non è la stessa in entrambi i casi e quindi non può essere chiamata due istanze della stessa classe, alla fine si sta avendo la stessa funzionalità in due posti. Quindi immagina che lo scopo del singleton fosse avere un punto centralizzato per costruire una risorsa . Poiché puoi istanziare la classe wrapper tutte le volte che vuoi , ognuno con una classe nidificata pubblica anonima con un metodo pubblico, non hai più un punto univoco per il comportamento che sconfigge lo scopo di un singleton .

risposta data 02.12.2016 - 20:36

fonte

Leggi altre domande sui tag java

Evitare parametri aggiuntivi tramite API o dispositivo (Android, iOS) Winforms: utilizzo del designer rispetto alla generazione per codice

score 0 · Accepted Answer

Prima di tutto, ci possono essere altre implementazioni di tale interfaccia. Niente nel tuo codice impedirebbe alle persone di implementare quell'interfaccia più volte.

Preferisco suggerire di utilizzare un enum per implementare tale interfaccia. Poiché la JVM ti garantisce che i singletons di enum sono completamente "singleton corretti", fuori dagli schemi. Lo faccio in genere in questo modo:

interface FooFunctionality {
  void foo();
}

class FooFunctionalityImpl implements FooFunctionality {...

enum FooFunctionalityProvider implements FooFunctionality {
  INSTANCE;
  private final FooFunctionality delegatee = new FooFunctionalityImpl();

  @Override
  void foo() {
    delegatee.foo()
  }

Ciò aiuta a separare chiaramente i diversi aspetti:

Esiste un impl per l'interfaccia
C'è un enum per renderlo un singleton

Inoltre, consente anche di eseguire test unitari quasi completi di tutti gli aspetti in modo pulito e "separato".

Ma certo: puoi anche avere più classi impl nella mia soluzione. E questo non è davvero un problema.