Sono nomi come OrderCreation e UserRegistration nomi adatti per la logica aziendale / classi di dominio

Question

Sono nomi come OrderCreation e UserRegistration nomi adatti per la logica aziendale / classi di dominio

#1 da (2 voti)
#2 da (1 voti)
#3 da (1 voti)
#4 da (0 voti)

2

Ci siamo spostati su un modello SRP in più e abbiamo scoperto che i nomi delle classi erano difficili. Precedentemente avevamo una classe Order simile a questa:

public class Order
{
    public void Create()
    {
    }

    public void Dispatch()
    {
    }

    public void Cancel()
    {
    }
}

Ora stiamo suddividendo questi 3 metodi in classi separate in modo che assomiglino a ciò che ho descritto di seguito:

public class OrderCreation
{
    public void CreateOrder(OrderDTO order)
    {
    }
}

public class OrderDispatch
{
    public void DispatchOrder(OrderDTO order)
    {
    }
}

public class OrderCancellation
{
    public void CancelOrder(OrderDTO order)
    {
    }
}

La denominazione di queste classi e dei metodi pubblici è ragionevole? Seguono quale dovrebbe essere la denominazione in una business logic o in una classe di dominio? (Ricorda che stiamo seguendo SRP)

UPDATE: Le classi sono state modificate in modo da non essere anemiche. Sulla base del feedback riteniamo che questa sia una soluzione migliore.

public class OrderCreation
{
    public string CustomerName {get;set;}
    public string CustomerEmail {get;set;}
    public string Address {get;set;}

    public void CreateOrder()
    {
    }
}

public class OrderDispatch
{
    public string OrderNumber {get;set;}
    public string Courier {get;set;}

    public void DispatchOrder()
    {
    }
}

public class OrderCancellation
{
    public string OrderNumber {get;set;}

    public void CancelOrder()
    {
    }
}

design c# java design-patterns single-responsibility

posta user1786107 22.03.2016 - 23:53

fonte

4 risposte

Leggi altre domande sui tag design c# java design-patterns single-responsibility

Si tratta di una monade in Java? (parte 2) Perché Google Chrome utilizza SQLite se l'utilizzo dei thread risulta in un accesso parallelo?

score 2 · Answer 1

Se lo spingi ancora un po 'oltre, e fai questo:

public interface ICommand
{
    void Invoke();
}

public class OrderCreation : ICommand
{
    private readonly OrderDTO _order;

    public OrderCreation(OrderDTO order)
    {
        _order = order;
    }

    public void Invoke()
    {
        // do the logic
    }
}

public class OrderDispatch : ICommand
{
    private readonly OrderDTO _order;

    public OrderDispatch(OrderDTO order)
    {
        _order = order;
    }

    public void Invoke()
    {
        // do the logic
    }
}

public class OrderCancellation : ICommand
{
    private readonly OrderDTO _order;

    public OrderCancellation(OrderDTO order)
    {
        _order = order;
    }

    public void Invoke()
    {
        // do the logic
    }
}

Finisci con schema di comando . Questo ha grandi vantaggi:

L'esecuzione è separata dall'invocazione. Ciò consente ad altro codice di fare qualcosa di interessante con ogni comando eseguito.
Consente di utilizzare l'ereditarietà per implementare un comportamento comune per l'invocazione. Ad esempio, la transazione del database può essere avviata e impegnata nella classe base e la classe figlio utilizza solo la connessione al database.
Consente la composizione dei comandi per formare comandi più complessi.

Il principale svantaggio è l'aumento della complessità. Questo aumento è davvero fattibile solo se ogni comando ha una complessità elevata in sé. Se ogni metodo è costituito da poche righe di codice, la creazione di un intero comando attorno ad esso può sembrare non necessario.

score 1 · Answer 2

Questi assomigliano a una banda di 4 oggetti Command (un po '). Non mi piacciono ma se questo è ciò che vuoi, allora vai per questo - e questi nomi hanno perfettamente senso

Dal mio punto di vista ora ho il mio codice che sa tutto sugli ordini distribuiti troppo.

Sarei astratto solo se avessi davvero bisogno di un comportamento comune tra "Comando" - come essere in grado di persistere, condurli, eseguirli indirettamente dagli script ecc. Ma anche in quel caso avrei una vera classe sotto. Forse sarebbe una classe statica che ha Order.Create, Order.Delete ecc.

score 1 · Answer 3

Nella tua riscrittura, cosa fa OrderDTO ? Se è effettivamente solo un "oggetto valore" anemico, come implica il nome, ciò che hai fatto è separare la logica dai dati, passando da OOP a programmazione procedurale antiquata. IMO una brutta cosa. Succede quando SRP è sovrautilizzato e diventa ZRP, a.k.a. Principio di responsabilità zero.

OTOH, se OrderDTO mantiene un sacco di logica, in primo luogo, dargli un nome migliore per riflettere questo. E sono d'accordo che possibilmente il tuo oggetto Order originale ha fatto "troppo" ed è un candidato per refactoring usando SRP.

score 0 · Answer 4

Di per sé, new OrderCancellation().CancelOrder(OrderDTO order); non mi sembra un gran miglioramento.

Penso, tuttavia, che sia appropriato separare le preoccupazioni tra un "Sistema di ordinazione" e il "Modulo di invio ordine". La responsabilità del sistema di ordini è di accettare o rifiutare ordini (e in caso contrario gestire gli ordini, come assegnare un ID ordine), mentre il modulo d'ordine trasmette il contenuto della richiesta d'ordine. Questo tipo di passaggio va alla modifica che stai mostrando per quanto riguarda l'introduzione del OrderDTO come separato (responsabilità / classe) dalla creazione e cancellazione. (Un ordine può essere un'entità complessa con numerosi elementi pubblicitari, informazioni di pagamento, ecc. Quindi è ragionevole che un modulo d'ordine sia separato da un sistema di ordinazione.)

Considero che un sistema di ordini che ha sia l'accettazione che l'annullamento è una nozione ragionevole di Responsabilità Unica (vale a dire la gestione degli ordini o, in un certo senso, la coda degli ordini); il che significa che accettare e cancellare non dovrebbe essere separato in classi diverse a causa di SRP. (Non separeresti i metodi di aggiunta e rimozione di una raccolta in classi separate (non funzionerebbe), gestire la raccolta è solo una responsabilità.)

Tuttavia, se accetti le cancellazioni come eventi registrati e / o richieste di invio che hanno una durata specifica, ciò che stai mostrando potrebbe avere un senso poiché ogni evento (ordine, cancellazione) è una richiesta di un tipo logico diverso. Considererei questi elementi come richieste, non azioni garantite, ad esempio denominate come OrderCancellationRequest .