Qual è la differenza tra i metodi all-static e l'applicazione di un modello singleton? [duplicare]

Perché Singleton e il metodo statico sono le tue uniche opzioni?

Dal mio punto di vista, entrambe le opzioni sono piuttosto negative. Leggi su Singleton AntiPattern . La maggior parte dei casi d'uso di Singleton Pattern non è corretta.

Nel tuo caso, vorrei utilizzare un oggetto istanza e usare dependency injection (se stai usando un framework DI) o un servizio localizzatore / modello di registro

Con una classe singleton, hai un maggiore controllo in termini di come gestisci l'oggetto che è stato creato.

In primo luogo, un singleton è un oggetto. Il metodo statico restituisce un'istanza dell'oggetto e ti consente di creare solo una singola istanza o più se lo desideri.

Anche i singleton sono pigri, il che significa che non vengono istanziati fino alla prima chiamata.

Un singleton non usa metodi statici, quindi non avrai problemi ad usarlo in un contesto non statico.

I singleton possono essere estesi / sottoclasse.

Poiché sono oggetti, possono essere iniettati in altri oggetti, che consentono la creazione di alcuni grandi schemi di progettazione che utilizzano i concetti di iniezione di dipendenza. Ad esempio, questo è il modo in cui funziona il modello Spring Bean IoC (Inversion of Control Dependency Injection).

What is the difference between all-static-methods and applying a singleton pattern?

Entrambi hanno lo stesso effetto: puoi chiamare un metodo di classe senza preoccuparti di come ottenere un'istanza della classe che contiene il metodo.

Tuttavia, se vuoi implementare i metodi statici di Unittesting sono più problematici perché non possono essere facilmente derisi .

Dal punto di vista della sperimentazione è più facile riscrivere il codice che usa i singelt per renderli inagibili con i mock.

L'anima più flessibile sarebbe avere Dependency_injection non importa se stai usando un di-container-framework (come suggerito da @ Tazzy531) o se si stanno collegando le dipendenze tramite codice.

Né è l'ideale, ma soprattutto non un mucchio di statici. Ecco un esempio del mondo reale dalla mia esperienza. Abbiamo parlato con un database. Tutti hanno detto "ce ne sarà solo uno", quindi qualcuno ha usato un singleton standard configurato da Spring. Poi è stato aggiunto un nuovo requisito: poter copiare i nostri dati su un altro (remoto) database. Ops. Dato che avevamo un oggetto reale che rappresenta il DB, e questa era una caratteristica "usata raramente", sono stato in grado di modificarlo eseguendo una copia temporanea e cambiando campi e valori, ma se fosse stato implementato con statistiche globali sarebbe stato un vero disastro.

Nella mia esperienza, quando "loro" dicono che ci sarà solo un DB, un utente, un'applicazione, una finestra principale, ecc., "loro" sono sbagliati. Con un Singlton almeno avere una possibilità di refactoring e risolvere il problema.

Spero che questo risponda solo alla domanda principale qui.

Ci sono già poche ottime risposte in SO . Li citerò solo.

Risposta migliore, per Heinzi :

A singleton is used to introduce some kind of global state to an application. If it is stateless, I also don't see the point of using a singleton, unless

• you expect to extend it with state in the foreseeable future or
• you need an object instance for some particular technical reason (for example, for the C# SyncLock statement, although this is already quite far-fetched) or
• you need inheritance, i.e., you want to be able to easily replace your singleton with another one using the same interface but a different implementation. For example, the Toolkit.getDefaultToolkit() method in Java will return a singleton whose exact type is system dependent.

Alto commento pertinente, per back2dos :

(...) singletons are misused to introduce global states. The purpose of a singleton is not to make an object globally available, but to enforce that an object is instantiated only once. Global objects are a necessary evil. Unless really required, one should try not to use them, since they generally lead to high coupling, with SomeSingleton.getInstance().someMethod() all over the place.

tzaman ha anche scritto una buona risposta:

I could see a case for a stateless singleton being used instead of a static methods class, namely for Dependency Injection.

If you have a helper class of utility functions that you're using directly, it creates a hidden dependency; you have no control over who can use it, or where. Injecting that same helper class via a stateless singleton instance lets you control where and how it's being used, and replace it / mock it / etc. when you need to.

Making it a singleton instance simply ensures that you're not allocating any more objects of the type than necessary (since you only ever need one).

E infine Sebastien si è anche risposto abbastanza bene:

Actually i've found another answer not mentionned here: static methods are harder to test.

It seems most test frameworks work great for mocking instance methods but many of them no not handle in a decent way the mock of static methods.

Detto questo, ti consiglio di utilizzare il modello Toolbox .