Distinguere classi: come rilevare il comportamento del sistema nelle classi (caso del sistema di libreria)

0

Supponiamo un sistema di libreria. se penso a Dati , posso solo distinguere Book , Member classi o al massimo Author o Publisher ... (Sono solo classi?), ma ne ho alcuni casi d'uso, scenari (prestito, consegna, prenotazione ...). Solo io non so quando e come distribuirli nelle classi menzionate, o dovrei introdurre nuove classi

Se penso a Single Responsibility e Separation of Concerns , mi suggeriscono molte altre classi per qualsiasi responsabilità come Borrow per i prestiti, BookRepository per salvare e libro di riserva, ecc ....

Mi piacerebbe sapere come trovi le classi di questo specifico esempio o come usi il principio Single Responsibility per trovare le classi.

La risposta di questo questionario ha alcuni punti positivi ma manca un esempio di chiarimento.

    
posta Ahmad 10.03.2015 - 09:18
fonte

2 risposte

2

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 ...

    
risposta data 10.03.2015 - 09:43
fonte
1

Il trucco è specificare il comportamento desiderato in un linguaggio semplice.

"Un membro prende in prestito un libro"

Hai due nomi in quella frase. Ogni nome è probabile che finisca come una classe-- nel tuo caso Book and Member.

C'è anche il verbo "prendere in prestito" questo probabilmente finirà come un metodo in una delle classi, e molto probabilmente il soggetto - è il membro che lo sta facendo in modo che il metodo "in prestito" dovrebbe far parte di la classe membro.

Quindi arriviamo agli aggettivi che il membro fa il prestito, ma un libro può essere "preso in prestito". Ne consegue che dovresti in qualche modo registrare lo stato "preso in prestito" nella classe del libro, forse anche chi ha preso il prestito.

Finalmente nella vita reale le cose sono fatte di altre cose. Potrebbe essere sufficiente memorizzare il nome del publisher come attributo della classe Book, ma, se la tua libreria esegue l'acquisto, probabilmente ti ritroverai con una classe Publisher, nella tua classe di libri avrai quindi bisogno di un riferimento all'editore classe.

    
risposta data 10.03.2015 - 09:55
fonte