PHP4 和 UML：设计对象图有意义吗？
我正在记录我为客户构建的 PHP4 系统。该系统将使用 MVC 模式按照面向对象的逻辑进行编写。我已经画好了一个类图；然而，我现在想知道为这样的系统创建对象图是否有意义，因为它相当松散地遵循 OOP 模型。
在这个系统中，最接近面向对象行为的可能是一些方法，这些方法根据它们的调用方式来改变它们的行为，尽管这不能完全称为实例化直接类；对象图会捕获此场景中的任何有用信息，还是我最好完全跳过它们？提前致谢。
I am documenting a PHP4 system I'm building for a client. The system will be written following an object-oriented logic, using the MVC pattern. I have already sketched up a class diagram; however, I am now wondering if it makes sense to create object diagrams for such a system, since it follows the OOP model rather loosely.
The closest thing to object-oriented behavior in this system will probably be a handful of methods changing their behavior based on how they're being called, although this can't exactly be called instancing straight-up classes; would an object diagram capture anything useful from this scenario, or am I better off just skipping them altogether? Thanks in advance.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
根据我的经验，UML 类图最好在孤立的上下文中使用——描述系统的一部分。
所以我的答案是，如果您在文档中描述系统的一部分，并且 UML 类图将帮助读者理解系统的相关部分，那么您应该为该部分绘制一个图表并包括它。
为整个系统绘制一个类图几乎没有什么用处。并且在没有上下文的情况下包含各种类图也很少有用。
使用 UML 时要有策略；它是一种沟通工具，而不是文档工具。 （有点像写作。纸上的文字没有任何意义，除非经过深思熟虑的使用和组织）
In my experience, UML Class diagrams are best used in an isolated context -- to describe a section of the system.
So my answer is that if you are describing a piece of your system in a document, and a UML class diagram would help a reader understand the relevant section of the system then you should do a diagram for that section and include it.
Doing one class diagram for the entire system is rarely, if ever, useful. And including various class diagrams without context is also rarely useful.
Be strategic in your use of UML; it's a communication tool, not a documentation tool. (Sort of like writing. Words on paper means nothing unless used and organized thoughtfully)
我认为你的情况的灵活性与UML的期望相冲突。
我建议从您的图表（和谎言）中抽象实现级别，并将这些方法的功能表示为执行自己工作的独立方法。
I think the flexibility of your situation conflicts with expectations of UML.
I would suggest abstracting the implementation level from your diagram (and lie) and represent the functionality of those methods as independent methods performing their own work.