Just one counter-thought to play devils advocate a bit. One thing you have
to consider is performance, especially on something like UIComponent that
drives every little thing in your app. And in general, creating lots of new
Objects is slow (and disposing of them can also be slow due to the GC).
Overall I think most people see the benefit of a highly-composited
UIComponent that lets you define only the necessary functionality and lets
you swap out each little bit of behavior with another. However, if you end
up with all UIComponents creating 100 new objects each time a UIComponent
is initialized, you may be trading a nice architecture for performance. The
big consideration, I think anyway, when deciding on what should be moved to
composition, is what pieces would we want to turn off by default? Focus is
a good example. If there are a lot of cases where we want focus off (even
to the point where that would be default and you'd have to turn it on
explicitly), then I love the idea of stripping 99% of the focus code out of
UIComponent and using something like a FocusBehavior. But if it's going to
be on by default, and used in most cases, then all we've done is introduced
the creation of a new Object into all UIComponents.

Reply via email to