关于 Flex 状态与子类化/继承
我认为我过度使用了 Flex 状态模型。按照 Spark 架构的教导方式，状态应该主要用于更改某个组件的视觉外观。然而，由于对使用 Flex 状态的简单性感到过度兴奋，并且也愿意在运行时重用现有的对象实例，我使我的组件变得非常“厚”，根据特定的状态更改注入不同的视图模型以及其他内容。这造成了一系列同步问题，因此我决定进行子类化和专业化，而不是过度依赖状态。
一般来说，根据经验，状态和子类化之间的边界应该放在哪里？
I think I'm overusing the Flex states model. The way the Spark architecture teaches it, states should mainly be used for changing the visual appearance of a certain component. However, being overly excited about the simplicity of using Flex states, and also willing to reuse existing object instances at runtime, I made my components really "thick", injecting different view models, as well as other stuff, based on a certain state change. This created a bunch of problems with synchronization, so I decided to subclass and specialize instead of relying on states that much.
In general, as a rule of thumb, where should the boundary between states and subclassing be put?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
嗯，据我了解，你有一个巨大的观点，你现在想用继承来分割它？这不会仍然使您的组件变得沉重且难以管理吗？
这里更好的解决方案是使用组合，而不是继承。创建新的、自我管理的小组件，将其整合为一个更大的组件。实际上不应该存在“状态和子类化之间的界限”，因为它们做了两件完全不同的事情。一种是基于视图的更改，另一种是添加功能。
我认为你只是真的混淆了 OOP 概念，应该停止你正在做的事情并在继续之前稍微回顾一下理论。如果你继续沿着当前的道路前进，你最终会到达你要去的地方；意大利面条代码。
Well, from what I understand, you have a huge view that you now want to use inheritance to split it up? Won't that still make your component heavy and hard to manage?
The better solution here is to use composition, not inheritance. Create new, self-managing and small components that come as a whole into a larger one. There really shouldn't be a 'boundary between states and subclassing' because they do 2 completely different things. One is for view based changes while the other is to add functionality.
I think you're just really mixing up your OOP concepts and should really stop what you're doing and go over the theory a bit before continuing. If you continue on your current path, you'll end up where you're heading; spaghetti code.