You can say the same thing about the public variable; both classes are dependent on it. If you take the public variable out you have the same problem. Is that tight coupling? Again, just preference and where you want to put or how you want to structure the code. I'm used to using custom events, as well as variables, because most of my work involves updating a model with an event/command, or sending data to a service call in the same fashion. For the original scenario, the components would update properties of a common VO, on change, in a presentation model. And when the button in the parent view was clicked, the VO would be sent, via a custom event, to a command or manager. Like I said, it's all about preference. And that's why we're here; to discuss different points of view and to elevate the level of understanding.
-TH --- In [email protected], "Amy" <amyblankens...@...> wrote: > > --- In [email protected], "Tim Hoff" TimHoff@ wrote: > > > > > > Don't agree. The smoke test for tight coupling is that if component A > > is tightly coupled to component B and you take away component B, you get > > a compiler error in component A. By using an event, that doesn't > > happen. Component A dispatches an event that component B listens for. > > If you take away the listener it doesn't break the dispatcher; and > > vice-versa. Sure, the components both reference the event class. But, > > with your logic, you're saying that two components that both use > > mx:controls:button are tightly coupled together; because they reference > > the same class. > > That's one way of looking at it. > > I look at it like this: > > Component A and Component B both need Component C to operate, so if you take Component C out of the equation (OR OUT OF EITHER COMPONENT), neither one will compile or work, and Component C is only needed to facilitate communication between the two components. Given that there are vanishingly few situations that actually call for Component C in the first place, why create the unnecessary dependency. > > On the other hand, if you have two components that use Button, there are several very real differences. The first is that you don't have to make a custom Button to make it work... If you wrote a Button subclass that was extended in a way that wasn't necessary for the functionality, that would get closer to the analogy. But even then, you could remove Button or its subclass from either class without breaking the way the two interact. > > -Amy >
