Flex 中的相反代码
为什么在 Flex 中，代码隐藏模式使用 Actionscript 类作为基类，而不是使用 MXML 组件？
我的意思是，为什么我们不在新的 AS3 类中扩展 MXML，而不是在类后面扩展我们的 AS3 代码？
使用这种方法似乎更自然，因为这是一个真正的扩展，我们正在向 MXML 基础添加代码和功能。
使用代码隐藏模式是对 OOP 的一种破解，每次我们向 MXML 添加组件时，我们都需要修改 AS3 类，也就是说，如果我们修改子级 (MXML)，我们也需要修改父级 (AS3)。
后面相反的代码（“前面的代码”）有什么问题？
Why in Flex the code behind pattern is using the Actionscript class as a base class instead of using the MXML component for that?
I mean, instead of extending our AS3 code behind class, why we don't extend our MXML in a new AS3 class?
Using that approach seems more natural, because is a real extension, we are adding code and functionalities to our MXML base.
Using the code behind pattern is a hack to OOP, every time we add a component to our MXML we need to modify our AS3 class, that is, if we modify the child (MXML) we need to modify the parent (AS3) too.
What's wrong with the opposite code behind ("code in front"?) ?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（4）
这就是 Adobe 决定重新设计其组件架构并创建 Spark 组件集和相应的换肤机制的原因。
在这个新的哲学中，您创建一个扩展 SkinnableComponent 或 SkinnableContainer 的 ActionScript 类，在其中描述组件的行为。然后，您可以在 MXML 中创建一个外观类，定义组件的外观（可能还有一些视觉行为，但没有组件的基本行为）。
这样可以清楚地分离关注点。它不是代码隐藏的对立面，但它是一种不同的方法，一旦掌握了它的窍门，它就会非常有效。
That's kind of why Adobe decided to redesign its component architecture and created the Spark component set and the according skinning mechanism.
In this new(-ish) philosophy you create an ActionScript class that extends SkinnableComponent or SkinnableContainer, in which you describe the behavior of your component. You can then create a skin class in MXML that defines what your component will look like (and perhaps some visual behavior, but no essential behavior of the component).
This allows for a clean separation of concerns. It's not the opposite of code-behind, but it's a different approach that works really well once you get the hang of it.
代码受欢迎的主要原因是工具。您无法在 Flex Builder 3 设计环境中拖动基于 AS3 的组件。我尝试过各种解决方法，但它们都有问题。事实上，这是我在博客上写的第一件事：
http://www.rogue-development.com/blog2/ 2007/03/code-in-front/
我还没有在 Flash Builder 4 中重新尝试过这一点。主要是因为，从那时起，我开始意识到 Flex 布局工具很糟糕，而且我很少使用它。因此，我最近的所有开发都是在代码前面进行的。
如果您需要绑定到 MXML 中的变量，则可以在 MXML 中定义该变量，然后可以通过子类中的继承来使用它。
我不太热衷于单层组件的火花蒙皮。如果您的组件具有完全相同的视觉外观，则前面的代码更容易开发。 （皮肤对于需要多个皮肤的组件来说是完美的）
The main reason code behind got popularity was because of the tooling. You just can't drag an AS3 based component around in the Flex Builder 3 design environment. I've tried various work-arounds, but they were all problematic. In fact it was the first thing I ever blogged about:
http://www.rogue-development.com/blog2/2007/03/code-in-front/
I haven't re-tried this in Flash Builder 4. Mostly because, since then, I've come to the realization that the flex layout tool is crap, and I rarely use it. Because of that, all of my recent development has been code-in-front.
If you need to bind to a variable in your MXML, you define that variable in MXML, it's then available through inheritance in your subclass.
I'm not a huge fan of spark skinning for single-skin components. If you have a component that has exactly one visual look to it, code in front is far easier to develop with. (Skinning is perfect for components that do need multiple skins)
“代码在前面”是一种更自然的扩展和 OOP 设计，因为我们正在使用 AS3 中的功能扩展 MXML，并且每次更改子级时都不需要更改父级。
但它有一个问题，我们不能在 MXML 中使用绑定，因为现在我们的 MXML 是我们的基类，并且我们的变量/函数位于 AS3 子类中。
编辑：前面代码的另一个问题是您在设计模式下看不到“AS3组件”（未在FB4+中测试，也许现在可以工作）。有关此内容的更多信息，请阅读 Marc Hughes 的回复。
"Code in front" is a more natural extension and OOP design, because we are extending our MXML with functionalities in AS3 and we don't need to change our parent every time we change our child.
But it has a proble, we can't use binding in MXML because now our MXML is our base class and we have our vars/functions in the AS3 child class.
EDIT: another problem with code in front is that you can't see your "AS3 componente" in Design Mode (not tested in FB4+ maybe it's working now). For more about this read Marc Hughes's reply.
我认为造成这种情况的原因是从 Flash 时代继承的遗留组件架构，您可以拖入一个黑盒组件，最多在颜色/形状/字体级别上稍微摆弄一下皮肤，而不是（可以） t) 触摸它是如何工作的。
I think the reason for this is the legacy component architecture inherited from Flash times, where you'd drag in a black box component and at most fiddle a bit with the skin on a colours / shapes / fonts level and don't (can't) touch how it works.