Quando mantenere il comportamento all'interno dell'oggetto dominio vs all'interno di un oggetto servizio?

Question

Quando mantenere il comportamento all'interno dell'oggetto dominio vs all'interno di un oggetto servizio?

#1 da (1 voti)
#2 da (1 voti)

1

Finora ho messo le funzioni in oggetti, se quelle funzioni funzionano esclusivamente sulle variabili / stati dell'oggetto. Fondamentalmente sto seguendo un approccio al modello di dominio non anemico / ricco.

Tuttavia, diventa più difficile, se il comportamento è solo parzialmente basato sullo stato dell'oggetto. In questi casi vedo due opzioni:

Approccio non anemico: passa le informazioni aggiuntive come argomento all'oggetto

obj.doSomeCalculationsAndSetAValue(someAdditionalInformation)

Approccio anemico: crea un "oggetto servizio" che vive sopra l'oggetto dominio. L'oggetto servizio ha tutte le informazioni di cui ha bisogno, vale a dire l'oggetto dominio stesso e le "informazioni aggiuntive".

class ServiceObject{
    AdditionalInformationWrapper additionalInfos;

    //uses additionalInfos and gets information from domain object to do calculations;
    //use obj-setter to set the calculated value
    public void doSomeCalculationsAndSetAValue(DomainObject obj);
}

Quando dovrei mantenere la logica all'interno dell'oggetto dominio e quando all'interno dell'oggetto servizio?
C'è un'altra alternativa?

design java design-principles

posta teddyD 27.12.2017 - 14:12

fonte

2 risposte

Leggi altre domande sui tag design java design-principles

Qual è il modo migliore per archiviare i thread dei messaggi? php reference architecture / design / folder structure

score 1 · Answer 1

Penso che potresti scrivere il codice in un modo altrettanto elegante.

Faccio la scelta tra ADM e OOP a seconda di come utilizzo l'oggetto.

Per le app di lunga durata in cui verranno eseguite più operazioni sullo stesso oggetto ha senso conservare tale istanza in memoria e chiamare Object.DoWhatever (), Object.NowDoThis () ecc.

Tuttavia, quando l'oggetto è temporaneo, ovvero istanziato in una chiamata Web, viene eseguita un'unica operazione e quindi eliminata. Ha più senso mantenere il servizio in memoria e riutilizzarlo per più oggetti.

score 1 · Answer 2

La prima cosa a cui pensare è chi è responsabile del fare? La risposta a questa domanda si riduce in realtà alla ragionevolezza che qualcun altro del team si aspetti che il metodo appartenga a parte dell'oggetto dominio. Se non puoi fare una buona argomentazione per far sì che il metodo appartenga a un oggetto dominio, allora potresti guardare un oggetto servizio.

Tuttavia, qualcosa che potrebbe valere la pena di considerare è se il SetAValue dovrebbe essere parte dell'oggetto servizio ... L'impostazione dei valori è responsabilità dell'oggetto dominio, facendo i calcoli può benissimo essere parte dell'oggetto di servizio. Inoltre, puoi considerare un po 'di riorganizzazione:

class ServiceObject {
    public CalculationResult doSomeCalculation(allArgsNeeded);
}

e invocandolo in questo modo:

obj.processCalculation(serviceObject, argsNeeded);

all'interno del tuo oggetto dominio funzionerebbe in questo modo:

public void processCalculation(serviceObject, argsNeeded) {
    result = serviceObject.doSomeCalculation(allArgsNeeded);

    // do something with the result
    setAValue = fromResult;
}

Separare il calcolo e l'impostazione può aiutare a mantenere un oggetto dominio ricco pur continuando a supportare oggetti di servizio. Fornisci tutti gli argomenti necessari al metodo invece di nascondere un argomento come attributo di classe per il tuo oggetto servizio.