我真的希望有人能告诉我我错了。是否有面向对象或模块化文件和数据 I/O 的技术/模式?是否有一些约定可以遵循以添加一些代码可重用性?我知道存在各种工具使读取单个文件更容易,例如 XML 解析器等,但我指的是使用这些工具的更大设计。
问题不限于一种语言;我在 Java、C、Matlab、Python 等中都遇到了同样的问题。
这是一个关于何时保存对象的问题,它涉及到编程和文件操作。该问题似乎涉及到工厂模式,其中文件的内容被构建,最终写入磁盘。我的问题是关于整体架构,包括用于写操作的工厂,以及用于读取/获取操作的(在此插入模式)。
我能想到的最好的解决方案是外观模式...但是那些外观中的代码实在是太丑陋了。
请有人告诉我是否存在一种模式,可以重用我的一些代码,或者至少为未来的读写操作提供一个模板。
有人问过模块化设计,但答案都是针对该提问者的问题,并不完全有用。
示例
这只是一个示例,基于我去年做的一个项目。可以随意提供其他示例。
我们的程序是一个物理沙盘。我们想要加载描述沙盘中物体物理属性的XML数据。我们还需要加载包含3D渲染信息的.3DS文件。最后,我们需要查询SQL数据库以了解谁拥有哪些物体。
当支持新的3D模型格式时,我们也需要能够支持这些格式。我们还不知道这些文件的样子,但我们想预先设置好代码框架。这样,一旦我们获得新的数据架构,加载例程就可以快速实现。
来自所有3个来源的数据将用于创建我们软件中的对象实例。
稍后,我们需要将物理信息(如位置和速度)保存到数据库中,并将自定义纹理信息保存到本地文件中。我们不知道纹理将是什么类型的文件,因此我们只想布置好代码结构,以便稍后可以插入保存代码。
没有某种设计模式,即使是少量的对象也会迅速导致紧密耦合的网络。
外观模式可以将对象/数据与相应的文件解耦,但这只是将问题集中在输入和输出外观中,很快就会变成一个噩梦般的混乱。此外,对象/数据现在与外观紧密耦合,因此并没有真正获得模块化。
从三周前编辑...
之前,当我第一次提出这个问题时,我提供了一堆伪代码,但后来我决定它使我的主要问题变得晦涩难懂。可以说:我不得不使用大约2000行非常奇怪的代码来进行那个特定的读取操作,它在处理和组织方面做得很少,我将永远无法在其他项目中再次使用它。
我希望将来避免编写这样的代码。
zohoFile
当作一个对象来处理,它继承了一个抽象的..File
吗?这样,每当有新的应用程序/客户端出现时,你只需要实现特定于该应用程序/客户端的抽象方法即可。然后,getZohoFiles
只需创建List<ZohoFile>
并在每个对象上调用get
(或其他)方法。 - ketan vijayvargiya