Perché a volte separiamo il comportamento dalle classi in Java

Question

È una domanda piuttosto semplice, ma io sono nuovo nella progettazione Java per scusarmi. :)

Desidero sapere in quali scenari è necessario separare il comportamento della classe dalla classe stessa.

per es.

Se ho un Dipendente di classe, avrò alcuni dati come - nome, età, ecc. Anche questa classe avrà un comportamento come doWork() ecc. Ora in quale scenario possiamo avere dati e il comportamento all'interno una volta sola classe (Dipendente) e in quale scenario è necessario avere 2 classi diverse per Dati dipendente (EmployeeDTO) e comportamento (EmployeeService)

Domanda molto soggettiva ma sto cercando alcuni input su un progetto di una piccola applicazione in cui io sto prendendo i dati da un file di testo. Dovrei inserire i dati e il comportamento in classi diverse o uguali? Quale sarà la tua ragione per giustificare questa decisione?

PS: Tutti i link a informazioni su questo sarà anche molto utile :)

Thankyou

Answer 1

Fai la cosa più semplice possibile. Puoi sempre rendere il tuo codice più generalizzato in un secondo momento e ci sono buone probabilità che non dovrai nemmeno farlo.

Applicare il principio YAGNI ogni volta che è necessario prendere una decisione. Extreme Programming wiki è anche una bella lettura.

Metti tutto in una classe al momento. Quando vedi che il tuo Dipendente si sta ingrassando, puoi eseguire alcuni refactoring, ad esempio, move method in un'altra classe. In linguaggi tipizzati staticamente come Java è facilissimo perché il compilatore aiuta molto e il supporto IDE è ottimo.

La lettura dal file, ad esempio, si presenta come un ovvio candidato da estrarre in una classe di caricatore separata. D'altra parte, se hai un formato molto comune come input come XML o JSON, potresti semplicemente creare il metodo statico List<Employee> Employee.loadFromFile(string fileName) e implementare la logica di lettura in un paio di righe di codice. È abbastanza buono in questo momento: semplice, breve e funziona bene.

maggio Real Ultimate Programming Power essere con voi!

Answer 2

Buone sostenitori progettazione orientata agli oggetti che ogni classe obbedire alla Single Responsibility Principle. Che non posso riassumere più eloquente di quanto la voce di Wikipedia:

Martin definisce una responsabilità come un motivo per cambiare, e conclude che una classe o modulo devono avere una, e una sola, motivo per il cambiamento . Ad esempio, prendi in considerazione un modulo che compila e stampa un rapporto . Tale modulo può essere modificato per due motivi. Innanzitutto, il contenuto del report può cambiare. In secondo luogo, il formato del rapporto può cambiare . Queste due cose cambiano per cause molto diverse; uno sostanziale e un cosmetico. Il principio di responsabilità singola afferma che questi due aspetti del problema sono in realtà due distinte responsabilità di e devono pertanto essere in classi separate o moduli . Sarebbe un cattivo progetto accoppiare due cose che cambiano per motivi diversi in momenti diversi.

Se ci pensate, potete bloccare tutto il vostro codice Java in un file di classe, ma non lo fate. Perché? Perché vuoi essere in grado di cambiare, mantenerlo, adattarlo e testarlo. Questo principio dice che invece di dividere il tuo codice arbitrariamente in moduli diversi, dovresti prendere il fatto che le cose dovrebbero essere suddivise dalle loro responsabilità logiche. Questo generalmente significa più, piccoli moduli che sappiamo essere più facili da cambiare, mantenere, adattare e testare.

Personalmente, consiglierei di inserire il codice in classi discrete più piccole e combinarle in un secondo momento se ciò si rivela irragionevole - questo diventerà ovvio per voi. È molto più facile combinare codice liberamente accoppiato in futuro che ridurre il codice strettamente accoppiato.

Answer 3

Mantenendo le logiche di business fuori dal pojo, rendendolo un puro oggetto di trasferimento, si ha il vantaggio di un accoppiamento lento qualora un giorno ti trovassi nella situazione per la necessità di passare da Spring framework a EJB JavaBeans.

Inserendo dati e business logic, diventa un oggetto dominio. La forma più semplice di utilizzo di bean gestito promossa in JSF2 utilizza il modello di dominio in base al quale l'azione viene combinata con i dati del modulo.

Se si sceglie il primo modello, è possibile separare in modo pulito le preoccupazioni per la progettazione dell'ereditarietà e del polimorfismo per gli oggetti dati, senza essere disturbato se i comportamenti definiti hanno senso e viceversa.

Answer 4

Si utilizza un DTO (come suggerisce l'acronimo) quando si desidera spostare i dati utilizzando il modo più leggero possibile, ad esempio tramite il cavo per un servizio.

Answer 5

Per la cronaca

suo classico ricco dominio oggetto vs oggetto di dominio anemico.

In generale, se si dispone di un oggetto UI o di un oggetto libreria (ad esempio la classe Date o la classe TextButton), e potrebbe essere un altro tipo di oggetti, potrebbe essere possibile avvolgere tutto in una singola classe anziché si affida a classi diverse solo per merce per avere tutti gli attributi e i metodi nella stessa classe.

Tuttavia, per un oggetto Business classico (BO) è diverso. Anche se si desidera un oggetto dominio ricco, escludendo alcuni altri problemi che non voglio menzionare a questo punto, è il fatto che il livello Business Service (BS) funge da "programma di dieta brucia grassi" e trasforma ogni ricco BO in un BO anemico.

Rich BO -------> BS ----------> Anemic BO.