Come progettate progetti orientati agli oggetti? [chiuso]

Sto lavorando a un grande progetto (per me) che avrà molte classi e dovrà essere estensibile, ma non sono sicuro di come pianificare il mio programma e di come le classi devono interagire.

Ho seguito un corso di OOD alcuni semestri indietro e ho imparato molto da esso; come scrivere UML e tradurre i documenti dei requisiti in oggetti e classi. Abbiamo anche imparato i diagrammi di sequenza ma in qualche modo mi è mancata la lezione o qualcosa del genere, non mi sono rimasti fedeli.

Con progetti precedenti ho provato a usare metodi che ho imparato dal corso ma di solito finisco con un codice che appena posso dire "sì, sembra qualcosa di simile a quello che avevo in mente" non ho voglia di scavare nel letame per aggiungere nuove caratteristiche.

Ho una copia del Codice completo di Steve McConnell che ascolto continuamente è sorprendente, qui e altrove. Ho letto il capitolo sul design e non sembra uscito con le informazioni che sto cercando. So che dice che non è un processo secco, che si basa principalmente sull'euristica, ma non riesco a prendere tutte le sue informazioni e applicarle ai miei progetti.

Quindi quali sono le cose che fai durante la fase di progettazione di alto livello (prima di iniziare a programmare) per determinare quali sono le classi di cui hai bisogno (specialmente quelle che non si basano su alcun 'oggetto del mondo reale') e come interagiranno tra loro ?

In particolare sono interessato a quali sono i metodi che usi? Qual è il processo che segui che di solito genera un design buono e pulito che rappresenterà da vicino il prodotto finale?

I passaggi che utilizzo per la progettazione iniziale (per arrivare a un diagramma di classe) sono:

1. Raccolta dei requisiti. Parlate con il cliente e valutate i casi d'uso per definire quale funzionalità dovrebbe avere il software.

2. Componi una narrazione dei singoli casi d'uso.

3. Passa attraverso la narrazione ed evidenzia i nomi (persona, luogo, cosa), come classi candidate e verbi (azioni), come metodi / comportamenti.

4. Elimina i nomi duplicati e ottimizza le funzionalità comuni.

5. Crea un diagramma di classe. Se sei uno sviluppatore Java, NetBeans 6.7 di Sun ha un modulo UML che consente di diagrammi e ingegneria di andata e ritorno ed è GRATUITO. Eclipse (un IDE Java open source), ha anche un framework di modellazione, ma non ne ho esperienza. Puoi anche provare ArgoUML, uno strumento open source.

6. Applica i principi OOD per organizzare le tue classi (estrai funzionalità comuni, costruisci gerarchie, ecc.)

Aggiungendo a ciò che Scott Davies aveva da dire:

1. Assicurati assolutamente di sapere di cosa tratta il tuo programma prima di iniziare. Qual è il tuo programma? Cosa non farà? Quale problema sta cercando di risolvere?

2. Il tuo primo set di casi d'uso non dovrebbe essere un elenco completo di tutto ciò che il programma alla fine farà. Inizia con il più piccolo set di casi d'uso che riesci a trovare che cattura ancora l'essenza di ciò a cui il tuo programma è destinato. Per questo sito Web, ad esempio, i casi d'uso principali potrebbero essere il login , porre una domanda , rispondere a una domanda e visualizzare domande e risposte . Nulla di reputazione, voto o wiki della community, solo l'essenza grezza di ciò per cui stai girando.

3. Quando ti vengono in mente potenziali classi, non pensare a loro solo in termini di quale nome rappresentano, ma di quali responsabilità hanno. Ho trovato che questo è il più grande aiuto per capire come le classi si relazionano tra loro durante l'esecuzione del programma. È facile trovare relazioni come "un cane è un animale" o "un cucciolo ha una madre". Di solito è più difficile capire le relazioni che descrivono le interazioni di runtime tra oggetti. Gli algoritmi del tuo programma sono importanti almeno quanto i tuoi oggetti e sono molto più facili da progettare se hai spiegato qual è il lavoro di ogni classe.

4. Una volta che hai quel set minimo di casi d'uso e oggetti, inizia a scrivere codice. Ottieni qualcosa che effettivamente viene eseguito il prima possibile, anche se non fa molto e probabilmente sembra una merda. È un punto di partenza e ti costringerà a rispondere a domande che potresti sorvolare su carta.

5. Ora torna indietro e scegli altri casi d'uso, scrivi come funzioneranno, modifica il tuo modello di classe e scrivi altro codice. Proprio come il tuo primo taglio, affronta il meno possibile alla volta aggiungendo comunque qualcosa di significativo. Risciacqua e ripeti.

Solo i miei due centesimi. Speriamo sia utile.

Quando ne ho avuto la possibilità, normalmente utilizzo quella che chiamo la "regola delle tre iterazioni".

Nella prima iterazione (o avvio), ho ideato il layout generale dell'applicazione in base agli oggetti del modello, agli algoritmi e al previsto ( davvero previsto, non forseprevisto) direzioni future. Non scrivo documenti di progettazione, ma se devo coordinare più persone, è ovviamente necessario uno schizzo approssimativo della procedura, insieme a un'analisi delle dipendenze e alla stima del tempo necessario. Cerca di ridurre al minimo questa fase se, come me, preferisci un metodo più agile. Ci sono casi in cui è necessaria una forte fase di progettazione, in particolare quando tutto è noto e vero sulla logica del tuo programma e se prevedi di avere molte interazioni tra le funzionalità del tuo codice. In questo caso, i casi d'uso o le storie utente fornite sono una buona idea di alto livello, in particolare per le app GUI. Per le app della riga di comando, e in particolare le librerie, prova a scrivere "storie di programmi" in cui codifichi la libreria che devi sviluppare e controlla come appare.

Dopo questa prima iterazione, avrai una migliore comprensione di come le cose interagiscono, tirando fuori i dettagli e i punti difficili, risolti i problemi con una patch schiacciata del nastro adesivo. Sei pronto a sfruttare questa esperienza per migliorare, pulire, lucidare, dividere ciò che era troppo grande, fondere ciò che era troppo frammentato, definire e utilizzare modelli di progettazione, analizzare colli di bottiglia delle prestazioni e problemi di sicurezza non banali. In generale, tutte queste modifiche avranno un impatto enorme sui test unitari scritti, ma non sui test funzionali.

Quando completi questa seconda iterazione, avrai un piccolo gioiello, ben testato, ben documentato e ben progettato. Ora hai sia l'esperienza che il codice per eseguire la terza iterazione, estendere. Aggiungerai nuove funzionalità e utilizzerai casi per migliorare la tua applicazione. Troverai punti difficili e alla fine entrerai in una quarta iterazione che è analoga alla seconda. Risciacqua e ripeti.

Questo è il mio approccio generale alla progettazione del software. È simile al design a spirale, con brevi iterazioni di tre mesi ed elementi di sviluppo Agile, che ti consente di imparare i problemi e conoscere il tuo software e il suo campo di applicazione. Certo, è una questione di scalabilità, quindi se l'applicazione è così grande da coinvolgere centinaia di sviluppatori, le cose sono un po 'più complesse di così, ma alla fine immagino che l'idea sia sempre la stessa, divide et impera .

Quindi riassumendo:

1. Nell'iterazione uno, ne assapori e impari
2. Nella seconda versione, ripulisci il tuo prodotto e lo prepari per il futuro
3. Nella terza versione, aggiungi nuove funzionalità e scopri di più
4. vai 2

La fonte più interessante che conosco a riguardo è la parte D di Object Oriented Software Construction, 2a edizione di Bertrand Meyer.

Parte D: Metodologia orientata agli oggetti: applicare bene il metodo

19: Sulla metodologia, 20: Modello di progettazione: sistemi interattivi multi-pannello, 21: Case study sull'ereditarietà: "annulla" in un sistema interattivo, 22: Come trovare le classi , 23: Principi di progettazione delle classi, 24: Usare bene l'eredità , 25: tecniche utili, 26: senso dello stile, 27: analisi orientata agli oggetti, 28: processo di costruzione del software, 29: insegnamento del metodo

È interessante notare che il capitolo 22. Come trovare le lezioni è disponibile online.

Spesso è ripetuto ma del tutto vero - capisci i tuoi dati.

Per OOP le tue lezioni dovrebbero descrivere informazioni salienti e il modo in cui interagiscono.

Se hai un modello mentale che descrive bene il comportamento e la durata dei dati, avrai una pedalata facile che espone le tue lezioni.

Questa è semplicemente un'estensione di: Conosci esattamente cosa stai cercando di fare.

Prova a utilizzare lo sviluppo basato sul comportamento. Sarà difficile rompere le tue vecchie abitudini, ma ho scoperto che BDD è davvero la soluzione migliore quando si tratta di sviluppare nel mondo reale.

http://behaviour-driven.org/

Il problema con progetti di grandi dimensioni è che non è possibile supervisionare tutte le interazioni tra i componenti. È quindi importante ridurre la complessità del progetto. I diagrammi di classe e sequenza sono troppo dettagliati per questa fase di progettazione.

Prima prova a pensare da un livello di astrazione più alto. Pensa ai componenti principali e alle loro responsabilità (la loro interfaccia con altri componenti), guarda alcuni modelli architettonici per ispirazione (no, non modelli progettuali, questi sono di livello troppo basso! MVC e Multi-Tier sono esempi di modelli architettonici). Per progetti abbastanza grandi, tale vista dovrebbe avere circa 3-5 componenti.

Solo allora ingrandisci un determinato componente e provi a progettarlo. Ora siamo a livello di modelli di progettazione e diagrammi di classe. Cerca di concentrarti su questa parte del progetto, se trovi che devi aggiungere una responsabilità a uno degli altri componenti, basta aggiungerlo alla tua documentazione / todo list. Non perdere tempo a pensare alle implicazioni a questo punto cambiano troppo rapidamente, rivedi quando il design è più solido.

Non è necessario progettare completamente ogni componente a questo punto, anche se è probabilmente saggio disporre di un pezzo di codice che implementa l'interfaccia dei componenti non implementati e generi risposte semplici ma utili. In questo modo, è possibile avviare lo sviluppo (e progettare) un componente alla volta e testarlo a un livello ragionevole.

Naturalmente, quando i nuovi componenti sono completati, è necessario verificare come (e se) si integrano tra loro prima di procedere.

In breve: prendi OO e il principio di nascondere le informazioni e portalo su un altro livello!

PS: fai molti schizzi durante la progettazione, è proprio come la vera architettura!

PPS: prova ad affrontare la questione da diverse angolazioni, pensa fuori dagli schemi (anche se la scatola potrebbe essere la strada da percorrere), discutere con i colleghi può essere molto utile per questo ... e hai qualcosa di cui parlare durante il pranzo.

La tecnica che ho usato in progetti reali con discreto successo è Responsibility Driven Design, ispirata al libro di Wirfs-Brock.

Inizia con le storie degli utenti di livello superiore e con i colleghi, su una lavagna, disegna le interazioni di alto livello che implicano. Questo ti dà la prima idea di quali siano i grandi moduli; e una iterazione o due di carte CRC di alto livello come il gioco dovresti aver stabilizzato un elenco dei componenti principali, cosa fanno e come interagiscono.

Quindi, se una qualsiasi delle responsabilità è grande o complessa, affina quei moduli fino a quando non hai cose che sono abbastanza piccole e abbastanza semplici da essere oggetti, giocando le interazioni all'interno del modulo per ciascuna delle principali operazioni identificate dalle interazioni di livello superiore .

Sapere quando fermarsi è una questione di giudizio (che viene solo con l'esperienza).

Modelli di progettazione

Modelli di design creazionale

Singleton: assicurarsi che venga creata solo un'istanza di una classe e fornire un punto di accesso globale all'oggetto.

Factory (versione semplificata del metodo Factory): crea oggetti senza esporre la logica di istanza al client e fa riferimento all'oggetto appena creato tramite un'interfaccia comune.

Metodo di fabbrica: definisce un'interfaccia per la creazione di oggetti, ma consente alle sottoclassi di decidere quale classe creare un'istanza e fa riferimento all'oggetto appena creato tramite un'interfaccia comune.

Fabbrica astratta: offre l'interfaccia per la creazione di una famiglia di oggetti correlati, senza specificare esplicitamente le loro classi.

Builder: definisce un'istanza per la creazione di un oggetto ma consente alle sottoclassi di decidere quale classe creare un'istanza e consente un controllo più preciso sul processo di costruzione.

Prototipo: specificare i tipi di oggetti da creare utilizzando un'istanza prototipica e creare nuovi oggetti copiando questo prototipo.

Modelli di progettazione comportamentale

Catena di responsabilità - Evita di allegare il mittente di una richiesta al suo destinatario, dando così ad altri oggetti la possibilità di gestire anche la richiesta. - Gli oggetti diventano parti di una catena e la richiesta viene inviata da un oggetto all'altro attraverso la catena fino a quando uno degli oggetti lo gestirà.

Comando: incapsula una richiesta in un oggetto, consente la parametrizzazione di client con richieste diverse e consente di salvare le richieste in una coda.

Interprete - Data una lingua, definisci una rappresentazione per la sua grammatica insieme a un interprete che usa la rappresentazione per interpretare frasi nella lingua / Mappa un dominio su una lingua, la lingua su una grammatica e la grammatica su un disegno gerarchico orientato agli oggetti

Iteratore: fornisce un modo per accedere agli elementi di un oggetto aggregato in sequenza senza esporre la sua rappresentazione sottostante.

Mediatore: definisce un oggetto che incapsula il modo in cui un insieme di oggetti interagisce. Il mediatore promuove l'accoppiamento libero impedendo agli oggetti di riferirsi esplicitamente tra loro e consente di variare la loro interazione in modo indipendente.

Osservatore: definire una dipendenza uno-a-molti tra gli oggetti in modo che quando un oggetto cambia stato, tutti i suoi dipendenti vengono notificati e aggiornati automaticamente.

Strategia: definire una famiglia di algoritmi, incapsulare ciascuno di essi e renderli intercambiabili. La strategia consente all'algoritmo di variare indipendentemente dai client che lo utilizzano.

Metodo modello: definisce lo scheletro di un algoritmo in un'operazione, rimandando alcuni passaggi alle sottoclassi / Metodo modello consente alle sottoclassi di ridefinire determinati passaggi di un algoritmo senza consentire loro di modificare la struttura dell'algoritmo.

Visitatore - Rappresenta un'operazione da eseguire sugli elementi di una struttura di oggetti / Visitatore consente di definire una nuova operazione senza modificare le classi degli elementi su cui opera.

Null Object: fornisce un oggetto come surrogato della mancanza di un oggetto di un determinato tipo. / The Null Object Pattern fornisce un comportamento intelligente senza fare nulla, nascondendo i dettagli dai suoi collaboratori.

Modelli di progettazione strutturale

Adattatore: converte l'interfaccia di una classe in un'altra interfaccia che i clienti si aspettano. / Adapter consente alle classi di lavorare insieme, cosa che altrimenti non potrebbe a causa di interfacce incompatibili.

Bridge: componi gli oggetti in strutture ad albero per rappresentare gerarchie intere. / Composito consente ai clienti di trattare i singoli oggetti e composizioni di oggetti in modo uniforme.

Composito: componi gli oggetti in strutture ad albero per rappresentare gerarchie intere. / Composito consente ai clienti di trattare i singoli oggetti e composizioni di oggetti in modo uniforme.

Decoratore: aggiungi ulteriori responsabilità in modo dinamico a un oggetto.

Flyweight: utilizzare la condivisione per supportare un gran numero di oggetti che hanno una parte del loro stato interno in comune dove l'altra parte dello stato può variare.

Memento: cattura lo stato interno di un oggetto senza violare l'incapsulamento e fornendo così un mezzo per ripristinare l'oggetto nello stato iniziale quando necessario.

Proxy: fornisce un "segnaposto" affinché un oggetto controlli i riferimenti ad esso.

Ti consiglierei di usare BlueJ e anche ActiveWriter per imparare e anche per sviluppare una buona comprensione degli oggetti. Il libro consigliato è anche una bella risorsa.

Da Wikipedia :

BlueJ è un ambiente di sviluppo integrato per il linguaggio di programmazione Java, sviluppato principalmente per scopi didattici, ma adatto anche per lo sviluppo di software su piccola scala.

Inoltre utilizza UML e per me è stata una buona risorsa per comprendere diverse cose sulla modellazione di oggetti.

testo alternativo http://www.ryanknu.com/ryan/bluej.png

ActiveWriter è uno strumento per modellare entità e relazioni, genera anche codice ed è facile apportare modifiche. Ti farà risparmiare tempo e per lo sviluppo agile è molto adatto.

_{(fonte: altinoren.com )}

Prima di tutto, il design dovrebbe provenire dalla tua anima. Devi sentirlo da ogni tua fibra. Di solito lo percorro per due o tre mesi prima di iniziare a fare qualsiasi cosa, semplicemente camminando per le strade (davvero). E pensare. Camminare è una buona meditazione, lo sai. Quindi ti consente di concentrarti bene.

In secondo luogo, utilizzare OOP e le classi solo dove esiste una gerarchia di oggetti naturali. Non "farsela" artificialmente. Se non esiste una gerarchia rigorosa (come nella maggior parte delle applicazioni aziendali), scegliere procedurale / funzionale o, almeno, utilizzare gli oggetti solo come contenitori di dati con accessori isolati.

E l'ultimo: prova a leggere questo: l'algoritmo del pensiero creativo

Ho appena citato http://www.fysh.org/~katie/computing/methodologies.txt

E al centro di RUP c'è una piccola area in cui devi usare i talenti del design OO .... se non li hai, è come avere una metodologia per gestire i 100m.

"Step 1: scrivi di correre molto velocemente. Step 2: Vai e disegna un piano per la pista. Step 3: vai a comprare pantaloncini di lycra molto stretti. Step 4: corri davvero, davvero, molto velocemente. Step 5: incrocia prima la linea "

È quel passaggio 4 che è quello difficile. Ma se metti molta enfasi su 1,2,3 e 5 è possibile che nessuno se ne accorga e quindi potresti probabilmente fare un sacco di soldi vendendo la metodologia per essere atleti che pensano che ci sia un "segreto" per essere un 100m runner over

Hai fatto domande che molti autori usano per scrivere un libro. Esistono numerose metodologie e dovresti sceglierne una che ti sembra "più carina".
Posso consigliare il libro "Domain Driven Design" di Eric Evans. Inoltre, controlla il sito dddcommunity.org .

Penso che la risposta qui dovrebbe essere molto diversa a seconda dell'esperienza reale del ragazzo che chiede.

Se hai solo uno o due anni di esperienza lavorativa, devi andare al punto che è: come arrivi al punto in cui conosci veramente i tuoi dati e capisci esattamente cosa stai cercando di fare?

Sì, se hai lavorato nel mondo reale per oltre 5 anni, sceglieresti uno dei tanti modelli o tecniche dei processi di sviluppo software.

Ma non fai esperienza leggendo solo libri. Dovresti imparare lavorando in un buon gruppo sotto una buona leadership.

Se ciò non è possibile, dovresti farlo da solo. Inizia iterando codificando un pezzo di codice probabilmente molto brutto, imparando i tuoi errori, scaricandoli tutti, codificandone uno migliore e così via.

Imparerai molto sulla tua base di codice. Gli strumenti sono strumenti, non ti insegneranno nulla.

Se disponi di competenze di dominio sul progetto, lavorerai come dire banking. È facile strutturare i tuoi oggetti e sai come arrivano questi miglioramenti a giorni alterni.

Se non hai quell'esperienza, lavora con qualcuno che ha quell'esperienza e converti quelle idee in dettagli tecnici.

Se sei confuso su come strutturare il design del tuo progetto. Segui ciecamente il libro "programmatore pragmatico". Ero nella stessa situazione prima, prova a leggere un capitolo di quel libro. vedrai la differenza, cambierà il tuo modo di pensare come sviluppatore di software.

1. studio e master design pattern.
2. Successivamente, scopri il Domain Driven Design
3. Successivamente, impara la raccolta dei requisiti

Ho seguito un corso di OOD alcuni semestri indietro e ho imparato molto da esso; come scrivere UML e tradurre i documenti dei requisiti in oggetti e classi. Abbiamo anche imparato i diagrammi di sequenza ma in qualche modo mi è mancata la lezione o qualcosa del genere, non mi sono rimasti fedeli.

4. Conosci il passaggio 3. Devi padroneggiarlo. Voglio dire, attraverso molta pratica per farlo diventare la tua seconda natura. Questo perché il metodo che impari è semplicemente contrario al modo in cui eravamo abituati. Quindi devi dominarlo davvero. Altrimenti, ti ritroverai sempre a tornare al tuo modo originale di fare le cose. Questo è in qualche modo come Test Driven Process, in cui molti sviluppatori Java si arrendono dopo alcuni tentativi. A meno che non lo padroneggino completamente, altrimenti è solo un peso per loro

5. Scrivi casi d'uso, specialmente per corsi alternativi. Il corso alternativo occupa oltre il 50% del nostro tempo di sviluppo. Normalmente quando il tuo PM ti assegna un'attività, ad esempio, crea un sistema di accesso, penserà che è semplice, puoi impiegare 1 giorno per completarlo. Ma non tiene mai conto di ciò che è necessario considerare, 1. cosa succede se l'utente digita una password errata, 2. cosa succede se l'utente digita una password errata per 3 volte, 3. cosa succede se l'utente non digita il nome utente e così via? Devi elencarli e mostrarli al tuo PM, chiedigli di riprogrammare la scadenza.

Temo che questa non sia una risposta che alla gente piace sentire . Comunque, lasciami esprimere la mia opinione.

OOP dovrebbe essere visto come uno dei paradigmi, non come il paradigma superiore. OOP è utile per risolvere determinati tipi di problemi, come lo sviluppo di una libreria GUI. Si adatta anche allo stile di sviluppo del software di solito seguito da grandi società di software: un team d'élite di designer o architetti stabilisce la progettazione del software in diagrammi UML o qualche altro mezzo simile e un team di sviluppatori meno illuminatotraduci quel disegno in codice sorgente. OOP offre pochi vantaggi se lavori da solo o con un piccolo team di programmatori di grande talento. Quindi, è meglio usare un linguaggio che supporti più paradigmi e ti aiuterà a elaborare velocemente un prototipo. Python, Ruby, Lisp / Scheme ecc. Sono buone scelte. Il prototipo è il tuo design. Quindi migliorerai su questo. Usa il paradigma che è meglio per risolvere il problema a portata di mano. Se necessario, ottimizza gli hot spot con estensioni scritte in C o in altri linguaggi di sistema. Utilizzando una di queste lingue, si ottiene anche l' estensibilitàgratuitamente, non solo a livello di programmatore ma anche a livello di utente. Lingue come Lisp possono generare ed eseguire dinamicamente codice, il che significa che i tuoi utenti possono estendere l'applicazione scrivendo piccoli frammenti di codice, nella lingua in cui il software stesso è codificato! Oppure, se scegli di scrivere il programma in C o C ++, considera di incorporare un interprete per un linguaggio di piccole dimensioni come Lua. Esporre le funzionalità come plugin scritti in quella lingua.

Penso che, la maggior parte delle volte, OOP e OOD creino software che sono vittime di over design.

Per riassumere, il mio modo preferito di scrivere software è:

1. Usa un linguaggio dinamico.
2. Scrivi il design (prototipo) nella stessa lingua.
3. Se necessario, ottimizzare determinate aree utilizzando C / C ++.
4. Fornire estensibilità tramite l'interprete del linguaggio di implementazione stesso.

L'ultima funzione consente al software di adattarsi facilmente ai requisiti specifici dell'utente (incluso me stesso!).

Uso Test-Driven Design (TDD). Scrivere prima il test ti aiuta a portare a un design pulito e corretto. Vedi http://en.wikipedia.org/wiki/Test-driven_development .

Scopri i modelli di progettazione . Negli ultimi due anni è stata la mia rivoluzione personale per quanto riguarda OOP. Prendi un libro. Ti consiglierei questo:

Head First Design Patterns

È in Java ma può essere estensibile a qualsiasi lingua.

Onestamente, un buon passo sarebbe tornare indietro e guardare al diagramma di flusso e ai diagrammi di sequenza. Ci sono un sacco di buoni siti che ti mostrano come farlo. Trovo che abbia un valore inestimabile quando osservo come voglio scomporre un programma in classi poiché so esattamente cosa deve essere immesso, calcolato e prodotto e ogni passaggio può essere suddiviso in una parte del programma.

Come risposto in Qual è il flusso di lavoro che segui per progettare il software che stai per scrivere?

Una tecnica utile è quella di mettere in relazione la descrizione del tuo unico problema con qualcosa che puoi trovare nel mondo reale. Ad esempio, stai modellando un sistema sanitario complesso che prenderà d'assalto il mondo. Ci sono esempi su cui puoi facilmente fare appello per modellarlo?

Infatti. Osserva come opererebbe la farmacia laterale o la stanza del medico.

Trasforma il tuo problema di dominio in qualcosa di comprensibile per te; qualcosa a cui puoi relazionarti.

Quindi, una volta che i "giocatori" all'interno del dominio iniziano ad apparire ovvi e inizi a modellare il tuo codice, scegli un approccio di modellazione "fornitore-consumatore", ovvero il tuo codice è il "fornitore" del modello e tu sei il "consumatore ".

Relazionarsi con il dominio e comprenderlo ad alto livello è una parte fondamentale di qualsiasi progetto.

Durante le mie avventure di progettazione di strutture di classe, ho notato che è molto utile iniziare a scrivere alcuni pseudo-codici. Ciò significa: inizio con la "scrittura" di alcuni frammenti generali del codice dell'applicazione al più alto livello, ci gioco e scopro gli elementi che appaiono - in effetti, gli elementi che io - come programmatore - vorrei usare. È un ottimo punto di partenza per progettare la struttura generale dei moduli e le loro interazioni. Dopo alcune iterazioni, l'intera struttura inizia a sembrare più un sistema completo di classi. È un modo molto flessibile per progettare parti di codice. Puoi chiamarlo un design orientato al programmatore.