Galleria mappe mentale L'arte della progettazione di strutture software
Quando vogliamo impartire ad altri la conoscenza sull'arte della progettazione di strutture software, sarà difficile convincerli ad accettare la nostra conoscenza perché non hanno un'esperienza simile alla nostra.
Modificato alle 2024-04-10 17:25:12Questa è una mappa mentale su una breve storia del tempo. "Una breve storia del tempo" è un'opera scientifica popolare con un'influenza di vasta portata. Non solo introduce i concetti di base della cosmologia e della relatività, ma discute anche dei buchi neri e dell'espansione dell'universo. questioni scientifiche all’avanguardia come l’inflazione e la teoria delle stringhe.
Dopo aver letto "Il coraggio di essere antipatico", "Il coraggio di essere antipatico" è un libro filosofico che vale la pena leggere. Può aiutare le persone a comprendere meglio se stesse, a comprendere gli altri e a trovare modi per ottenere la vera felicità.
"Il coraggio di essere antipatico" non solo analizza le cause profonde di vari problemi nella vita, ma fornisce anche contromisure corrispondenti per aiutare i lettori a comprendere meglio se stessi e le relazioni interpersonali e come applicare la teoria psicologica di Adler nella vita quotidiana.
Questa è una mappa mentale su una breve storia del tempo. "Una breve storia del tempo" è un'opera scientifica popolare con un'influenza di vasta portata. Non solo introduce i concetti di base della cosmologia e della relatività, ma discute anche dei buchi neri e dell'espansione dell'universo. questioni scientifiche all’avanguardia come l’inflazione e la teoria delle stringhe.
Dopo aver letto "Il coraggio di essere antipatico", "Il coraggio di essere antipatico" è un libro filosofico che vale la pena leggere. Può aiutare le persone a comprendere meglio se stesse, a comprendere gli altri e a trovare modi per ottenere la vera felicità.
"Il coraggio di essere antipatico" non solo analizza le cause profonde di vari problemi nella vita, ma fornisce anche contromisure corrispondenti per aiutare i lettori a comprendere meglio se stessi e le relazioni interpersonali e come applicare la teoria psicologica di Adler nella vita quotidiana.
L'arte della progettazione di strutture software
Prefazione
"Una volta rilasciata l'API, faciliterà la nostra convivenza eterna"
Quando vogliamo trasmettere la conoscenza agli altri, sarà difficile convincerli ad accettare la nostra conoscenza perché non hanno un’esperienza simile alla nostra.
Teoria e ragioni
"Arte" o "Ingegneria"
Importante unicità dell'API: coerenza
Come c'è coerenza all'interno del gruppo?
Lavoro di squadra perfetto
visione condivisa
termine pubblico
P2 Un anno dopo, ho confermato questa ipotesi. Poiché Netbeans è un progetto open source, esiste un'API che attrae sviluppatori esterni. All'inizio, questo collaboratore di codice esterno svolgeva principalmente un lavoro di correzione di bug. Successivamente ha iniziato a occuparsi da solo di un sottoprogetto e ha progettato le relative API. La persona originariamente responsabile della progettazione di questa API ha detto di aver scoperto che l'API di questo sottoprogetto stava peggiorando sempre di più, ma non è riuscito a trovarne il motivo e sperava che potessi aiutarla. Ha detto: Non gli piacciono molto queste nuove API e non vuole integrarle nei progetti di cui è responsabile. Ma non riusciva nemmeno a capire quale fosse il problema con queste nuove API. Infine, ha affermato che queste nuove API sembravano incoerenti con la sua visione originale. Una volta gli ho detto qualcosa di simile. Secondo i miei standard, l'API che ha scritto non è coerente con l'idea dell'API di NetBeans!
metodologia
razionalismo
Empirismo
Nessuna emozione
Comprensione superficiale
La portata della comprensione di qualcosa è limitata al sapere come usarla
profonda comprensione
Afferrare i principi e le leggi dietro qualcosa
Nella maggior parte dei casi è sufficiente una “comprensione superficiale”.
incapacità selettiva
Alcuni contenuti richiedono una comprensione approfondita
Il principio threadless dello sviluppo di applicazioni
Cercare di consentire al personale interessato, responsabile in ultima analisi, di svolgere un buon lavoro nell'integrazione senza dover comprendere a fondo il sistema.
Oggetto: persone
Criteri per valutare la qualità delle API
Perché?
Vogliamo essere in grado di assemblare "threadless" elementi costitutivi di grandi dimensioni in applicazioni
Che cosa?
Metodo, classe, firma del campo
File (tubo unix)
Variabili d'ambiente e opzioni della riga di comando
Informazioni di testo (toString)
protocollo
Comportamento
Il modo più importante per giudicare la compatibilità è il "funzionamento normale", ma questo è determinato dalla specifica implementazione interna.
valore restituito nullo
globalizzazione
…
Qualità
comprensibilità
Percorsi di comunicazione tra designer e sviluppatori
L'importanza degli esempi
consistenza
Abbassa la curva di apprendimento
rimanere compatibile
visibilità
Fornisci un "portale" per trovare le soluzioni di cui hai bisogno
Basato su obiettivi e compiti effettivi o attesi
Agli utenti non interessano classi specifiche
I compiti semplici dovrebbero avere soluzioni semplici
utente ordinario
utente esteso
proteggere gli investimenti
Pensa di più agli utenti
Cambiare obiettivi
compatibile con versioni precedenti
Compatibile con il codice sorgente
Compatibile binario
Funzionalmente compatibile
facile da perdere
Atteggiamento, i “buoni capi” non si lamentano dei clienti
L’importanza dell’orientamento al caso d’uso
Esempio
cosa dovrei fare
Scene
Dovresti fare prima questo e poi quello
Revisione della progettazione API (regole API eccellenti)
Utilizzare la progettazione API basata sui casi
Quando si progetta un'API, è necessario condurre un'analisi astratta basata su alcuni scenari specifici e sulla comprensione dell'API e infine fornire un progetto
Coerenza della progettazione API
Le API vengono spesso completate da più progettisti, ma l'intero team deve essere in grado di mantenere alcuni principi base di "migliori pratiche". Non importa quanto un'interfaccia sia ben progettata, finché viola la coerenza dell'intero team, preferiremmo accontentarci del secondo posto migliore.
API semplice e chiara
Le attività semplici e comuni dovrebbero essere più facili da gestire. Se progetti in base a un approccio basato sui casi d'uso, puoi verificare facilmente se queste API possono completare questi casi d'uso importanti attraverso scenari che possono essere facilmente implementati.
meno è meglio
Le funzioni fornite da un'API al mondo esterno dovrebbero includere solo le funzioni descritte nei casi d'uso. In questo modo si evitano discrepanze tra la funzionalità richiesta e quanto effettivamente fornito.
Miglioramenti del supporto
La biblioteca deve essere mantenuta continuamente. Anche se dovessero sorgere nuove necessità o se l'autore originale se ne andasse, questa libreria di classi non verrà abbandonata.
Pratica di progettazione
Rendi pubblico solo ciò che vuoi rendere pubblico
Facile da aggiungere, difficile da rimuovere
Quando rilasci la prima versione, rimuovi i contenuti non necessari
Metodi sui campi
Ad eccezione dei tipi base dichiarati statici e finali, delle costanti stringa, delle enumerazioni e degli oggetti immutabili, nessun altro campo dovrebbe essere esposto.
I metodi di fabbrica sono migliori delle funzioni
Il valore restituito da un metodo factory non è necessariamente un'istanza del tipo dichiarato, ma può essere un'istanza di una sottoclasse
L'oggetto restituito ogni volta non è necessariamente un oggetto appena creato, può essere memorizzato nella cache
Controllo della sincronizzazione, elaborazione unificata del codice prima e dopo la creazione di un oggetto
Rendi tutto immutabile
Se non vuoi avere sottoclassi, dovresti renderle non ereditabili
Evita di abusare dei metodi del setter
Non dichiarare mai metodi setter nelle API formali a meno che non sia necessario
setAbilita
Può essere sensibile al contesto
Il giudizio isEnable rende setEnable privo di significato
Esporre la funzionalità tramite metodi amici quando possibile
Metodo di accesso al pacchetto predefinito di Java, classe interna
Concedere ai creatori di oggetti più diritti
permesso di accesso
Evitare di esporre l'eredità profonda
riutilizzo del codice
Riutilizzo delle funzioni
L'"ereditarietà" non viene utilizzata per modificare comportamenti specifici, ma per aggiungere alcune azioni aggiuntive
Se erediti una classe solo per cambiare il percorso di esecuzione di determinati metodi, questo approccio dovrebbe essere evitato
Raccomandazione: evitare l'ereditarietà profonda, definire le interfacce del programma e consentire agli utenti di implementare queste interfacce
Programma rivolto alle interfacce piuttosto che alle implementazioni
Separazione tra definizione astratta (interfaccia) e implementazione
cooperare
Mettilo in chiaro agli utenti API: quando usi le API, dovresti seguire i principi corretti. Se devi utilizzare un'API, devi rispettare i principi dell'API e non infrangerla.
Spiega chiaramente i requisiti dell'API, definisci i casi d'uso corrispondenti e aiuta i progettisti di API a implementare tali API.
I metodi protetti non possono essere rimossi, con conseguente modifica da parte delle sottoclassi
L'aggiunta di un metodo astratto a un'interfaccia forzerà le sue sottoclassi non astratte a implementare il metodo
Architettura modulare
L'orientamento agli oggetti non evita la programmazione spaghetti
Lo scopo della modularizzazione: ottenere un accoppiamento lasco di vari componenti
L'architettura modulare separa le specifiche dall'implementazione
Nel modulo dove si trova la specifica ci sarà almeno una piccola "voce"
iniezione di dipendenza
Primavera
Ricerca Netbean
Espandere
P111 Nel 2001, abbiamo presentato un argomento chiamato "Posizionamento e cooperazione dei componenti" alla conferenza JavaOne. Il contenuto di questo argomento è in qualche modo correlato a questo capitolo. Riteniamo che il contenuto coinvolto in questo argomento sia importante per tutti i programmi modulari. Tuttavia, il comitato organizzatore della conferenza JavaOne in quel momento potrebbe semplicemente pensare che il nome dell'argomento non sia abbastanza interessante, o forse perché ritengono che la parola componente sia abusata e la parola "componente" includa quasi tutto l'immaginabile. quindi la questione non è stata accettata. Fino al 2006, io e il mio collega Tim Boudreau abbiamo presentato un argomento simile chiamato "Patterns of Discovery Injection e Dependency Injection in Modular Architectures". Come previsto, infatti, il tema è stato accettato dal comitato organizzatore. Ciò significa che devi trovare termini vicini al tuo pubblico di destinazione per impressionarlo. Quando hanno sentito la parola "iniezione di dipendenza", i loro cuori sono rimasti senza parole. Proprio come la parola API, un nome appropriato facilita la comunicazione. Per gli utenti, più è facile comprendere la parola API, più facile sarà per loro accettare il contenuto relativo all'API.
In effetti, ci sono alcune parole in più: architettura, modello
Quando si progetta un'API, distinguere tra i gruppi di utenti target
API
Può essere aggiunto ma non rimosso
Chiamato da altri per completare determinate funzioni
lezione finale
coeso, autonomo
SPI
Interfaccia del fornitore di servizi
Può essere rimosso ma non aggiunto
Per altri per estendere la funzionalità API
interfaccia
Evitare di mescolare i due
Decomporre ragionevolmente l'API
API
SPI
Classificazione dei NetBean
API principale
Supporto API
SPI fondamentale
Supporta l'SPI
Organizza la tua struttura API in base alle diverse esigenze dei tuoi gruppi di utenti
Tieni a mente la testabilità
Oggetto finto
Fornire oggetti mock per l'API
Il codice di prova fa parte delle specifiche
Buoni strumenti semplificano la progettazione delle API
procedura guidata
Consenti ai clienti di iniziare il prima possibile
Il primo obiettivo del progetto è portarlo rapidamente sul mercato
Ogni tecnologia importante in NetBeans ha una procedura guidata corrispondente per stabilire la struttura di base iniziale.
Suite di test di compatibilità
Per utenti SPI e implementatori API
Collabora con altre API
Utilizza le API di terze parti con cautela
modalità di confezionamento
Esporre solo contenuti astratti
Più si è esposti, meno spazio c’è per l’evoluzione.
Rafforzare la coerenza dell'API
Agenti e portafogli
Evita l'uso improprio dell'API
Ci deve essere coerenza tra tutti i livelli.
Alcuni contenuti del runtime specifico dell'API
“Notorious” – Invece di lamentarsi degli utenti, è meglio cambiare atteggiamento
"Guardian" - test automatizzati
Sincronizzazione e stallo
Descrivere in modo corretto e appropriato il suo modello di threading
Insidie nei monitor Java
L'ereditarietà influisce sulla sincronizzazione
Per le API pubbliche, i metodi esterni non possono essere dichiarati come sincronizzati.
Sincronizzazione Java e situazioni di stallo con insidie ovunque
programmazione dichiarativa
Idea di base: invece di lasciare che gli utenti API dicano al programma passo dopo passo cosa fare, devono solo comunicare al programma i loro risultati e poi lasciare che l'API faccia il lavoro.
L'implementazione di NetBeans Lookup richiede solo una semplice descrizione XML e non richiede la registrazione o il logout dell'utente.
auto-descrittivo
vita quotidiana
La vita reale è piena di fattori mutevoli e le cose teoriche non possono essere applicate immutate nella vita. Non solo devi sapere cosa funziona e cosa non funziona, ma devi anche sapere come lavorare per farlo
Le opinioni estreme sono dannose piuttosto che utili
API richiesta
è bello
è corretta
Se la facilità d'uso viene sacrificata a favore della correttezza, potrebbero sorgere più problemi
Mercurial e SVN
Mantienilo semplice
è ad alte prestazioni
Assolutamente compatibile
è simmetrico
Contraddizioni nella progettazione delle API
contraddittorio
Definizione Wiki: "Credere simultaneamente in due visioni contrastanti senza rendersi conto che sono contraddittorie"
Dipartimento di sicurezza
Sicurezza degli aerei
Gli sviluppatori si lamentano continuamente di cose come recensioni, standard di programmazione, ecc. Ma i guardiani dell’API devono stare sempre attenti, altrimenti potrebbero sorgere problemi a causa di una piccola svista. D'altronde non è solo un problema minore, quantomeno dimostra che il lavoro che stai facendo è davvero utile.
rapporto di minoranza
Migliora l'API
Lavoro di squadra
Condurre revisioni del codice prima di inviarlo
Convinci gli sviluppatori a fornire la documentazione per le loro API
Ragionamento a ritroso
prima di scrivere il codice
Panoramica
FAQ
Un monitor coscienzioso
Gli strumenti monitorano tutte le modifiche che richiedono attenzione
Se non hai strumenti, hai bisogno di qualcuno che sia “onnisciente e onnipotente”
Ricevi patch API
Accetta solo i buoni consigli
Sviluppare requisiti
I requisiti non possono essere troppo complicati
Utilizza i giochi di competizione per migliorare le capacità di progettazione delle API
Fornito per il download da www.xmindchina.net