Se fai questa domanda, non dovresti iniziare a progettare toolkit; -)
Mettendo scherzi via, la mia vista è la seguente (fatta in casa, senza grandi nomi riferiti).
Devi costruire un software, che risolverà un determinato compito. Avete alcune specifiche sui diversi oggetti dati, sulla logica aziendale associata, sul flusso di lavoro, sull'aspetto, sulle prestazioni, ecc. Requisiti che l'applicazione deve soddisfare in un determinato ambiente (desktop o server, SO, framework, ...)
Tuttavia, per raggiungere questo obiettivo, probabilmente impiegherete più tempo in "manutenzione" piuttosto che implementare l'algoritmo, il flusso di lavoro, ecc.: memorizzerete e leggete i dati persistenti, elaborate le informazioni di configurazione, i parametri della riga di comando, gli script, gestite il comunicazione tra la GUI e la logica aziendale, gestire gli errori. In scenari più complessi (come lo sviluppo di giochi), si impiegano enormi quantità di tempo non sulla codifica, ma solo configurazioni di edifici (come progettare una mappa di livello, attori, ecc.), Abilitare script e scrivere script. .. A volte è utile creare app helper indipendenti per fare queste cose. Quest'ultima roba è quella che chiamerei "livello del toolkit": non specificata direttamente come richiesta, ma è necessario che facciano il tuo lavoro. E migliore è la progettazione del livello del toolkit, più gli sforzi richiedono, ma alla fine, quando devi risolvere il tuo compito, gli strumenti lo rendono piuttosto semplice.
Semplificando: puoi risolvere i tuoi compiti uno per uno in modo indipendente o estrarre le somiglianze, risolverle una volta e risolvere un "vero" compito significa utilizzare il livello comune nell'ambiente specifico. Il problema: il livello comune è
- intrinsecamente più complesso, in quanto dovrebbe rispondere a "qualsiasi" domanda anziché a "uno",
- difficile da modificare perché molti altri codici dipendono da loro,
- e quando si rompe, potrebbe bloccarsi praticamente su qualsiasi cosa.
Bella teoria, cose difficili.
Se non hai una visione del toolkit dietro il tuo compito attuale, penso che non dovresti progettarlo. Progetta la tua applicazione in un modo piacevole e orientato agli oggetti : interfacce, classi astratte, componenti helper condivisi. Quest'ultimo sarà il tuo "toolkit layer" per questa applicazione. Se lo hai progettato bene, questo livello ti aiuterà quando aggiungi "un'ultima nuova caratteristica" o componente all'app poco prima della scadenza. Se puoi stimare bene il tempo richiesto in questa situazione, il tuo toolkit è buono.
... e se vivrai con questo farmaco-kit per 20 anni, non vedrai l'applicazione, ma solo il livello del toolkit. Questo è il motivo per cui creo un serializzatore JSON automatico con un livello di persistenza comune e un toolkit GUI di associazione dei dati per la mia sempre prima applicazione iOS. Semplicemente non posso farlo in un altro modo (e Objective C / Cocoa rocks) ...