Il framework .NET viola i principi SOLID? [chiuso]

Toccateli uno per uno.

S è per la singola responsabilità

• L'unica responsabilità di XMLDocument è fornire API per attraversare un documento XML
• Sì, la sua interfaccia ha metodi per il salvataggio e il caricamento, ma l'implementazione di XMLDocument non viene effettivamente salvata o caricata. Analizza o analizza in relazione a un'astrazione, un "flusso", che dovresti fornire al documento XML per far funzionare quei metodi. Il parsing e il unparsing sono associati naturalmente al traversal. La persistenza non è gestita dalla classe stessa.
• Anche le classi Stream e StreamReader / Writer lo fanno. Lavorano su rappresentazioni logiche, un array di byte infinito teorico, che viene attualizzato in uno dei sottotipi, ad esempio MemoryStream o FileStream .

O è aperto / chiuso

Moot. Tutte le classi del framework sono chiuse alla modifica, a meno che non si stia facendo qualcosa di veramente strano.

L è per Liskov Sostituzione

Abbastanza sicuro di poter sostituire qualsiasi tipo di flusso quando è necessario un vapore; Chiunque stia utilizzando lo stream generalmente non si preoccuperà se si tratta di un flusso che va in memoria, su disco o su una connessione di rete. Se vi sono differenze di capacità (ad esempio, a un flusso di rete non viene fornito accesso casuale) tali capacità sono rilevabili tramite proprietà nella classe di base, ad es. CanSeek .

I è per Interfaccia segregazione

Microsoft è stata un po 'lenta nel fornire interfacce per molte delle sue classi. Detto questo, puoi facilmente scrivere codice che funzioni con tipi di base astratti anziché tipi concreti, ad es. puoi scrivere codice che funziona con qualsiasi tipo di stream purché erediti da BaseStream .

D è per Inversione di dipendenza

XMLDocument e le classi di flusso utilizzano entrambe l'iniezione di dipendenza, seguendo il principio dell'inversione del controllo. In effetti, StreamReader e StreamWriter sono due dei primi esempi di questo principio, poiché prendono il flusso sottostante come argomento del costruttore (tramite l'implementazione di base astratta di un flusso, che è buono come accettare un'interfaccia). XMLDocument utilizza DI consentendo a un flusso di base astratto di essere iniettato come argomento del metodo su Salva o Carica.

Quindi no, non sono d'accordo con te, penso che .NET framework faccia un buon lavoro seguendo SOLID.