使用外观设计模式|缺点/解决方案/建议

Facade Object中的每种方法都是在几个接口中公开的几种其他方法的组合。在这段时间内，随着我们将了解通过组合复杂系统中可用的不同接口和其方法可以实现的不同操作，该对象也将增长。使用外观设计模式|缺点/解决方案/建议

我的问题很简单：

1）这是一个更好的选择与门面继续下去还是我们有一些可用的其他选择？因为随着我们增加适应Facade对象中每个新操作的方法数量，它也变得复杂。 我可以想到的一个可能的解决方案是创建一个门面

2）另外，当我们说它变得复杂时，是否有由门面暴露的限制方法？ Update：我的分析说，如果它很难理解和重新考虑你的设计，停止向门面添加更多的方法; is that it？

来源

2013-10-14 Rupesh

由于问题是相当开放的，我推荐Head First Design Patterns ch。 7，那里解释了很多最佳实践。而2） - 限制是它开始让你和你的程序员感到困惑。 – LastFreeNickname

@LastFreeNickname：哪一部分你不明白？请让我知道我也会尝试添加。 – Rupesh

由于您的问题非常抽象，因此很难以确保您所写内容的具体内容来回答问题。

据我所知，你问的问题是真的，如果你有

interface A { public void a(); } 
interface B { public void b(); } 

class ABFacade { 
    private final A a = ... 
    private final B b = ... 
    public void ab() { a.a(); b.b(); } 
}

则是有用与否？

答案是要依赖于

问题域 - 如何定义的呢？
如何命名事物 - 人们会理解它吗？
代码重用 - 是否有不止一件事情需要调用facade方法？

我不认为有一个正确的答案 - 至少没有具体的例子。这也取决于使用这种模式的目的是什么 - 更好的代码重用？更少的重复代码集可以完成一些复杂的事情？创建阻塞点所有X必须通过的代码？对其他开发人员的清晰度？这个问题的答案会深刻地影响你的代码的外观。

我可以推荐一些一般的东西，这可能有助于产生一些有用的东西：

如果一个门面方法将只在一个地方使用，但可能不应该是在门面 - 如果它的代码只有一个客户端，这可能是更有意义的做内联的所有步骤
可以对立面上的某些操作给出明确的命名？结果会比写出正面所做的一切更直观吗？如果是这样，那么这可能应该在门面

最后，它只是一个模式。如果它允许您编写更小，更好或更可靠的软件，请使用它;如果没有，请不要打扰。

来源

2013-10-14 07:01:27

有用的答案，但正如您在答案中突出显示的那样，* ab *是您创建的操作，只是为了执行一项操作，然后可以有多个这样的组合。我的问题是围绕着这些线，当你确定新的操作，并考虑添加新的方法，你的立面OBJ，使它更重。我认为Facade不会比帮助。 – Rupesh

@Tim Boudreau'如果一个门面方法只能在一个地方使用，那么它可能不配置在门面中。“不是在DI方面，它对聚合服务非常有用：http：// blog。 ploeh.dk/2010/02/02/RefactoringtoAggregateServices/。并且“内嵌所有步骤”违反了SRP并违反了TDD，因此降低了可维护性。 – Fendy

我也不同意'如果一个门面方法只能用在一个地方...'。这就像说如果要从一个地方调用方法就不要制作方法。 – weston

使用外观设计模式|缺点/解决方案/建议

回答

相关问题