Assegnare un nome a una classe che elabora gli ordini [chiuso]

Question

Assegnare un nome a una classe che elabora gli ordini [chiuso]

#1 da (4 voti)

2

Sono nel mezzo del refactoring di un progetto. Di recente ho letto Clean Code e desidero prestare attenzione ad alcuni dei consigli al suo interno, con particolare attenzione al Single Responsibility Principle (SRP).

Attualmente esiste una classe denominata OrderProcessor nel contesto di un sistema di ordini di prodotti di produzione.

Questa classe attualmente esegue la seguente routine ogni n minuti:

controlla il database per gli ordini appena inviati + non elaborati (tramite una classe Data Layer già, per favore!)
raccogliere tutti i dettagli degli ordini
contrassegnali come in-process
scorrere ogni a:
- esegue alcuni controlli di integrità
- chiama un servizio web su un sistema di terze parti per effettuare l'ordine
- controlla lo stato del valore di ritorno del servizio web per successo / fallimento
- invia un'email a qualcuno se il servizio web restituisce un errore
accedere costantemente a un file di testo su ogni operazione o possibile punto di errore

Ho iniziato suddividendo questa lezione in nuove classi come:

OrderService - nome scadente. Questo è quello che si sveglia ogni n minuti
OrderGatherer - chiama il DL per ottenere l'ordine dal database
OrderIterator (? sembra troppo forzato o mal chiamato) -
OrderPlacer - chiama il servizio web per effettuare l'ordine
EmailSender
Logger

I stanno lottando per trovare buoni nomi per ogni classe, e implementando SRP in modo ragionevole.

In che modo questa classe può essere separata in una nuova classe con responsabilità discrete?

refactoring naming class-design

posta p.campbell 29.09.2012 - 20:39

fonte

1 risposta

Leggi altre domande sui tag refactoring naming class-design

Licenza per il progetto Opensource [duplicato] Architettura per i dati dei social graph con un time frame associato?

score 4 · Answer 1

Come regola generale ho 1 classe per ogni oggetto (spesso collegato a una tabella DB) o processo.

A volte può essere difficile definire tutte le classi prima del tempo, quindi tendo a creare alcune classi bare-bones e iniziare a scrivere una versione approssimativa (spesso procedurale) di ciò che voglio fare. Questo processo di vedere realmente come si blocca il tuo codice mi permette di iniziare a individuare pattern e link. Posso quindi modificare rapidamente le mie classi di scheletri rapidamente, creando efficacemente il design e il flusso di lavoro in modo iterativo fino a quando non arrivo a qualcosa di cui sono felice.

Vorrei iniziare con:

OrderChecker - classe del thread che controlla ogni n minuti
OrderProcessor - ottiene un nuovo ordine dal DB (usando DAL) e ne elabora ciascuno - questo è il posto dove si svolgerà la maggior parte del lavoro, incluse le chiamate a EmailSender e Logger.
OrderSender - Invia email in base allo stato dell'ordine (discendente dalla classe mittente email generica)
OrderLogger - registra le informazioni in base ai risultati dell'elaborazione dell'ordine (discendente dalla classe generica del logger?)

Trovo che la chiave sia mantenere tutto "sciolto" (spesso veloce e sporco) finché non sei soddisfatto del tuo progetto e hai tenuto conto di tutti i problemi / requisiti prevedibili.