想象一下，一个以命令式风格编写的遗留C程序：自上而下，没有对象，并夹杂着goto语句。这个程序实现了一个依赖于观察者模式；即酒吧子架构中的订户。
任务是实现到所述程序的OO接口。
什么设计图案最适合这里？起初，我跳到了Adapter模式：
适配器
将类的接口转换为另一个接口客户端预料适配器使类能够协同工作，否则无法由于接口不兼容[Go4，8]
这里的问题是适配器转换另一个类的接口。在这种情况下，没有要转换的类；C没有类。
接下来我想到了proxy:
代理
为另一个要控制的对象提供代理项或占位符访问它。[Go4，9]
这符合——有点——但似乎没有抓住我想要做的事情的本质。
立面
为子系统中的一组接口提供统一的接口。Facade定义了一个更高级的接口，使子系统更易于使用。[Go4,9]
也许。。。这可能是最好的选择，但我不确定。
在这种情况下，哪种设计模式最适用？Thx，Keith:^(
模式使您更容易向已经熟悉相同模式的其他人解释您正在做的事情；它们不会自动让你的工作变得更轻松。
在您的情况下，似乎根本不需要任何模式：您正在编写C++类来定义pub-sub系统的接口，并在实现该接口的成员函数中调用C函数。这是基本的封装：C++类的用户不知道实现内部发生了什么，而实现对他们隐藏了所有的意大利面条/goto。
您可以将其描述为适配器模式的应用程序，即使您所拥有的只是C函数的集合，而不是类。在非常一般的级别上，非OO函数可以被认为是单个顶级类的类函数；您的"适配器"将一组类作为C++接口放在它们之上。