我正在设计一个库,它提供对我们公司使用的Bug Tracker应用程序的访问。
目前,我们只需要访问简单的函数:
criteria)
搜索错误跟踪器
)
我设计了这个库来提供这些操作的接口,这样我们就可以在新版本发布时透明地替换实现。
为了支持今后更多的行动,我们可以:
问题是-- Decorator似乎太依赖底层基类/接口了。我的意思是,它依赖于这样一个事实,即它所修饰的对象提供了足够的访问权限,可以让它轻松地添加操作。
在这个例子中,如果我不公开底层第三方对象为我的接口中的bug跟踪器提供API,那么装饰器将无法添加更多的操作。
我如何通过更好的设计来克服这个问题?
发布于 2011-12-11 06:52:57
你不需要装饰模式
在这种情况下,装饰器模式不是很有用。它的目的是允许您在运行时追加行为。您正在尝试在编译时附加行为(或多或少)。
请参阅:http://en.wikipedia.org/wiki/Decorator_pattern
此模式允许用户创建以下类型的代码实例:
。
要做到这一点,就需要大量的设计开销。对于一个装饰,您需要实现四个类。
如果您不关心实例化有意未修饰的类型,这将是很大的开销。
你可能根本不需要担心这个
只有当您已经推出了一个接口时,我才会担心这个场景,同时重新部署所有东西(客户端和服务)将花费很大的代价。如果您可以一次性重新部署整个世界,那么只需修改界面即可。
多个接口更适合您的场景。
如果您只想在执行交错推出时保持服务和客户端的运行,我建议您利用.Net允许对接口进行多重继承的事实,并对接口进行版本化。
当发布修改接口的新版本时,添加一个新接口并实现这两个接口。让您的对象实现两个接口。
这将允许您错开推出,并保持向后兼容。您可以在任何时间对您的计划最有意义的时候取消和删除旧的接口。
下面是一个例子。请注意,除了解决您的具体问题之外,我根本没有想出服务的设计:
namespace Version1
{
public interface IOpenDefectService
{
void Submit(string title, string description, int severity);
void Bump(int issueId);
}
}
namespace Version2
{
public interface IOpenDefectService
{
void Submit(string title, string description, int severity);
// Removed Bump method - it was a bad idea
// Added an optional priority field
void Submit(string title, string description, int severity,
int priority);
// Added support for deleting
void Delete(int id);
}
}
public class OpenDefectService : Version1.IOpenDefectService,
Version2.IOpenDefectService
{
// Still must support it until you no longer have any clients using it.
// Here to support staggered rollouts
[Obsolete("This method is deprecated. Don't use it")]
public void Bump(int issueId) { /* Still has implementation... */ }
public void Submit(string title, string description,
int severity) { /* ... */ }
public void Submit(string title, string description,
int severity, int priority) { /* ... */ }
public void Delete(int id) { /* ... */ }
}https://stackoverflow.com/questions/8462416
复制相似问题