“经纪定义集”设计模式——众所周知的另一个名字？

在我参与多年的一个项目中，我逐渐形成了一种设计模式，事实证明它对我来说非常有用。有时我觉得我应该对此有点福音派，但如果我尝试并发现这只是我对某人旧帽子的版本，我会有点尴尬。我翻遍了设计模式，徒劳地寻找它，而且我还没有遇到其他人谈论它，但我的搜索并不详尽。

核心思想是拥有一个管理一组定义对象的代理对象，每个定义对象构成一些复杂属性的可能值。例如，您可能有 Car、Plane 和 Generator 类，它们都具有 EngineType。 Car 不存储自己的 EngineType 对象，它存储某种类型的引用键，用于说明其拥有的 Engine 类型（例如整数或字符串 ID）。当我们想要查看 EngineType（例如 WankelEngine）的属性或行为时，我们向 EngineTypeBroker 单例对象询问 WankelEngine 的定义对象，并向其传递引用键。该对象封装了有关 EngineTypes 的所有有趣的内容，可能只是一个属性列表，但也可能加载了行为。

因此，它促进的是一种共享的、松散耦合的聚合，其中许多汽车可能有一个 WankelEngine，但只有一个 WankelEngine 定义对象（并且 EngineTypeBroker 可以替换该对象，利用松散耦合来增强运行时态射）。

我使用此模式的一些元素（继续使用 EngineType 作为示例）：

1. 总是有 IsEngineType(x) 和 EngineType(x) 函数，分别用于确定给定值是否是 EngineType 的有效引用键以及检索与引用键对应的 EngineType 定义对象。
2. 我总是允许给定 EngineType 使用多种形式的引用键，总是至少有一个字符串名称和定义对象本身，通常是一个整数 ID，有时是聚合 EngineType 的对象类型。这有助于调试，使代码更加灵活，并且在我的特定情况下，缓解了与旧实践相关的许多向后兼容性问题。 （在这个项目的上下文中，人们用来执行所有这些操作的常用方法是为 EngineType 可能具有的每个属性定义哈希值，并通过引用键查找属性。）
3. 通常，每个定义实例都是该定义类型的通用类的子类（即 WankelEngine 继承 EngineType）。定义对象的类文件保存在 /Def/EngineType 等目录中（即 WankelEngine 的类将是 /Def/EngineType/WankelEngine）。因此，相关的定义被分组在一起，类文件类似于 EngineType 的配置文件，但具有定义代码的能力（通常在配置文件中找不到）。

一些简单的示例伪代码：

class Car {

    attribute Name;
    attribute EngineTypeCode;

    object GetEngineTypeDef() {
        return EngineTypeBroker->EngineType(this->GetEngineTypeCode());
    }

    string GetDescription() {
        object def = this->GetEngineTypeDef();
        return "I am a car called " . this->GetName() . ", whose " .
            def->GetEngineTypeName() . " engine can run at " .
            def->GetEngineTypeMaxRPM() . " RPM!";
    }

}

那么，这有一个名字吗？

单例注册中心

信不信由你。今天早上我也在想同样的事情。

我以前使用过这种模式，但我从未找到它的参考，也不知道如何命名它。

我认为这是一种“键控”单例，其中实例存储在某处，并使用密钥获取它们。

我上次使用它是从不同来源检索数据。

我有大约 50 个数据库表（使其成为 10 个），并且我有一个前端“表”，其中要显示数据，但数据可以来自任何这些源，并且每个源都需要不同的逻辑（查询、联接、键） ， ETC。 ）

该前端是“可配置的”，因此我不知道要显示哪些值以及哪些值不会显示。

解决方案是将columnName（在前端）作为键，并获取正确的实例来创建正确的查询。

它一开始就安装在哈希图中，后来从数据库表中检索。

代码是这样的：

class DataFetcher {
    abstract Object getData( Object id );
}

class CustomerNameDataFetcher extends DataFetcher {
    Object getData( Object customerId ) { 
        // select name from customer where id = ? 
     }
}

class CompanyAdressDataFetcher extends DataFetcher { 
     Object getData( Object customerId ) { // don't ask why.
          // select name from company , customer where customer.co = company.co and cu = ?  etc.
     }
} 

class ProductColor extends DataFetcher { 
     Object getData( Object x ) { 
     // join from customer to color, to company to season to a bunch of table where id = ? 
}

// And the list goes on.

每个子类使用不同的逻辑。

在运行时，用户配置其视图，并选择他想要查看的内容。

当用户选择要查看的列时，我使用列名称和 Id 来获取数据。

DataFetcher 全部安装在父类中（我不想为此有一个单独的类）的类方法中。

class DataFetcher {
    abstract Object getData( Object id );

    private static final Map fetchers = new HashMap();static { 
        fetchers.put("customer.name", new CustomerNameDataFetcher() );
        fetchers.put("company.address", new CompanyAdressDataFetcher () );
        fetchers.put("product.color", new ProductColor () );
        ...
    }
    public static DataFetcher getFetcher( String id ) { 
        return fetchers.get( id );
    }      

}

最后填充前端表我只是这样称呼它：

伪代码

 for each row in table 
      for each column in row
          column.text = DataFetcher.getFetcher( column.id ).getData( row.id )
       end
 end

是这样吗？或者我误读了你的描述，我的描述完全不同。

最后我认为这被称为 SingletonRegistry 或类似的东西。我（可能）喜欢你，出于需要而创造了这个。这很可能是一种常见模式。