CODEWITHSUNDEEP
design-patterns
Koran
Koran

Reputation: 639

A design pattern question

I am designing an application, and I am unable to point out the correct design for the same. I have one in my mind, but it does not seem to be part of the GOF pattern and so I am not sure whether it is a nice way to go.

My project creates data from any of the possible 15-20 documents (the documents are all of same type, but the data can vary widely). Once the data is obtained, it needs to be formatted in any of the supported 4 formats and displayed. Also, to complicate matters, even though the documents itself are broadly classified to 4-5 types, few of the documents (across these classifications) are formatted in a similar way.

Now, I split it in the following way:

Data creation creates an interface data object with common interface which can handle all these documents.

Data display reads through the data object and displays it in the way it is required.

My first question is that - I did not see about such an interface object in the GOF pattern set. Is this a good design decision to have such a thing?

As I mentioned before, just two documents are formatted the similar way - across classifications. The problem here is that other documents - which should have been formatted the similar way - are not. So, I find myself cloning the code in one scenario while getting the data, which I dont want to.

So, my second question is - what is the best way to handle this?

I will be very thankful if someone can help me out here.

Upvotes: 4

Views: 324

Answers (4)

ewernli
ewernli

Reputation: 38605

Don't try to push too hard pattern in advance. Figure out a few designs and then try to reveal patterns in them. Patterns are meant to communicate and can be seen as reusable for some specific concern only.

So your broad problem is that you have X documents and Y rendered.

  • Try to generate a class hierarchy for the documents that make sense. You can probably factor some logic in a base class or use an interface
  • If you can't figure out interface to abstract all types of document, you may rely on adapters to, well, adapt the various document to a given interface
  • To have multiple renderers, you can have a look at the visitor pattern, the decorator pattern or the strategy pattern, or use just plain inheritance/polymorphism with Y rendered that implements the same interface. It depends on the nature of the variations.
  • To obtain the right renderer according to the use case, you can use a factory to embed the decision and instantiation logic.

GoF patterns are at a lower granularity than your problem. You will have to figure out a design that matches your very specific requirement. In case of doubt, always pick the design that is the simplest / more intuitive. No them one with the most patterns and fancy class hierarchy.

My 2 cents

Upvotes: 5

jojo
jojo

Reputation: 3609

Have you thought about the builder pattern for the data creation

builder Intent

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

for the display you can use a different decorators

Upvotes: 0

Ignacio Vazquez-Abrams
Ignacio Vazquez-Abrams

Reputation: 798456

Sounds like Strategy pattern, with the overall application being MVC with a degenerate Controller.

Upvotes: 1

kgiannakakis
kgiannakakis

Reputation: 104168

Your interface object could be described with the Facade or the Adapter design pattern. Don't worry too much if there isn't a direct match with an existing design pattern - your described solution is the best way to go.

For the second question, you could have a base class that implements the functionality that is common to all classes. Then extend it for all special needs. I know books recommend to prefer composition over inheritance, but this isn't a strict rule and there are cases that inheritance is a good solution.

Upvotes: 0

Related Questions