È possibile incapsulare l'oggetto stesso all'interno di una proprietà dinamica?

Quello che sembra vogliate è una classe statica semplice. La classe e tutti i suoi membri sono semplicemente dichiarati statici. Ad esempio:

public static class Foo
{
   static Foo()
   {
       //initialize any state data needed by methods
   }

   public static void Bar()
   {
      //...
   }
}

//usage, just as you wanted
Foo.Bar();

Il problema di base con questo è che tutto nella classe deve essere dichiarato statico e deve essere sempre accessibile in modo statico. Ciò a sua volta significa che una volta che questo codice viene utilizzato in più di un paio di punti, non si può davvero cambiare la sua architettura per essere più orientata agli oggetti. Di solito significa anche che la classe non può avere alcuna gerarchia di ereditarietà, perché qualsiasi genitore o figlio dovrebbe anche essere statico, e se il genitore è statico e tutti i bambini sono statici, in realtà hai solo tre classi parziali. Ad esempio, in C # non è possibile derivare una statica da un'altra classe e non ereditare da una statica; sono stranezze singole, isolate e ampiamente circoscritte del codice base.

Le statistiche in generale devono essere ridotte al minimo perché, come sopra, violano alcuni principi chiave della progettazione del codice SOLID e del codice orientato agli oggetti in generale (nel mondo reale che OOA & D tenta di modellare, ci sono molto, pochissime generalizzazioni di oggetti che non hanno genitori, senza figli, e ci sono e possono essere sempre e solo una di esse).

Questi sono i problemi che il modello Singleton risolve, per la maggior parte. La classe stessa non è statica, ma ha due o tre membri statici; un costruttore in modo che possa inizializzarsi automaticamente e un accessore all'istanza (che può utilizzare un campo di supporto specifico o una proprietà automatica). Mentre si dispone ancora di stato statico e disponibilità statica che sono tipi di no-nos, il singleton consente di utilizzare l'istanza come un'istanza, passandola tra classi e metodi come dipendenza, senza che nessuno di questi oggetti di livello inferiore debba sapere che è stato fissato in modo statico o che può esserci sempre un'istanza. Poiché la classe stessa non è statica, se lo si desidera, è possibile implementare interfacce o estendere le classi base, e in teoria è possibile derivarne, anche se ciò diventa molto complicato molto rapidamente.

Il compromesso fa sempre riferimento all'istanza quando si usa il singleton nello stato statico. Ci sono modi carini per mitigarlo, ma ho incluso solo gli esempi qui sotto perché pensavo che fossero divertenti; NON UTILIZZARE QUESTI MAI :

public class F
{
   static F() {instance = new F();}

   private F() {...}
   public static F oo {get{return instance;}}

   public void Bar() {...}
}

...

//FXCop (and most of your fellow coders) will curse your name
F.oo.Bar();

public class Fo
{
   static Fo() {instance = new Fo();}

   private Fo() {...}
   public static F this(int useZeroItsFunny) {get{return instance;}}

   public void Bar() {...}
}

//a WTF if there ever was one...
Fo[0].Bar();

No, non lo è.

Ma se usi spesso il singleton, puoi sempre creare una variabile locale con riferimento all'istanza.

Ma prenderei in considerazione l'uso così pesante del singleton come codice dell'odore e mi chiederei se dovresti usare un singleton.

No, c'è (per quanto ne so) attualmente una limitazione nella DLR in cui le sostituzioni dinamiche non vengono applicate ai membri statici. Puoi eseguire trucchi con una variabile in modo che reindirizzi tutte le chiamate a un singletone, o anche tramite i metodi di estensione in modo che ogni oggetto abbia un membro .Foo() che puoi chiamare un singleton .Bar() attivo. Puoi persino fare trucchi con gli operatori di conversione impliciti in modo che Ploof assomigli e agisca come un elenco.

Ma ancora una volta, tutto questo è orribile e mal consigliato - anche più di singleton in primo luogo.