Quando è astrazione e modularizzazione una cattiva pratica di programmazione?

Question

appena visto questo commento in una "cosa JS lib si usa" sondaggio

"@ Xanti - sì, sì, modularizzazione e astrazione in programmazione è una pratica terribile funzioni che chiamano altre funzioni spreco.?".

E che mi ha lasciato curioso perché sto usando quadro Kohana per PHP e libreria jQuery per javascript.

Perché alcune persone considerano di astrazione e di modularizzazione cattive pratiche? Non sono framework e librerie realizzati per facilitare e accelerare lo sviluppo?

il sondaggio

Answer 1

Ho scoperto che troppa astrazione può essere pericoloso per la produttività:

• Un'astrazione mal scelto può essere peggio quindi non è un'astrazione a tutti.

• Se avete bisogno di leggere quattro o cinque moduli differenti, al fine di capire come funziona un semplice algoritmo, quindi le barriere di astrazione probabilmente non sono nei posti giusti. Forse c'è un buon modo di refactoring del codice, o forse sarebbe più facile solo per rimuovere le barriere.

• Se l'astrazione non corrisponde a un'idea relativamente familiare, può essere difficile per i nuovi membri del team per imparare.

L'astrazione non è una "buona senza cervello"; esiste per servire scopi specifici. Tra gli scopi più comuni sono

• proteggere gli invarianti di una struttura di dati

• incapsulare decisioni di progettazione che potrebbero cambiare

La mia più grande esperienza con l'astrazione intralcio era con il nostro compilatore ricerca per C-- . C'era molto di più l'astrazione di studenti sono stati abituati a vedere in classe del compilatore:

• Il computer di destinazione è stato estratto
• Il linguaggio assembly è stato estratto
• Le convenzioni di chiamata erano astratto
• La disposizione impilata telaio usato un "blocco" insolito astrazione

Ciascuna di queste astrazioni servito uno scopo importante per la nostra ricerca, ma l'effetto complessivo è che era molto difficile per i nuovi studenti di imparare il compilatore. Quindi, anche se il commento originale era per scherzo, ci sono luoghi in cui l'astrazione può causare problemi.

Answer 2

Quando si lavora su risorse limitate, si può facilmente aggiungere in testa.

Certo ci sono cose compilatore di ottimizzare via, ma se si crea quattro oggetti ordinate in quattro file .c pulito, compilarle a quattro file .so pulito e poi li collegano con un linker muto, chiamate di funzione cross-modulo che potrebbe essere facilmente inline ancora sono fatti con discarica stato pieno, pezzi che potrebbero essere ottimizzati via del tutto ancora eseguiti, e così via.

Vi assicuro se si avvia la programmazione di un microcontrollore PIC a 8 bit con 4K di RAM e 16K Flash utilizzando le migliori pratiche di linguaggi orientati agli oggetti, utilizzando modelli di progettazione avanzati e la creazione di più di uno strato di astrazione, il programma non verrà mai eseguito. "Ottimizzazione prematura è la radice di ogni male", è stato detto da un ragazzo che non ha mai programmato per una piattaforma che dispone di 128 byte di RAM.

Answer 3

Possiamo probabilmente assumerà il commentatore non era serio.

Non riesco a immaginare qualcuno sostenendo modularizzazione e astrazione sono cattiva pratica e in realtà significa che.

Answer 4

L'astrazione e la modularizzazione, in generale, sono buone ed essenziali. Ci potrebbe essere cattivi astrazioni là fuori, per esempio: i quadri che non sono supportati più o scelta costosi o semplicemente non utilizzabile, o grande, o non aggiornate, o 2 °, eccetera. La libreria "mercato", in generale, è enorme. Che tipo di librerie che si trovano da soli, usando dipende da circostanze e preferenze personali.

  

Perché alcune persone considerano di astrazione e di modularizzazione cattive pratiche? Non sono quadri e   librerie fatte per facilitare e accelerare lo sviluppo?

Cambia e l'apprendimento è a volte difficile - così la gente combattono. Se vi piace studiare questo tipo, si potrebbe iniziare la vostra ricerca presso: http://thedailywtf.com/ : - ) vorrei solo ignorarli e utilizzare librerie e framework come vi servono e rendere la vita programmatore migliore.

Answer 5

Uno sviluppatore si sostengono che un'astrazione o di modularizzazione è una cattiva pratica quando sono in grado o richiesto di interagire con detto l'astrazione o modularizzazione e sono in grado di capire il suo scopo o di design.

Answer 6

Quando tutte le funzioni (e le funzioni di supporto) è nel suo proprio modulo?

Answer 7

E 'stato tranquillo po' di tempo fa, ma un manuale per un compilatore FORTRAN consigliato di scegliere gli identificatori come stringhe della stessa lunghezza e lettere scelti a caso.

Spiegazione? bene permette per una distribuzione uniforme dei nomi nella tabella hash compilatore interno e per questo prevede la compilazione più veloce.

Penso che il testo che stai citando appartiene proprio accanto a questa raccomandazione

Answer 8

Le buone astrazioni sono usati spesso

Le buone astrazioni si fa riferimento a 2 o più posti nel software.

Esempi:

• Le funzioni con siti 2+ chiamata.
• classe astratta con 2+ classi concrete.
• Interfacce con 2+ implementazioni.
• I generici con 2+ istanze
• Le biblioteche con 2+ utenti.
• ecc.

Un'astrazione che è riferito a 2 o più posti aiuta a ridurre la dimensione del codice, dal factoring le cose comuni, e questa è una buona cosa.

Ma se avete un sacco di astrazioni cui fa riferimento una sola volta, poi ci è una buona probabilità che l'astrazione non è necessario.

Alcuni esempi in cui le astrazioni inutili venire:

• oggetto la scrittura di codice felice (interfacce e classi astratte che hanno ovunque solo 1 realizzazione o concrezione). Queste interfacce e classi astratte non sono necessarie (a quel punto dello sviluppo). YAGNI principio.
• Qualcuno costruisce un "nuovo fiammante" Interfaccia su quello vecchio, in cui le nuove funzioni dopo un po 'di conversione solo chiamano la vecchia interfaccia. Si può immaginare che un gran casino è il risultato, se si ripete più volte. In questo caso le vecchie funzioni avranno un unico sito di chiamata, quindi non sono necessari. È necessario spostare il codice dalle vecchie funzioni nel nuovo o non scrivere una nuova e modificare quello vecchio.

Alcuni esempi di veramente buoni astrazioni:

• Hardware Abstraction Layer: fornisce un'unica interfaccia per le applicazioni in modo che non hanno bisogno di sviluppare codice per ogni tipo di hardware
. Sistema
• File: Non importa si utilizza FAT, NTFS, EXT3 qualunque. Esso consente di utilizzare i file e le directory, il driver del file system fa il resto.
• linguaggio C: Non è necessario alla porta il vostro programma per ogni architettura della CPU. Basta compilarlo.

Quindi, per rispondere alla tua domanda in modo pragmatico: Le astrazioni sono cattivi, quando si fa riferimento da meno di 2 posti

.

Per quanto riguarda la modularizzazione, la sua soggettiva: è possibile organizzare il codice quello che vuoi. Se il codice sorgente della tua biblioteca si trova in un singolo file di origine che non lo rende peggio che se si mette esplodere diverse centinaia di file.

Quando un punteggio Il tuo astrazioni come buono o cattivo, sempre in considerazione il quadro generale:. L'intero progetto, l'intera linea di prodotti, ecc