design-patterns - "Brokered definition set"设计模式——众所周知的另一个名字？

Question

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

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

所以它促进的是一种共享的、松散耦合的聚合，其中许多 Cars 可能有一个 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!";
    }

}

那么，有没有这个名字？

Answer 1

单例注册

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

我以前用过这个模式，但我从来没有找到它的引用，也不知道如何命名它。

我认为这是一种“Keyed”单例，其中实例存储在某个地方并使用 key 获取。

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

我有大约 50 个数据库表(设为 10 个)并且我有一个用于显示数据的前端“表”，但是数据可以来自这些来源中的任何一个，并且每个来源都需要不同的逻辑(查询，连接、键等)

这个前端是“可配置的”，所以我不知道要显示哪些值，哪些不显示。

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

这在开始时安装在 HashMap 中，后来从数据库表中检索。

代码是这样的:

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.

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

在运行时，用户配置它的 View ，并选择他想看到的内容。

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

DataFetchers 都安装在父类(我不想为此有一个单独的类)的类方法中。

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 或类似的东西。我(可能)喜欢你，出于需要创造了这个。这很可能是一种常见的模式。