是否有一种设计模式可以帮助在通用显示器上配置命令？

Question

我有一个显示对象，它显示用户列表并提供一个用于对该列表进行操作的菜单 - 添加新用户、将它们添加到组、删除它们等。现在，显示器配置自己的菜单，因此它可以添加菜单命令如doCreateNewUsers()。不幸的是，这意味着显示的每个实例始终具有“创建新”选项。

我想针对不同的显示实例以不同的方式配置菜单 - 在“用户”选项卡中，它应该包含“创建新”选项，而在“组”选项卡中，它不应该包含。我的第一个想法是外部化菜单，以便我可以以不同的方式配置它。问题是我失去了调用私有doCreateNewUsers()函数的能力！

有针对这种情况的设计模式吗？我不喜欢将 doCreateNewUsers 公开的想法，因为它显示了一个不应由外部类触发的对话框。我可以使显示抽象，以便我可以在匿名子类中定义菜单，但这会扰乱我现在重用小部件的方式 - 我想在创建并初始化显示后配置菜单。我希望有一些行业标准的方法来处理这个问题！

Answer 1

在我看来，在这种情况下您可能会使用策略模式。

Answer 2

显示器可以配置自己的菜单，但前提是该操作可以封装在与菜单项关联的命令中。一旦您进行了这样的设置，您就可以从菜单中添加和删除项目，并且他们不需要访问私有方法，因为他们将有权访问负责该操作的命令。

我认为 命令模式 是你的朋友。

一旦获得命令对象，您就可以使用它们来创建菜单项并提供执行实际命令的方法。

如果您只是添加 User 对象列表，则传递命令对象可能更有意义。如果您传递一个代表用户集合的对象，那么添加一个方法来公开命令对象可能是有意义的。如果是这种情况，那么您可能应该让您的对象实现一个接口以提供对命令对象的访问，例如：

public ICommandProvider
{
    ICollection<ICommand> GetCommands();
}

那么命令可以是：

public ICommand
{
     String GetMenuText();
     void Execute();  
}

让正在显示的对象负责返回命令可以很容易地让命令具有对所显示内容的引用，因此可以对其进行修改（例如添加元素或删除元素）。
显然，确切的细节将取决于您的情况，但类似的东西应该允许您配置显示器的菜单选项，而显示器不需要了解正在执行的操作的详细信息。您可能需要在执行命令后刷新显示。