Design Pattern: acquisizione di una raccolta di oggetti da origini diverse

1

Ho una classe Shop che contiene una raccolta di oggetti Item . Puoi creare un negozio in due modi diversi:

  1. Crea un negozio pieno di dati di test (a scopo di debug);
  2. Crea un negozio leggendo i dati dal file

Devo anche scrivere di nuovo al negozio.

C'è qualche schema che può avvolgere elegantemente questo comportamento?

Questa è l'implementazione in questo momento (in Java):

class Item {

    public final String name;

    public Item(String n) {
        name = n;
    }

}

class Shop {

    public List<Item> items;

    private Shop() { 
        items = new LinkedList<>();
    }

    public static Shop generateTestData() {
        Shop shop = new Shop();
        shop.items.add(new Item("Product A"));
        shop.items.add(new Item("Product B"));
        shop.items.add(new Item("Product C"));
        return shop;
    }

    public static Shop readFromFile(String filepath) {
        // read from file
    }

    public static void writeToFile(Shop shop, String filepath) {
        // write to file
    }

}

NB. Ho considerato l'applicazione di una sorta di modello prototipo in questo modo: creo un'istanza statica di Shop piena di dati di test, quindi l'utente può ottenerne una copia e modificarla come desidera. È una buona idea?

    
posta incud 27.05.2017 - 11:21
fonte

2 risposte

5

In breve, ti manca il supporto di un livello dedicato (astrazione) indirizzato per facilitare l'accesso ai dati e ai suoi diversi archivi. DAL

Il DAL ti consente di disaccoppiare il tuo Shop effettivo dalla sua memoria. Il livello stabilisce una separazione ben definita delle preoccupazioni (responsabilità).

Il design del DAL di solito varia tra i progetti. Tuttavia, penso che DAO e Repository modelli potrebbero fare il lavoro perfettamente in questo caso specifico.

In termini di astrazione, DAO e repository appartengono a diversi livelli. Essendo il Repository più alto e il DAO più basso

Bussines Layer -> Repository -> DAO

Non è necessario implementare entrambi. Sia che tu ne implementi uno o entrambi, la chiave qui è il principio di responsabilità singola .

Tradotto nel tuo caso specifico, puoi fare qualcosa di simile:

ShopRepository:

  • FileShopDAO
  • InMemoryShopDAO
  • DataBaseShopDAO
  • ecc ...

Per ogni situazione specifica potresti usare uno dei DAO

  • Test: InMemoryShopDAO
  • Produzione: DataBaseShopDAO o FileShopDAO

La chiave qui è che tutti i DAO implementano la stessa interfaccia. Ad esempio: ShopDAO .

public ShopRepository {

  private ShopDAO dao;

  public ShopRepository(ShopDAO dao){
    this.dao = dao;
  }

   //Data access methods....
}

Scegli in base ai requisiti e alle tue preferenze.

Ad esempio, potresti decidere di utilizzare 3 repository diversi anziché 3 diversi DAO. Dipende da te.

    
risposta data 27.05.2017 - 13:05
fonte
3

Puoi sicuramente ottenerlo con il modello di build . Secondo il GoF, il suo intento è

to separate the construction of a complex object from its representation, so that the same construction process can create different representations.

L'idea è che un direttore abbia l'incarico di invocare le parti dell'edificio (ad esempio il negozio e la raccolta iniziale) e di assemblarle entrambe insieme.

Il vantaggio è che questo modo di isolare il processo di costruzione dalla rappresentazione interna, in modo che se si decide di utilizzare diversi tipi di collezioni, o addirittura di utilizzare qualche implementazione persistente, il processo di costruzione nel client funzionerebbe ancora : l'unica parte mutevole sarebbe il costruttore concreto.

    
risposta data 27.05.2017 - 13:02
fonte

Leggi altre domande sui tag