反射使用语言的UML替代方案

Question

当我们谈论使用反射的语言时，是否有任何UML的扩展/替代？ 我的意思是，我尝试在编写之前将我的项目表达为UML，但是我总是提出“这个方法将通过反射调用，其中方法名称从文件中加载”，这显然打破了我的许多图表。 / p>

谈到C＃，使用属性可以改变我开发方式的很多方面，所以我的所有UML图看起来都很奇怪，因为很多东西都没有编写（例如，如果方法有给定的属性）。

是否有任何视觉语言可以帮助您以某种方式表达“反思”？

Answer 1

我通过有效地思考UML和OOP中的反射来找到解决方案。

如果你认真考虑OOP，你不应该考虑由属性（字段）和方法组成的对象，而是必须将它想象为由其他对象组成（应该）的对象。

话虽这么说，想象方法和属性就像对象（所以我们将拥有UpdateMethod对象或LengthProperty对象）和是这样你就可以更容易地放置 C＃attributes ，或者你可以赋予 C＃delegates 而不是函数指针的含义。

这张图片应该解释一个难以用词语表达的概念：

很可能需要改进UML，因为必须以更好的方式支持广泛使用的功能（反射），而不是像我使用它（这不太好）。