implicazioni di una grande classe parziale

Question

implicazioni di una grande classe parziale

#1 da (13 voti)

6

Sto scrivendo uno strato intermedio tra il codice fornitore e la logica aziendale dell'azienda. Parte dell'esercizio consiste nell'isolare la nostra logica aziendale dai tipi di fornitore per facilitare lo scambio del codice fornitore.

Come tale, sto scrivendo un sacco di metodi di estensione che fanno la traduzione da e verso. Sto posizionando queste estensioni in classi parziali statiche pubbliche. Per scopi organizzativi e semplicemente perché, per i metodi di estensione statici, la classe non ha importanza (si tratta di una assunzione corretta btw?)

EDIT: Per essere chiari, sto creando molti file sorgente con nome appropriato, che hanno implementato una classe parziale

La mia domanda è, quanto codice è troppo per una classe parziale. Potrei concepire di avere 100 di metodi in una singola classe (ad un certo punto). Quando questo diventa un peso per il compilatore e il livello CIL? C'è davvero un limite se queste classi parziali non contengono stato / memoria?

design c#

posta Dmitry 28.03.2013 - 22:09

fonte

1 risposta

Leggi altre domande sui tag design c#

Che cosa può fare l'API REST che un'API utilizzando le stringhe di query URL HTTP non può fare? I decoratori non sono in grado di rompere facilmente l'ISP?

score 13 · Accepted Answer

TLDR: una singola classe con centinaia di metodi va benissimo, non si avranno problemi se non si hanno migliaia di metodi.

Per verificarlo correttamente, ho creato il seguente modello T4 in Visual Studio:

class LotsOfMethods
{
    <# for (int i = 0; i < 100; i++) { #>
    public static void M<#= i #>()
    {
    }
    <# } #>
}

Variando la costante nel ciclo, posso scoprire come si comportano vari numeri di metodi. A quanto pare, 100, 1 000, 10 000 o persino 100 000 metodi si compilano bene (anche se in questi ultimi casi la compilazione richiede più tempo di un singolo progetto con una o due classi normalmente e VS anche a volte si blocca per pochi secondi ).

Quando ho provato a eseguire effettivamente il codice, i casi con 100, 1 000 o 10.000 metodi erano tutti perfetti. La parte interessante è che quando provi ad usare la classe con 100.000 metodi, otterrai un'eccezione:

System.TypeLoadException: Type 'LotsOfMethods' from assembly 'ConsoleApplication1, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null' contains more methods than the current implementation allows.

In particolare, questa eccezione si verifica quando la classe ha 65 521 (2 ¹⁶ -15) metodi o più. (Una domanda interessante è perché esattamente questo numero. Cosa significa il 15?)

Un'altra osservazione è che più metodi in una classe rendono la compilazione JIT più lenta. (O sono più metodi in un assembly? Non l'ho provato.) Quando eseguo 500 dei metodi ottengo i seguenti risultati:

Per una classe con 65 520 metodi:

For the first time: 2,2079481 s
For the second time: 0,0003259 s

Con 1 000 metodi:

For the first time: 0,0545898 s
For the second time: 0,0003138 s

E 500 metodi:

For the first time: 0,0361426 s
For the second time: 0,0003226 s

I risultati sono stati misurati utilizzando il seguente codice:

var sw = Stopwatch.StartNew();

int n = 500; // this is constant no matter how many methods does the class have

for (int i = 0; i < n; i++)
{
    typeof(LotsOfMethods).GetMethod(string.Format("M{0}", i)).Invoke(null, null);
}

var first = sw.Elapsed.TotalSeconds;
sw.Restart();

for (int i = 0; i < n; i++)
{
    typeof(LotsOfMethods).GetMethod(string.Format("M{0}", i)).Invoke(null, null);
}

var second = sw.Elapsed.TotalSeconds;

Console.WriteLine("For the first time: {0} s", first);
Console.WriteLine("For the second time: {0} s", second);