【问题标题】:Design of a multi-level abstraction software多层次抽象软件的设计
【发布时间】:2012-12-28 22:58:53
【问题描述】:

我现在正在设计一个软件,它有几个抽象层次。这可能是我开始设计的最复杂的一段代码,并且它要求易于升级,所以我想在开始编写任何代码之前确保我走在正确的轨道上。

基本上,将有 3 个主要级别的课程。这两个班级需要互相交谈。

首先是输入源数据。目前有两种主要类型的输入数据,它们产生相似但不相同的输出。这些类的主要目标是从两个不同的来源获取数据并将其转换为通用接口,以供程序的其余部分使用。

第二组将是外部库的适配器。该库一直在定期更新,我没有理由怀疑它不会在这些年中继续更新。最有可能的是,每次升级都将与前一次非常相似,但可能会进行一些小的更改以支持新的库版本。这个级别将负责获取输入,并格式化它们以供输出类使用。

最后一类是输出。我认为这不需要多个版本,但至少需要指定两个不同的输出目录。我怀疑最简单的做法是在创建输出类时简单地传入一个输出目录,这是唯一需要的抽象级别。这个类会经常更新,但不要求支持多个版本。

【问题讨论】:

  • 你真的需要课程吗?输入和输出?记住上课的黄金法则;如果你的类有两个方法,其中一个是__init__,那么它不是一个类而是一个函数。
  • 输入和输出实际上是复杂的集合,即它们将输入和输出完全不同的格式、不同的文件等。这将不仅仅是一个简单的函数。
  • 记住python.org/dev/peps/pep-0020。尤其是“简单胜于复杂”。

标签: python design-patterns


【解决方案1】:

如下设置代码,基本上遵循bridge pattern,但有多个抽象层。

输入类将是抽象。目前两种不同的获取输出方式是两个不同的具体类,如果需要可以添加更多的具体类。

包装类将是factory pattern。大多数代码在各种实现之间应该是通用的,所以这应该可以很好地处理细微的差异。

输出类将作为实现类的一部分包含在内。没有真正需要的模式,因为这个类只需要一个版本。此外,实现者很可能是单身人士。

【讨论】:

    猜你喜欢
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 2011-08-16
    • 1970-01-01
    • 1970-01-01
    相关资源
    最近更新 更多