Utilizzo di Structs per organizzare il codice

Esempi con termini come "Foo", "Bar", "Altro" e "Altro" sono raramente utili quando si tratta di problemi di progettazione. Quindi, supponiamo che il codice "reale" assomigli più a questo:

 public struct NetworkSettings
 {
      public string ConnectionString { get; set; }
      public ProtocolType Protocol { get; set; }
      public double Timeout { get; set; }
 }

 public struct DatabaseSettings
 { 
       public string ConnectionString { get; set; }
 }

(potrebbero anche essere classi invece di structs, ma in questo caso non fa una grande differenza).

Questo potrebbe non essere il design finale "perfetto", ma almeno è meglio che avere un gruppo di variabili singole come

   public string NetworkConnectionString { get; set; }
   public NetworkProtocolType Protocol { get; set; }
   public double NetworkTimeout { get; set; }
   public string DatabaseConnectionString { get; set; }

Quindi i nomi struct forniscono almeno nomi di gruppo significativi e i parametri hanno un significato che diventa più chiaro quando vengono visualizzati nel loro contesto specifico. Se è il tuo caso, la risposta è "sì, questo ha senso" - perché il codice diventa più leggibile.

Naturalmente, questo non è fine a se stesso - quando ciascuna delle strutture contiene solo un singolo valore, oi nomi non stanno chiarendo, oi nomi dei gruppi sembrano essere artificiali, quindi il raggruppamento perde i suoi benefici e uno meglio rimuoverlo o trovare un gruppo migliore.

Ho visto anche questo usato. Una possibile ragione è che con diciamo 10+ impostazioni, diventa difficile scegliere quello giusto anche con Intellisense. Ma se sono suddivisi per categoria / sottocategorie, quando si digita "." per ottenere previsioni Intellisense, ottieni solo 3-4, quindi puoi scavare per area.

È solo un modo per semplificare le cose per l'utente client

E poiché esiste un singleton con TUTTE le impostazioni, la probabilità di avere molte proprietà è alta. Quindi aiuta a organizzarli. Certo che avrebbero potuto definire 5 classi di differenza per diversi tipi di impostazioni, ma rende solo le cose molto più confuse, ora devi dare la caccia ai nomi delle classi

Sono d'accordo con te sul fatto che "le strutture vengono usate come un modo per separare il codice tra le diverse aree di app" e servono come "pseudo namespace".

Sulla base di questa convinzione, la mia ipotesi è che lo sviluppatore stesse usando una struct, un tipo di valore, invece di una classe, un tipo di riferimento, per evitare la necessità di scrivere codice per istanziare istanze di classe per i propri campi. Ad esempio, se i campi "otherSettings" e "moreSettings" del codice di esempio erano stati tipi di classi, è necessario creare un'istanza delle classi prima di accedere ai campi in questo modo:

 // Initialize class field values
 otherSettings = new OtherSettings();
 moreSettings = new MoreSettings();

 ...

 // Access fields after instantiation from some other class
 var c = Settings.Instance.moreSettings.ConnectionString2;
 var c2 = Settings.Instance.otherSettings.OtherConnectionString;

Invece, come tipi di struct, i campi non hanno bisogno di istanziazione e possono essere consultati direttamente in questo modo:

 // Access fields without needing any instantiations
 var c = Settings.Instance.moreSettings.ConnectionString2;

Usando le strutture, lo sviluppatore non ha bisogno di fare le istanze di classe e di salvare alcune sequenze di tasti.

Personalmente, se l'utilizzo era limitato e puramente per scopi "pseudo namespace", non vedo alcun problema nel farlo in questo modo poiché semplifica la codifica.

Oltre a mantenere l'ambito dei sottotipi locali, che è buono, i tipi di valore consentono una serializzazione più efficace se le impostazioni fossero mantenute su un file. L'uso delle strutture è appropriato poiché le impostazioni sono comunque solo un gruppo di tipi di valore e non rappresentano un'entità di dominio problematica che richiede funzionalità di classe. Quindi saluto questo approccio e prenderei in considerazione l'idea di usarlo da solo.