Consentire a un oggetto di essere configurato da un'altra classe

2

Attualmente sto pianificando un server di monitoraggio per un sistema distribuito. In un file (o forse un database, un giorno) salverò tutti i server e i parametri che voglio monitorare. All'avvio del sistema di monitoraggio, analizzo il file di configurazione e memorizzo il contenuto in una classe di configurazione (vedere il codice sorgente di seguito). Per essere indipendente dal tipo di archiviazione (file, database, ...) utilizzo l'interfaccia IConfigurationHandler (ok, ammetto che il nome non si adatta davvero :)), le cui implementazioni sono responsabili della lettura / scrittura del file soddisfare.

Ho considerato il seguente disegno:

public class Configuration
{
    private IConfigurationHandler _configHandler;

    public Configuration(IConfigurationHandler configHandler)
    {
        this._configHandler = configHandler;
        this.Load();
    }

    public void Load() 
    {
        this._configHandler.LoadConfigurationInto(this);
    }
}


public class XmlDocumentConfigurationHandler : IConfigurationHandler
{
    public void LoadConfigurationInto(Configuration configuration)
    {
        configuration.X = "...";
        configuration.Y = "...";
        configuration.Z = "...";
    }
}

Se volessi usare la classe Configuration, l'unica cosa che dovrei fare è aggiungere una dipendenza al costruttore (supponendo che io stia usando un DI-Framework).

public class ConfigurationConsumer
{
    public ConfigurationConsumer(Configuration configuration)
    {
        // Do something with the configuration
    }
}

Ma in qualche modo questo codice mi dà una brutta sensazione. Che cosa ne pensate a riguardo? È "buono" se un oggetto si configura da solo con un'altra classe?
Anche se "sembra" sbagliato, non riesco a pensare a un caso particolare in cui questo design ha un impatto negativo.

Un altro approccio sarebbe chiamare IConfigurationHandler direttamente dalla classe che richiede la configurazione, come segue:

public class Configuration
{
    public Configuration() { }
}


public class XmlDocumentConfigurationHandler : IConfigurationHandler
{
    public Configuration GetConfiguration()
    {
        Configuration configuration = new Configuration();
        configuration.X = "...";
        configuration.Y = "...";
        configuration.Z = "...";
    }
}


public class ConfigurationConsumer
{
    public ConfigurationConsumer(IConfigurationHandler configurationHandler)
    {
        var configuration = configurationHandler.GetConfiguration();
        // Do something with the configuration
    }
}

Il problema con questo approccio è che avrei bisogno di accettare un IConfigurationHandler , anche se l'unica cosa di cui ho bisogno è un oggetto Configuration .

Ecco uno schema (molto) approssimativo della mia architettura:

Edeccounesempioperilcontenutodelfilediconfigurazione:

<servers><serverid="1">
        <monitored_values>
            <monitored_value name="CpuUsage"/>
            <monitored_value name="..."/>
        </monitored_values>
        <!--some more configuration-->
    </server>

    <server id="...">
        <!--some more configuration-->
    </server>

    <server id="n">
        <!--some more configuration-->
    </server>
</servers>

Il vero file di configurazione quindi, tra gli altri, contiene un elenco con tutti i server, che a loro volta contengono un elenco con i loro parametri monitorati.

    
posta timnot90 14.10.2016 - 15:09
fonte

2 risposte

1

Penso che ti dia una "cattiva sensazione" perché rompe l'incapsulamento . In questo modo:

configuration.X = "...";
configuration.Y = "...";
configuration.Z = "...";

ciò che dovrebbe essere lo stato interno di Configuration è esposto pubblicamente.

Finora ho capito, qualcosa del genere dovrebbe essere sufficiente?

public class Configuration
{
    private X x;
    private Y y;
    private Z z;

    public Configuration(X x, Y y, Z z)
    {
        this.x = x;
        this.y = y;
        this.z = z;
    }
}
    
risposta data 14.10.2016 - 16:02
fonte
0

Is it "good" if an object let's configure itself by another class?

Sì. È fatto tutto il tempo.

Come dice @spotted, è incapsulamento. Ma voglio aggiungere che questo incapsulamento dovrebbe essere realizzato attraverso il concetto di "fabbrica".

Crea una classe factory che ha-un oggetto di configurazione. Il codice cliente comunica alla fabbrica solo l'oggetto da creare. La fabbrica può essere complessa se necessario per creare secondo la "specifica" di configurazione. Il concetto di fabbrica ha lo scopo di ridimensionare e indirizzare la struttura dell'oggetto: "metodo di fabbrica", "fabbrica" e "fabbrica astratta" riflettono questo ridimensionamento. "Builder" è un modello complementare che affronta la complessità della creazione di oggetti.

    
risposta data 19.10.2016 - 17:09
fonte

Leggi altre domande sui tag