Esiste una tecnica di analisi molto semplice in cui annotare i casi d'uso in testo semplice ed estrarre nomi e verbi. Probabilmente i sostantivi sono concetti essenziali nel tuo dominio (quindi probabilmente classi), i verbi sono probabilmente azioni da intraprendere nel dominio (quindi probabilmente metodi). Questa regola non è scritta in pietra ma può aiutarti ad andare avanti. Quando ho seguito dei corsi sull'analisi Object-Oriënted ci hanno iniziato con questo metodo, ma è qualcosa che impari a fare "a memoria" senza pensarci troppo con un po 'di pratica.
Diamo un'occhiata a un esempio *
Un cliente può effettuare una prenotazione per un libro in una biblioteca. Per fare ciò, deve verificare la disponibilità del libro nella biblioteca. Se il libro è disponibile per il periodo in cui l'utente desidera prestarlo, può concedere un prestito alla biblioteca per prestare il libro per un determinato periodo.
Nomi pertinenti
- Clienti
- Prenotazione
- Prenota
- Libreria
- Disponibilità
- Periodo
- Prestito
Verbi rilevanti
- Crea (prenotazione)
- Verifica (disponibilità)
- Make (lending)
Questo mi porterebbe a un sistema in cui ho una classe Book che appartiene a una classe Library. La classe Library contiene anche un elenco di prenotazioni e prestiti. Sulla libreria ci sarebbe un metodo makeReservation che crea una prenotazione per un libro durante un periodo. Ci sarebbe anche un make lending che crea un prestito per un libro durante un periodo. Infine, sarebbe presente un metodo checkAvailability che restituisce informazioni sulla disponibilità di un Libro durante il Periodo.
Il modo in cui procedi è principalmente una questione di preferenze personali. Ci sono alcuni principi guida che potresti prendere in considerazione durante la progettazione di questo ( SOLID e Law Of Demeter vengono in mente) quindi in questo senso ci sono soluzioni "buone" e "meno buone". Ma se ha più senso per te che la classe Book abbia un metodo Borrow che crea un oggetto di prestito sul libro, non c'è niente di sbagliato in questo.
Cose come il Single Responsibility Principle (SRP, la S in SOLID) possono aiutarti a guardare il design che pensi funzioni e analizzarlo. Ad esempio, con la mia proposta di progettazione Libreria viola l'SRP in quanto è responsabile della creazione di prenotazioni, la creazione di prestiti e il controllo delle disponibilità. Spiegando il ruolo della classe Library posso immediatamente vedere che violento SRP e potrebbe esserci un design più ottimale.
Poi di nuovo, se dovessi applicare tutti i principi SOLID alla lettera non saresti in grado di scrivere alcun codice ...
* Semplificato per ovvi motivi, in realtà le librerie avrebbero più copie di alcuni libri ecc ...