modello di progettazione per la descrizione di una sottoparte variabile di un file di configurazione

Question

modello di progettazione per la descrizione di una sottoparte variabile di un file di configurazione

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

2

Supponiamo di avere un file XML config come il seguente:

<myapp>
    <settings/>

    <output>

        <mailto>mail service configuration parameters</mailto>
                           OR            
        <smsto>sms service configuration parameters</smsto>        

    <output>

Mentre il nodo delle impostazioni avrà sempre la stessa struttura, il nodo di output potrebbe avere strutture diverse, a seconda che si tratti di una posta o di un output SMS.

Le classi Java saranno:

class MyAppConfig {

    String settingXXX;

    {what type?} output;

}

Ovviamente avrò un class MailTo {} e un class SmsTo {} .

Poiché l'output può essere un MailTo o un SmsTo oggetto, può essere:

un tipo di oggetto, poiché MailTo e SmsTo non hanno alcuna superclasse in Comune.
un'interfaccia Output , che a sua volta è implementata da MailTo e SmsTo. Poiché MailTo e SmsTo non hanno nulla in comune, l'interfaccia Output sarà vuota e "collasserà" su un'interfaccia marker.

Penso che, data questa situazione, questa sia l'unica implementazione possibile.
Il codice cliente verrà convertito in Object o Output in MailTo o SmsTo , che deve essere gestito in modo diverso.

Tuttavia, sono perplesso perché i modelli di progettazione (libro GoF) sembrano non considerare questo tipo di situazioni.
Qual è lo schema del "mondo reale" che applicheresti in questo caso?

java design-patterns idioms

posta AgostinoX 23.01.2012 - 18:51

fonte

3 risposte

Leggi altre domande sui tag java design-patterns idioms

SSRS ha sostituito Crystal Reports come nuovo standard per lo strumento di reporting di Visual Studio? C'è qualcosa come Diaspora scritto in PHP?

score 3 · Answer 1

Penso che la direzione dovrebbe essere un Pattern creativo , pagina 33 nel libro GoF presenta una tabella di aiuto per la costruzione di un design variabile. Dalla pagina:

Design Pattern         Aspect(s) That Can Vary
--------------         -----------------------
Abstract Factory (68)  families of product objects
Builder (75)           how a composite object gets created
Factory Method (83)    subclass of object that is instantiated
Prototype (91)         class of object that is instantiated

Da questa tabella, Prototype sembra adattarsi al meglio che sostanzialmente ti consente di

specify the kinds of objects to create using a prototypical instance, and create new objects by copying this prototype.

EDIT: belle informazioni dettagliate qui: link

Per favore, approfondisci il tuo problema se questo design non è sufficiente ...

score 1 · Answer 2

La tua domanda sembra un esempio da manuale dei vantaggi del polimorfismo, non penso che ci sia un modello chiamato per implementare questa funzionalità in quanto questo è un principio OO piuttosto basilare. La tua idea di creare un'interfaccia per entrambe le classi da implementare è l'idea migliore che consente di chiamare myInterface.doStuff per gestire entrambi i tipi di comunicazione e consentire l'aggiunta di ulteriori se necessario.

score 1 · Answer 3

Sono d'accordo con Ryathal che si tratta di polimorfismo di base e quindi non troverai un modello di design per questo. Sebbene sia possibile utilizzare qualcosa come un modello factory per creare la classe appropriata in base alle impostazioni di configurazione. Non sono d'accordo sul fatto che l'email e il servizio sms non abbiano nulla in comune. La classe base potrebbe essere qualcosa come "servizio di comunicazione" e questi servizi avrebbero sempre una posizione per il servizio (es: ubicazione del server smtp o url per servizio web o API) e alcune credenziali per l'autenticazione. La classe "email" e la classe "sms" erediterebbero dalla classe "servizio di comunicazione". Il metodo per inviare un messaggio sarebbe diverso nelle classi derivate.