UML 对于描述模板化代码有用吗？
我想知道 UML 对于描述高度模板化的代码是否有用。我知道 UML 中有参数化类的概念（vector），但是这个不足以描述我们与模板之间的复杂的鸭子类型关系。我总是可以在这些类之间建立关联，但在我看来，这实际上并不能帮助理解它是如何工作的。
此外，考虑到例如 STL 库，算法通常作为函数实现，因此不太适合 OOP 模型，尽管它们的行为仍然非常像引入类之间关联的对象。
那么，绘制 UML 图来描述这样的模板化代码有意义吗？如果是这样，哪种类型的图最有用 - 在“标准”OOP 中，我看到大多数时间都使用类图，但对于模板化代码，其他类型的图可能会更有帮助？如果 UML 不太适合，我还能使用什么？
I'd like to know if UML is useful to describe heavily-templated code. I know that there is a notion of parametrized classes in UML (vector<T> <---- <<bind>> ---- vector<int>), but this won't be enough to describe complex duck-typed relationships that we can have with templates. I can always put associations between such classes, but it seems to me that it won't actually help to understand how it works.
Moreover, considering for example the STL library, the algorithms are often implemented as functions, and thus don't fit very well into the OOP model, though they still behave quite like objects introducing associations between classes.
So, does it make sense to draw UML diagrams to describe such templated code? If so, which kinds of diagrams would be most useful - in "standard" OOP I've seen class diagrams being used most of the time, but probably for templated code some other kinds of diagrams would be more helpful? If UML is not well suitable for that, what else could I use?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
我认为这取决于。
如果不同的实例化将导致显着不同的行为或关系，那么虽然可以使用 UML 进行建模，但它会很丑陋。另一方面，如果不同实例化的行为确实如此不同，那么无论如何，我不确定模板是一个好主意。
但是，如果类之间的关系无论如何实例化都或多或少保持相同，那么 UML 类图对于建模这些关系将与非参数化类一样有用。
I think it depends.
If different instantiations will lead to significantly different behaviours or relationships, then while it would be possible to model with UML, it would be ugly. On the other hand, if the behaviour is really that different with different instantiations, I'm not sure templates are a good idea, anyway.
But if the relationships between classes remain more or less the same no matter how they're instantiated then an UML class diagram is going to be just as useful to model those relationships as it would be for non-parameterized classes.