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?
“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.