2

I've got a class Shop which contains a collection of Item objects. You can create a shop in two different ways:

  1. Create a shop filled with test data (for debug purposes);
  2. Create a shop by reading the data from file

I also need to write the shop back to file.

There is any pattern that can elegantly wrap this behavior?

This is the implementation right now (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
    }

}

N.B. I considered applying a sort of Prototype pattern in this way: I create a static instance of the Shop filled with test data, then the user can get a copy of that and modify it as he/she wants. Is it a good idea?

  • Possible duplicate of Choosing the right Design Pattern – gnat May 27 '17 at 9:29
  • Looks like you need a DAL. Take a look to DAO or/and Repository pattern – Laiv May 27 '17 at 10:09
  • @Laiv I think you're right, DAO pattern seems perfect. Could you kindly write a short answer for the question? – incud May 27 '17 at 10:19
5

In short, you are missing the support of a dedicated layer (abstraction) addressed to facilitate the access to the data and to its differents storages. The DAL

The DAL allow you to decouple your actual Shop from its storage. The layer stablishes a well-defined separation of concerns (responsabilities).

The design of the DAL usually vary among projects. However, I think that DAO and Repository patterns could do the job perfectly in this specific case.

In terms of abstraction, DAOs and Repositories belongs to different layers. Being the Repository the higher and the DAO the lower

Bussines Layer -> Repository -> DAO

It's not necessary to implement both. Whether you implement one of them or both, the key here is the single responsability principle.

Translated to your specific case, you can do something like this:

ShopRepository:

  • FileShopDAO
  • InMemoryShopDAO
  • DataBaseShopDAO
  • etc...

For every specific situation you could use one of the DAOs

  • Testing : InMemoryShopDAO
  • Production : DataBaseShopDAO or FileShopDAO

The key here is that all the DAOs implement the same interface. For instance: ShopDAO.

public ShopRepository {

  private ShopDAO dao;

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

   //Data access methods....
}

Choose according to the requirements and your preferences.

For instance, you may decide to go with 3 different Repositories rather than 3 different DAOs. That's up to you.

3

You can definitely achieve this nicely with the builder pattern. According to the GoF, it's intent is

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

The idea is that a Director is in charge of invoking the building parts (e.g. the shop, and the initial collection) and assembling both together.

The advantage is that this way of doing isolated the construction process from the internal representation, so that if you decide to use different kinds of collections, or even make use of some persistent implementation, the construction process in the client would still work: the only changing part would be the concrete builder.

  • 3
    Despite our answers are totally differents, I find to be your solution for differents ways of Shop instanciation, to be very elegant. I only miss in the answer the approach to address I also need to write the shop back to file.. That's why I thought an answer related to DAL was appropriated. But I think builder patterns could contribute to a better general solution. Using factories (for instance) to initialise a Shop from files is something I have never thought before and I like it. – Laiv May 27 '17 at 12:12
  • @Laiv Thanks. Indeed, I only answered on the creational pattern. The logic for writing back would be a classical serialization issue. In fact, the loading of the collection from a file could be implemented as a deserialization factory. But it doesn't need to, if the items are not polymorphic. Anyway, the issue would be for the concrete builder. I wasn' t more specific, because OP's persistance logic is a simple load/save of the catalog state. A real catalog would certainly work with a data layer and need to map objects to database, and handle lots of issues not in scope of the question. – Christophe May 27 '17 at 13:37
  • I see. Fair enough! – Laiv May 27 '17 at 13:40

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.