Overwhelmed by design patterns... where to begin?

Question

I am writing a simple prototype code to demonstrate & profile I/O schemes (HDF4, HDF5, HDF5 using parallel IO, NetCDF, etc.) for a physics code. Since focus is on IO, the rest of the program is very simple:

class Grid
{
public:
  floatArray x,y,z; 
};

class MyModel
{
public:
  MyModel(const int &nip1, const int &njp1, const int &nkp1, const int &numProcs);
  Grid grid;
  map<string, floatArray> plasmaVariables;
};

Where floatArray is a simple class that lets me define arbitrary dimensioned arrays and do mathematical operations on them (i.e. x+y is point-wise addition).

Of course, I could use better encapsulation (write accessors/setters, etc.), but that's not the concept I'm struggling with. For the I/O routines, I am envisioning applying simple inheritance:

• Abstract I/O class defines read & write functions to fill in the "myModel" object
  • HDF4 derived class
  • HDF5
  • HDF5 using parallel IO
  • NetCDF
  • etc...

The code should read data in any of these formats, then write out to any of these formats. In the past, I would add an AbstractIO member to myModel and create/destroy this object depending on which I/O scheme I want. In this way, I could do something like:

myModelObj.ioObj->read('input.hdf')
myModelObj.ioObj->write('output.hdf')

I have a bit of OOP experience but very little on the Design Patterns front, so I recently acquired the Gang of Four book "Design Patterns: Elements of Reusable Object-Oriented Software". OOP designers: Which pattern(s) would you recommend I use to integrate I/O with the myModel object? I am interested in answering this for two reasons:

• To learn more about design patterns in general
• Apply what I learn to help refactor an large old crufty/legacy physics code to be more human-readable & extensible.

I am leaning towards applying the Decerator pattern to myModel, so I can attach the I/O responsibilities dynamically to myModel (i.e. whether to use HDF4, HDF5, etc.). However, I don't feel very confident that this is the best pattern to apply. Reading the Gang of Four book cover-to-cover before I start coding feels like a good way to develop an unhealthy caffeine addiction. What patterns do you recommend?

Answer 1

Just write the code. And when you have written it, try to recognise the patterns (and importantly not just the GOF patterns) in the code you have written. If you can't, don't worry - on your next project, just write the code again, and again try to recognise the patterns in that and the first project. That's all design patterns are - things you do repeatedly. And they are only sensible to talk about once you have at least a modicum of experience. The GOF book is not intended to be a catalogue of solutions.

Answer 2

Personally, I wouldn't go about trying to figure out what pattern to apply. Instead I'd simple focus on how the code should be revamped to be more readable and maintainable.

At some point you'll do this enough that the real patterns will start emerging. At that point go back to the GoF book to figure out how best to tweak them.

Answer 3

I agree with Neil in that it is better to "discover" the patterns lying dormant in your code, rather than trying to impose a ready-made idea onto your design. For this, I recommend Refactoring to Patterns by Josh Kerievsky - it is a worthy read which gives you lots of insight into how you can actually use and work with patterns in your daily development work.

That said, Decorator is used e.g. in the Java IO Stream library, so there is precedent for what you have in mind :-)

Answer 4

"Which pattern(s) would you recommend I use to integrate I/O with the myModel object?"

You're asking the wrong question. The question you should be asking is, "How can I separate my model from I/O?"

There's lots of answers. One interesting setup I've seen is Robert C. Martin's use of proxy. Your idea of using decorator also has merit.

I strongly disagree with those telling you not to worry about patterns. It is true that you should let the problem dictate the solution but until you actually try to use patterns you'll never learn to recognize them nor will you be able to use them in architectural discussions; patterns are very important to being able to discuss design and architecture and if you don't have the vocabulary you'll be severely handicapped in such discussions.

Perhaps more important than patterns though is to learn the principles that cause them. Learn the Open/Closed principle (the primary one) and the LSP. Also keep in mind principles like the single responsibility principle and others. Design patterns are born out of following these principles so knowing them intimately will help you recognize when a pattern can be applied and why one particular pattern can help more than another.

Answer 5

Well, here is a website with C++ examples of the Design Patterns (to begin with): Vince Huston. The design is minimalist, but it gives examples and recommendations.

For your issue, I don't think the Decorator fits. The goal of the Decorator is to add something. The traditional example is to add a frame on a paint.

Here I think you are looking toward Strategy. The idea of Strategy is to choose, at runtime, how to perform a task. It is usually combined with an AbstractFactory which given a key returns the right concrete strategy.

For example, imagine that you choose the strategy based on the extension of the file:

class IDecoder
{
public:
  virtual void execute(Model& model, File const& file) const = 0;
private:
};

class HDF4: public IDecoder
{
public:
  virtual void execute(Model& model, File const& file) const;
private:
};

class DecoderFactory
{
public:
  static std::auto_ptr<IDecoder> Get(std::string const& fileName);
private:
};

class Model
{
public:
  Model(std::string const& fileName)
  {
    std::auto_ptr<IDecoder> decoder = DecoderFactory::Get(fileName);
    File file(fileName);

    decoder->execute(*this, file);
  }
};