Dovremmo usare l'oggetto dati (o l'oggetto di trasferimento dati) per condividere i dati tra queste tre classi?

Question

Dovremmo usare l'oggetto dati (o l'oggetto di trasferimento dati) per condividere i dati tra queste tre classi?

#1 da (3 voti)

2

Ho trovato un articolo di Martin Fowler che mi ha fatto dubitare delle mie scelte progettuali, in particolare degli oggetti dati. Martin Fowler ha scritto un articolo su ciò che pensa sia un odore di codice .

In questo articolo, dice:

The best smells are something that's easy to spot and most of time lead you to really interesting problems. Data classes (classes with all data and no behavior) are good examples of this. You look at them and ask yourself what behavior should be in this class. Then you start refactoring to move that behavior in there. Often simple questions and initial refactorings can be the vital step in turning anemic objects into something that really has class.

Ora, per il mio uso personale caso di classi di dati / oggetti / DTO / qualunque. : -)

Sto scrivendo una serie di classi che trasferiscono crediti dalla simulazione della nostra azienda alla simulazione di un destinatario. Questo processo ha tre fasi:

Convalida: in questa fase, i dati sono convalidati - abbiamo già trasferito crediti sull'account di questa persona? Abbiamo già gestito questo articolo? Possiamo riprovare o abbiamo raggiunto la soglia della "modalità manuale"?
Processo: in questa fase, facciamo il vero lavoro di spostare i crediti da un account all'altro. Utilizziamo gli oggetti recuperati nella fase di convalida, per ridurre il numero di query nel database e anche per migliorare le prestazioni della nostra applicazione.
Post-process: a questo punto, controlliamo i dati e se i dati devono essere corretti automaticamente (IE l'utente ha inserito informazioni errate e sappiamo come correggerlo automaticamente), lo contrassegniamo per la correzione automatica.

Ora, gli articoli 2 e 3 stanno utilizzando molti dati che vengono recuperati o inizializzati nella fase 1: il gestore eventi, l'ordine e gli oggetti di pagamento e transazione e così via. Quello che facciamo è il seguente:

L'oggetto di validazione memorizza tutti i suoi dati recuperati che sono utili al resto del processo in un data transfer object ( DTO ). Questo oggetto ha solo setter e getter.
Il resto delle classi (la classe process e la classe post-process ) accettano il DTO come argomento del costruttore e eseguono l'elaborazione, la gestione degli eventi e la manipolazione dei dati su tali oggetti. Alla fine, quegli oggetti sono persistenti nel database.

L'oggetto dati (o l'oggetto di trasferimento dati) non è raccomandato qui? Dovremmo usare un altro modo per condividere i dati tra queste tre classi?

object-oriented design design-patterns php

posta Parham Doustdar 17.11.2014 - 12:53

fonte

1 risposta

Leggi altre domande sui tag object-oriented design design-patterns php

Redis strategia per la dipendenza dalla cache Unisci ordinamento e O (n log n) mistero

score 3 · Accepted Answer

Should we use another way for sharing data between these three classes?

No, non è questo il punto su cui Fowler sta parlando. L'utilizzo di un DTO è probabilmente soddisfacente ( lo consiglia Fowler stesso , in particolare in uno scenario remoto). Il punto è che durante il refactoring, tale DTO potrebbe diventare un posto migliore per operazioni che funzionano esclusivamente sui dati memorizzati all'interno del DTO (che in realtà non significa mettere l'intera validazione, elaborazione e post- codice di elaborazione in là).

I candidati sono in genere operazioni che possono essere riutilizzate in più di una delle fasi sopra descritte. Un altro indicatore è quando inizi a implementare qualcosa come una classe FooDTOManager per una classe specifica FooDTO , invece di implementare le operazioni direttamente in FooDTO . Quello che dovresti considerare è il nome che dai al DTO - idealmente esprimerà una sorta di astrazione e qualche tipo di responsabilità. Utilizzare questa responsabilità come linea guida per decidere quali operazioni inserire nel DTO e quali no.

Tuttavia, se l'unica responsabilità degli oggetti DTO (al momento) è trasferire alcuni dati dal passaggio x al passaggio y, quindi lasciarlo così com'è. Più tardi, quando il tuo programma si evolve, potresti trovare operazioni che possono essere adatte come operazioni per questo DTO - se al momento non ce ne sono, va bene, non iniziare a cercare una soluzione diversa.