软件设计问题:路由器类 [英] A Software Design Issue: The Router Class

问题描述

在子系统设计中，有时我会看到具有一个仅具有一个功能的高级类的软件设计:它会将来自使用该类的客户端的调用路由到该客户端想要使用的特定类的另一个调用.但是，它本身没有任何功能.采取这种情况:

说保龄球馆子系统中有五个类:一个小巷，一个车道，一个保龄球馆，控制台和一个计分.每当子系统外部的客户端希望向用户显示任何数据时，它只会与控制台(路由器)进行通信，控制台将调用其持有的任何类来获取客户端请求的数据(例如，分数:客户端调用具有getScore()的控制台，该控制台调用Lane的getScore()，该控制台调用Bowler的getScore()).

我知道这是一个错误的设计决定，但是我想听听现实世界中的示例，这些示例会发现您发现具有此路由器类的后果(也称为中间人").随着您所使用的系统的发展，您遇到了哪些问题?您会说什么说服软件设计人员避免使用路由器类?

解决方案

我认为在某些设计中，路由器是首选的设计模式，例如在MVC框架中委托URL的处理程序.在这种情况下，它确实很有帮助，因为它在客户端看到"的内容与背后的实际逻辑之间提供了非常清晰的隔离.

In subsystem design, I sometimes see software designs that have one high-level class that has only one feature: It routes a call from a client using the class to another a certain class the client would like to use. However, it alone does not have any functionality. Take this scenario:

Say there are five classes in the bowling alley subsystem: An alley, a lane, a bowler, control desk, and a score. Anytime a client outside the subsystem wants any data to display to a user, it would communicate only to the control desk (the router) that would call any of the classes it holds to get the client's requested data (a score for example: Client calls control desk with getScore(), which calls a Lane's getScore(), which calls a Bowler's getScore()).

I understand this is a bad design decision, but I'd like to hear real-world examples with consequences you discovered of having this router class (Can also be known as a "middleman"). What issues did you run into as the system you were working on evolved? What arguments would you make to persuade software designers to avoid router classes?

解决方案

I'd argue that in some designs a router is the preferred design pattern, such as in MVC frameworks to delegate handlers for URLs. In that situation it's really helpful because it provides a very clean separation between what the client "sees" and the actual logic behind it.

这篇关于软件设计问题:路由器类的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！