Odore di codice javascript compilato: buone ragioni per classi grandi?

4

Ho consultato una libreria javascript per disegnare grafici, Dygraph, fonte su github .

Ha diverse classi enormi, come qui e here .

Personalmente, non penso che le giustificazioni per le classi grandi siano valide, poiché vanno contro i principi dell'OOP, come la singola responsabilità. In questo giorno ed età, anche i telefoni hanno un sacco di energia, quindi ad eccezione degli oggetti più fini, sembra una cattiva pratica. Ma anche allora, javascript usa spesso la boxe comunque.

Ora, non so davvero cosa faccia la precompilazione javascript oltre ad abbreviare i nomi dei simboli e rimuovere gli spazi bianchi, ma forse rende le classi grandi meno significative nell'aiutare le prestazioni?

In breve, la mia domanda è, se il codice precedente è stato rifattorizzato per rispettare la singola regola di responsabilità, quale tipo di degrado delle prestazioni potrebbe essere previsto? So che c'è un sacco di codice che potrebbe essere analizzato, ma forse ci sono alcune regole che i guru delle statistiche del codice potrebbero applicare? (So di aver visto motori di lanugine che fanno questo tipo di stime)

Modifica: la mia opinione è che è una cattiva pratica e dovrebbe essere evitata a meno che non sia fondamentale per le prestazioni. Sto solo dando agli autori il beneficio del dubbio

    
posta CL22 14.08.2016 - 16:36
fonte

1 risposta

12

Sono completamente in disaccordo con il presupposto che i requisiti di prestazione in un ambiente con risorse limitate abbiano mai giustificato grandi classi. Questo semplicemente non è come funziona.

Le classi di grandi dimensioni non vengono eseguite più velocemente o più lentamente. Sono solo più grandi. Sono il risultato di pensare alla codifica in modo diverso rispetto a "nel piccolo". La programmazione procedurale stipata nei moduli può comportarsi bene o male proprio come le piccole classi focalizzate possono avere un rendimento buono o scadente.

Per un po 'ci fu la percezione che le prestazioni non fossero qualcosa a cui OOP fosse bravo. Ciò si è dimostrato falso in quanto i programmatori addestrati all'ottimizzazione delle prestazioni hanno imparato a scrivere codice OOP reale anziché trattare le classi come un modulo di fantasia.

Al giorno d'oggi è davvero solo una scelta stilistica. Le classi grandi sono cattive non perché il computer non può gestirle. Sono cattivi perché non riesco a gestirli. Il codice ben organizzato e mirato è più facile da eseguire il debug e il refactoring. Ma attenzione, è possibile creare classi troppo piccole. Semplicemente non succede molto spesso.

Le classi dovrebbero essere il più piccole possibile, ma non più piccole.

Ma questo è solo per me. Il computer, onestamente, non gli interessa.

    
risposta data 14.08.2016 - 18:03
fonte

Leggi altre domande sui tag