La riusabilità è una funzione del buon progettazione del software .
La riusabilità è accettabile gloss ("breve notazione del significato") per una buona progettazione del software? Perché?
La riusabilità è una funzione del buon progettazione del software .
La riusabilità è accettabile gloss ("breve notazione del significato") per una buona progettazione del software? Perché?
Riutilizzare è un indicatore di buona progettazione. Indica che l' accoppiamento del sistema è abbastanza lento e il coesione di una particolare unità è abbastanza elevata da facilitare il riutilizzo senza incorrere in problemi di dipendenza o dover riscrivere la maggior parte del codice.
La riusabilità è in gran parte un'illusione. È verosimilmente impossibile misurare la "riutilizzabilità" di un'unità senza sapere in anticipo dove o come verrà utilizzata. Molti sviluppatori provano per progettare componenti "riusabili" e spesso scoprono in seguito che gli aspetti specifici che hanno cercato di rendere "flessibili" sono esattamente quelli che non hanno bisogno di essere.
Userei un "gloss" diverso: Testability
Ora non sono un sostenitore del TDD, né sento il bisogno di testare l'unità tutto e niente. Ma scrivere dei test per un componente ti darà un'ottima idea delle sue caratteristiche di accoppiamento / coesione e molto rapidamente. Se dipende dalle astrazioni, allora questo è un accoppiamento lento; troverai facile deridere le dipendenze e questo suggerisce un buon design. Se ha uno scopo chiaro (vedi anche Principio di singola responsabilità ) allora il suo comportamento sarà relativamente intuitivo, lo troverai facile per capire cosa testare, che di nuovo suggerisce un buon design.
Questo, naturalmente, garantisce un buon design; l'effettiva implementazione o anche l'intera architettura potrebbe essere del tutto inappropriata per il suo scopo dichiarato. Ma almeno ti dice che non stai lavorando con spaghetti code o God Objects.
Per favore, non cercare di fare ipotesi selvagge riguardo alla "riusabilità" di un componente, specialmente per non usarlo come prova del "buon design". Questo è qualcosa che puoi solo stabilire con il senno di poi, una volta che viene effettivamente riutilizzato, e quindi il design potrebbe essere cambiato in modo significativo.
No.
La riusabilità è una buona caratteristica, perché può accelerare lo sviluppo futuro. (Sebbene in pratica pochissime organizzazioni vedano lo sviluppo futuro accelerato quasi come speravano.) Tuttavia qualsiasi pezzo significativo di software ha parti specifiche per tale applicazione. Inoltre, quando le persone senza esperienza nel dominio cercano di scrivere software riutilizzabile, di solito nascondono quel pezzo e riducono le prestazioni senza riuscire effettivamente a renderlo riusabile.
Quindi un buon design è modulare e riutilizzabile solo dove è possibile vedere che il pezzo può essere riutilizzato e dove si ha l'esperienza per ottenere effettivamente la riusabilità. Altrove dovresti cercare di rendere le cose pulite, ma non preoccuparti della riusabilità. (Tranne che nella parte posteriore della tua testa dove stai prendendo appunti in modo che su qualche sistema futuro avrai un'idea su come renderlo riutilizzabile.)
Credo (e questa è la mia convinzione personale) che la relazione tra riusabilità e buon design non è riflessiva, quindi la risposta di base e semplice è no . Se sei interessato ad alcune buone guide di progettazione, consulta questo articolo di Wikipedia.
Un buon design del software deve essere riusabile, almeno in alcune parti fondamentali, penso che poche persone riescano effettivamente a riutilizzare il codice sorgente, perché è estremamente complesso progettare il nucleo di un sistema da riutilizzare a molti contesti diversi (e sto dicendo questo per esperienza)
Considera una classe con un'enorme quantità di responsabilità (a.k.a a Blob) che esegue tutte le attività di cui hai bisogno, ma senza alcun tipo di considerazioni progettuali, forse hai visto il caso. La maggior parte delle persone con una classe del genere lo userebbero ancora e ancora e penso che dovremo concordare che è riuso, riuso senza design.
Spero di non aver incasinato troppo le mie spiegazioni
Penso che un migliore indicatore del buon design sia l'adesione a idee fondamentali come il principio di responsabilità singola e il mantenimento della coesione di ciascun componente. Usando le astrazioni con un'interfaccia pulita e concisa e mantenendo la conformità con il Principio di sostituzione di Liskov incoraggiamo il riutilizzo senza tentare di prevedere ciò che sarà o non verrà riutilizzato.
Il rispetto di questi principi di progettazione fondamentali semplifica il riutilizzo del codice per testare e .
Design buono == buon design, la riusabilità è un sottoprodotto.
La riusabilità è spesso un obiettivo di progettazione implicito. Se puoi creare un componente, o un intero disegno, in modo tale che possa essere riutilizzato in seguito, sembra ovvio che dovresti farlo. Ciò che non è sempre ovvio è che può richiedere molto tempo e sforzi (e denaro) per rendere qualcosa riutilizzabile, e il beneficio della riusabilità deve quindi essere valutato rispetto al suo costo.
Un design riutilizzabile che costa il doppio e / o richiede il doppio del tempo rispetto a quello di cui il cliente ha bisogno non è un buon design dal punto di vista del cliente, soprattutto se il cliente non ha bisogno di riusabilità.
Esistono numerosi attributi simili che sono spesso considerati obiettivi di progettazione impliciti perché sembrano ovviamente buoni:
minimizzare i costi
riduzione dei tempi di sviluppo
riduzione della complessità
massimizzazione dell'affidabilità
Queste cose sono tutte obiettivamente buone, ma potrebbero non essere sempre importanti per un particolare cliente in un determinato momento, quindi è importante comprendere appieno le esigenze del cliente (anche se quel cliente è solo il tuo capo). Ci sono un certo numero di aforismi che sono pensati per ricordarci questo fatto (ad esempio "Fatto è meglio che perfetto" e "Buono, economico, veloce: scegli uno qualsiasi due"), ma è ancora facile cadere nella trappola di provare a fare software che è grande sotto tutti i punti di vista, quando in realtà non è sempre necessario un grande rispetto per tutti.
Per accedere alla domanda del titolo, quindi: No , la riusabilità non è sinonimo di buona progettazione. La riusabilità può essere un componente utile di un particolare buon design, ma solo quando è richiesto.
Non necessariamente. Se rendi riutilizzabile qualcosa che non verrà mai riutilizzato, allora è un cattivo design.
Ad esempio, se stai scrivendo un file pieno di dati che è univoco per la tua azienda e che i dati devono essere importati una volta altrove, perché preoccuparsi di renderlo riutilizzabile?
Detto questo, se il tuo framework non ne ha già uno, il codice per scrivere su un file potrebbe dover essere riusabile. Sarebbe un buon design.
Direi di no, principalmente perché descrive solo un piccolo segmento di codice. Ho scoperto che dove l'usabilità è più importante è al centro e ai margini esterni del territorio di utilità, non tanto nel mezzo. Darò alcuni esempi di cose in cui penso che la riusabilità sia un'utile metrica del design di qualità.
Core Stuff
Utility Utility
Per il materiale CRUD che occupa il 70-80% della maggior parte delle app, non penso proprio che la riusabilità sia una metrica valida.
Leggi altre domande sui tag design terminology