在子系统设计，我有时看到有只具有一个功能一个高层级的软件设计：它的路线使用类到另一个某一类客户想使用来自客户端的调用。 然而，其本身并不具有任何功能。 采取这样的场景：
说有五个班在保龄球馆子系统：一条小巷，车道，投球手，操作台，和一个分数。 每当子系统外部的客户想要的任何数据显示给用户，它只会传达给将调用任何它拥有获取客户端的请求的数据（例如得分类的控制台（路由器）：客户端调用与getScore（），它调用巷的getScore（），它调用一个投手getScore操作台（））。
我理解，这是一个不好的设计决定，但我想听听其后果你发现有这个路由器类（也可称为“中间人”）的真实世界的例子。 你碰到的系统您正在使用的进化哪些问题？ 你会作出什么样的参数，以说服软件设计，以避免路由器类？
我要说的是，在一些设计路由器是首选的设计模式，如MVC框架，以委托处理程序的URL。 在这种情况下它是真正有用的，因为它提供了什么之间的客户端“看到”和它背后的实际逻辑非常清晰的分离。
每当子系统外部的客户想要的任何数据显示给用户，它只会传达给将调用任何它拥有获取客户端的请求的数据类的控制台（路由器）
这听起来像Facade模式
至于中间人，在下面的例子中，难道不巷是罪魁祸首？
例如得分：客户端调用与getScore（），它调用巷的getScore（），它调用一个投手getScore（））操作台
简化了接口，为客户的子系统之外的利益的一个子系统，可以考虑良好的设计。
Facade模式，以及调解模式执行类似的任务，你所描述的。 您使用中间人名字的暗示在Facade模式调解模式，作为中间人负责与实体都不需要知道如何与其他通信的细节两个实体之间进行谈判。
您可以使用这些模式，以降低耦合的客户端类，它需要使用系统中的调解员或门面屏蔽。 在门面图案的情况下，意图是提供接口的类的系统的方便的方法。 对于Mediator模式，其目的是抽象从客户端执行一个复杂的任务所需的步骤。
我不知道，路由方法调用始终是个坏主意。
看来你只希望有任何抽象附加层相关的问题 - 抽象可以打破，或者它是一个可以胡作非为的潜在如果有东西底层做了更改件事。
我从来没有见过任何所谓深比几层更多，但我只是想象，增加额外的通话将使其更难以追踪的路径信息需要，使故障排除变得更加困难。
一个潜在的问题，不过，如果是每一层实现了自己的错误处理或重试过程，使得一些在每个级别压倒性作为一个整体是微不足道的。 例如，如果巷使得两次尝试检查投球手的得分，和台可尝试3次，检查得分，然后投球手的失败返回得分将导致正在取得6个查询。 在投球手添加一个30秒的超时时间，而你突然等待3分钟后，我应该需要30秒。
OldNewThing有大约在Windows操作系统的的这个例子中的文章，它造成的问题，但现在我似乎无法找到它。
我认为无论是ASP.NET MVC和MVP模式利用这种类型的，你最终的东西简单地处理那些从一端到另一或代表下层到上层的执行的逻辑概念。 这无疑使测试更容易执行，使得本身就是一个重大的好处。 这种现象也创造一些手工或tedeious工作，你可以点击一个按钮，并将它做一个任务，而不是按一下按钮，有什么截距点击，然后调入一些服务管理类，做一些工作。 但在保持你的代码简洁，可读性越分离前经常有时间就更好了。
如果你不是一个测试仪或并不十分关心的图案，然后直接把它以另一种格式。 你有一个链接，将用户的页面。 此链接散落在你的网站所有的地方作为目的地非常重要或使用了很多。 目标的变化。 这可能是一个查找和替换操作...或者你可以插入一个RedirectService（叫什么你会），当有人点击一个链接发生改变并引导唱首歌到正确的位置。 这使得能够在一个位置一旦定义的位置，并且因此改变了一次。 查找并经常更换时间的变化是没有意味着太多改变的事！
不管你怎么看这个......关注点分离是个不错的想法。 用户界面是一个问题。 活动控制器是另一个问题。 活动本身是另一个关注！
