设计模式不堪重负......从哪里开始？

Question

我正在编写一个简单的原型代码,用于演示物理代码的I/O方案(HDF4,HDF5,HDF5,使用并行IO,NetCDF等).由于重点是IO,程序的其余部分非常简单:

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;
};

哪个floatArray是简单的类,它允许我定义任意尺寸的数组并对它们进行数学运算(即x + y是逐点加法).

当然,我可以使用更好的封装(写访问器/设置器等),但这不是我正在努力的概念.对于I/O例程,我正在设想应用简单继承:

• Abstract I/O类定义了读写函数来填充"myModel"对象
  • HDF4派生类
  • HDF5
  • HDF5使用并行IO
  • 的NetCDF
  • 等等...

代码应该以任何这些格式读取数据,然后写出任何这些格式.在过去,我会AbstractIO向myModel 添加一个成员,并根据我想要的I/O方案创建/销毁此对象.通过这种方式,我可以做类似的事情:

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

我有一些OOP经验,但在设计模式方面很少,所以我最近获得了四人帮书"设计模式:可重复使用的面向对象软件的元素".OOP设计者: 您建议我使用哪种模式将I/O与myModel对象集成？ 我有兴趣回答这个问题有两个原因:

• 要了解有关设计模式的更多信息
• 应用我学到的东西来帮助重构一个大的旧的crufty /遗留物理代码,使其更具人性化和可扩展性.

我倾向于应用Decerator模式myModel,因此我可以动态地附加I/O职责myModel(即是否使用HDF4,HDF5等).但是,我不觉得这是适用的最佳模式.在开始编码之前阅读"四人帮"一书的封面感觉就像是一种培养不健康的咖啡因成瘾的好方法.你推荐什么样的图案？

Answer 1

只需编写代码即可.当你编写它时,尝试在你编写的代码中识别模式(更重要的是不仅仅是GOF模式).如果你不能,不要担心 - 在你的下一个项目中,只需再次编写代码,然后再次尝试识别该模式和第一个项目中的模式.这就是所有的设计模式 - 你反复做的事情.一旦你至少有一点点经验,他们只会明智地谈论.GOF书籍不是一个解决方案目录.