Pattern software per la combinazione di proprietà [chiuso]

Question

Pattern software per la combinazione di proprietà [chiuso]

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

1

Ho due classi che leggono file distinti. A titolo di esempio, due classi, sourceA o Client, sourceB o Resources:

public class Client()
{
    public string ClientName {get; set;}
    public int ClientNumber {get; set;}
    public string Address {get; set;}
    //...
}

public class Resources()
{
    public int ClientNumber {get; set;}
    public decimal Resources {get; set;}
    //...
}

Diciamo che ho bisogno di unire le classi booth in una nuova, ma ho solo bisogno di alcuni campi dalla classe Client e Resources . C'è qualche modello di software motivato da qualcosa di simile, per comporre una classe come ClientReport ?

La nuova classe dovrebbe essere qualcosa del tipo:

public class ClientReport()
{
    public string ClientName {get; set;}
    public int ClientNumber {get; set;}
    public string Address {get; set;}
    public decimal Resources {get; set;}

    public int CalculateRating()
    {
        //...
    }
}

Queste nuove classi avranno alcune proprietà di Client e Resources , e copiare codice da loro per creare ClientReport sembra essere una ripetizione, e penso che dovrebbe essere una via per comporre questa classe e utilizza solo le proprietà necessarie da Client e Resources .

design-patterns

posta cap7 05.05.2015 - 18:02

fonte

3 risposte

1

La definizione della classe del tuo cliente non dovrebbe essere legata al modo in cui acquisisci i dati per costruire la classe. Dovresti rivedere i requisiti di business della tua classe cliente e definirla in base solo a quella.

Da quanto visualizzato finora, sembra che siano necessarie due classi di elaborazione file a cui viene fornita una raccolta di oggetti client su cui lavorare, indipendentemente dalla loro creazione o aggiornamento.

La cosa fondamentale è che la classe client deve essere indipendente dall'elaborazione necessaria per i file. Domani potrebbe essere necessario leggere da un database, un servizio web o altro, ma questo non cambia la definizione di un cliente nel tuo dominio aziendale.

risposta data 05.05.2015 - 18:39

fonte

1

Se comprendo la tua domanda, Facade Pattern soddisfa le tue esigenze:

Intent:

Provide a unified interface to a set of interfaces in a subsystem. Facade defines a higher-level interface that makes the subsystem easier to use.

Wrap a complicated subsystem with a simpler interface.

La tua facciata, la classe ClientReport , ha le classi SourceA e SourceB per composizione. L'interfaccia unificata più semplice fornita da ClientReport delega ai metodi appropriati di SourceA e SourceB ; tuttavia, il client gestisce solo l'interfaccia ClientReport .

Il link sopra ha questo elenco di controllo per l'uso del pattern Facade:

Identify a simpler, unified interface for the subsystem or component.

Design a 'wrapper' class that encapsulates the subsystem.

The facade/wrapper captures the complexity and collaborations of the component, and delegates to the appropriate methods.

The client uses (is coupled to) the Facade only.

Consider whether additional Facades would add value.

risposta data 06.05.2015 - 02:06

fonte

Leggi altre domande sui tag design-patterns

Passare il contesto attorno ai nodi AST Quanto è grave il fatto che il mio index.php in un'applicazione Zend Framework MVC misuri definizioni ed effetti collaterali?

score 2 · Accepted Answer

Ecco (almeno) due oggetti client e report coinvolti. Da quanto scrivi finora, un rapporto sembra essere composto di client e ressources :

public class ClientReport()
{
    public Client client;
    public decimal ressources;

    public getClientName(){ return this.client.getName(); }
    // ...
    public setRessources(decimal ressources){ this.ressources=ressources; }

    public ClientReport(Client client){
        this.client=client;
    }
}

Invece di copiare i campi di Client dovresti avvolgere Client in ClientReport (passarlo tramite costruttore) e delegare chiamate in arrivo di il report per Client stesso (vedi getClientName () ). Quindi sei libero di nascondere / mostrare (= incapsulare ), qualunque parte del Client desideri. Ha senso nascondere la creazione di ClientReport dietro a Builder . Il Builder legge per primo SourceA per generare List<Clients> . Dopodiché legge SourceB per mappare le risorse al rispettivo client. Lo stesso Builder ha solo un metodo getClientReports() , che fa tutto ciò in modo trasparente al consumatore.

Dovresti pulire ulteriormente la progettazione dell'oggetto. Forse ha senso nel tuo dominio avere un Address -object, che è avvolto dall'oggetto Client .