Passa oggetti o valori come parametri alle funzioni

Question

Passa oggetti o valori come parametri alle funzioni

#1 da (4 voti)

4

Sto lavorando con lo standard JEE. Ho i seguenti livelli: JPA (Eclipse Link), Data Access, Business Logic e JSF (Primefaces). Primefaces utilizza pattern di progettazione MVC, quindi il livello di presentazione contiene ManagedBeans (controller).

Quando creo un oggetto da una richiesta utente, devo contromettere l'oggetto nel ManagedBean e passarlo come l'intero oggetto alla logica, oppure devo passare gli attributi di quell'oggetto alla logica:

public void businessLogicMethod(String clientAttributeA, int clientAttributeB...)

o

public void businessLogicMethod(Client client)

Non riesco davvero a decidermi. Funzionalmente, entrambe le opzioni fanno lo stesso ... Ma ci sono vantaggi di qualità del software da uno all'altro? C'è qualche motivo per progettare il livello per costruirlo nel controller o nel modello? C'è qualche altra ragione?

Uno dei vantaggi che vedo in quello superiore è che i servizi del diagramma di distribuzione avranno i parametri dichiarati nelle interfacce di servizio, quindi ci sono molte più informazioni nel diagramma.

code-quality java java-ee jsf

posta AFP_555 07.10.2016 - 05:21

fonte

1 risposta

Leggi altre domande sui tag code-quality java java-ee jsf

Sincronizzazione bidirezionale di 2 API diverse Costruire calcoli di logica aziendale che richiedono dati da oggetti padre

score 4 · Accepted Answer

But are there any software quality advantages from one to the other?

La programmazione è complessa e quindi cerchiamo di fare cose che lo rendono più gestibile e manutenibile.

Uno strumento che abbiamo per questo è l'astrazione. Se possiamo astrarre i dettagli rilevanti e nascondere l'implementazione di quei dettagli che ci danno un vantaggio, perché possiamo prendere in considerazione un numero inferiore di regole e problemi, e le cose funzionano.

Ogni volta che puoi prendere diversi concetti e raggrupparli insieme in un'unica astrazione, ne stai trarre vantaggio.

Quindi, prendere string, int e impacchettare quella classe come un cliente è un'astrazione che aiuta i clienti (non è un gioco di parole), spesso noi, a scrivere software migliori con meno preoccupazioni e opportunità di errore.

Un problema con due parametri separati è che qualcuno potrebbe confondere la stringa clientA con clientB int. In bundle, ciò non può accadere.

Un altro problema con il codice che stai mostrando è che i tipi di dati primitivi non offrono un controllo di tipo di valore elevato, quindi qualcuno potrebbe confondere un altro valore di stringa con la stringa per clientA. Raggruppato come in una nuova astrazione (una nuova classe, un suo tipo) che non accadrà.

Il concetto di fornire un'astrazione di qualità meno incline agli errori è il cuore della scrittura di codice gestibile.

One of the advantages I see in the upper one is that the deployment diagram's services will have the parameters declared in the service interfaces, so there is much more information in the diagram.

Questo è in realtà contrario a ciò che vogliamo. Vogliamo nascondere i dettagli di implementazione in modo che le modifiche future perturbino la superficie di codice più piccola possibile.

Is there any layer design reason to construct it in the controller or the model?

Dovresti costruire le tue astrazioni (qui di Client ) al più presto possibile, quando hai i vari attributi del tutto. Dopodiché, un'astrazione (singola) è la migliore confezione di quegli attributi.