Singleton for Java Functional Interface

Question

Singleton for Java Functional Interface

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

3

So che ci sono state 1 milione e 1 discussioni su Singletons su SO e qui e ho dovuto ripulire la mia giusta dose di terribili singleton nella nostra base di codici; uno dei motivi per cui sono timido con le pistole qui. Ma mi trovo in una situazione in cui mi sento come se Singleton fosse una soluzione ragionevole e volevo vedere cosa pensano gli altri.

Configurazione rapida: abbiamo una serie di interfacce che estendono le interfacce funzionali Java di Consumer, Function, ecc. per rendere la semantica più pulita. Uno di questi è il seguente. JaxbClass è un POJO dai binding XML generati da Jaxb e KbType è un Enum utilizzato per caricare i dati verso il basso. Praticamente un modo per avvolgere le classi vincolanti con la logica.

public interface KbTypeMapper extends Function<T extends JaxbClass, KbType>{}

La maggior parte delle classi che implementano questa interfaccia tengono traccia di alcuni stati interni e quindi è possibile avere più istanze di queste classi, ma per la classe corrente che sto implementando non esiste uno stato interno, quindi non c'è ragione per mai istanziare più di un oggetto di questa classe.

Gli oggetti che implementano questa interfaccia vengono solitamente iniettati come dipendenze e non cambierei questo per questa classe. La firma del param per la maggior parte dei casi in cui questa iniezione avviene è qualcosa sulla falsariga di Function<T,KbType> . Sostituirei semplicemente istanze come questa:

SomeClass x = new SomeClass(new SpecificKbTypeMapper())

Con:

SomeClass x = new SomeClass(SpecificKbTypeMapper.instance())

Potrei trasformarlo in una classe di tipo di utilità statica e iniettare solo StaticUtilility::functionName , ma in questo caso non si adatta al progetto generale e non implementerebbe effettivamente la nostra interfaccia personale che, a mio avviso, potrebbe confondere.

Non vedo un problema testare la classe stessa né prendere in giro la classe poiché la singola istanza viene ancora iniettata dove viene effettivamente utilizzata.

Ho torto completamente nel fatto che un singleton sia una soluzione perfettamente perfetta qui? O sono semplicemente in fase di progettazione e devo solo tenere un sacco di nuove istanze di oggetti?

java singleton

posta Hangman4358 12.06.2018 - 21:54

fonte

2 risposte

3

Il mio design per un'alternativa a singleton: static static

public static void main() {
    KbTypeMapper singleKbTypeMapper = new SpecificKbTypeMapper();
    SomeClass x = new SomeClass(singleKbTypeMapper);
    SomeOtherClass y = new SomeOtherClass(x, singleKbTypeMapper);

    y.doSomethingFun():
}

Ora non sto dicendo che le fabbriche non possono aiutare a nascondere la complessità. Semplicemente non ho bisogno o voglio che mi dica quante istanze posso avere. Lo deciderò io stesso.

risposta data 13.06.2018 - 03:41

fonte

Leggi altre domande sui tag java singleton

Come decidere correttamente quale sia l'errore di arrotondamento appropriato per una funzione matematica? Passare una callback fino in fondo o lanciare un'eccezione?

score 2 · Accepted Answer

Il peggiore problema di singleton dopo uno stato mutabile condiviso è un riferimento, che non può essere parametrizzato.

L'uso di un singleton stateless equivale all'utilizzo di classi istanziate ad hoc. Entrambi sono perfettamente validi, se il disaccoppiamento è ritenuto non necessario. Se il disaccoppiamento è necessario, entrambi funzionerebbero bene, essendo iniettati nel codice di livello superiore, come @orange dimostra.

In altre parole, i problemi dell'unicità di singleton non sono nella sua implementazione, ma nel modello di utilizzo, e non sono diversi dalla solita malizia di instatiazione ad-hoc di dipendenze complesse.

Qualunque cosa tu scriva nell'implementazione, non toglierai ai clienti la capacità di inquinare il codice base con riferimenti diretti ingiustificati. Rilassati, documenta lo schema di utilizzo previsto e mantieniti aggiornato sulle recensioni del codice.