c++ - 被设计模式所淹没……从哪里开始？

Question

关闭。这个问题需要更多 focused .它目前不接受答案。












想改进这个问题？更新问题，使其仅关注一个问题 editing this post .

5年前关闭。




Improve this question




我正在编写一个简单的原型(prototype)代码来演示和分析物理代码的 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 是逐点加法)。

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

抽象 I/O 类定义读写函数来填充“myModel”对象

HDF4 派生类

HDF5

HDF5 使用并行 IO

NetCDF

等等...

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

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

我有一点 OOP 经验，但在设计模式方面很少，所以我最近获得了 Gang of Four book "Design Patterns: Elements of Reusable Object-Oriented Software" . OOP 设计师: 您推荐我使用哪种模式将 I/O 与 myModel 集成目的？ 我有兴趣回答这个问题有两个原因:

要了解更多关于一般设计模式的信息

应用我学到的知识来帮助重构一个大型的旧的粗鲁/遗留物理代码，使其更具人类可读性和可扩展性。

我倾向于将 Decerator 模式应用于 myModel ，所以我可以将 I/O 职责动态附加到 myModel (即是否使用HDF4、HDF5等)。但是，我不太确定这是应用的最佳模式。在我开始编码之前，从头到尾阅读《四人帮》这本书感觉像是养成不健康的咖啡因成瘾的好方法。你推荐什么模式？

Answer 1

只写代码。并且当您编写好代码后，请尝试识别您编写的代码中的模式(重要的是不仅仅是 GOF 模式)。如果你不能，别担心 - 在你的下一个项目中，只需再次编写代码，并再次尝试识别该模式和第一个项目中的模式。这就是所有的设计模式——你重复做的事情。而且只有在您至少有一点经验时，才明智地谈论它们。 GOF 书并非旨在成为解决方案的目录。