On Tue, 25 May 2010 09:26:20 -0400, Jacob Carlborg <d...@me.com> wrote:
On 2010-05-24 21.08, Steven Schveighoffer wrote:
Don't user interface objects have data? If a UI component is an
interface, how does it expose access to its data? For example, a .NET
ListView control contains an Items property which you can use to access
the elements in the list view. The Items property returns a
ListViewItemCollection which implements IList, IContainer, and
IEnumerable. I've found these types of abstractions useful when
adding/iterating, etc.
-Steve
I would say that is a bad design, I would go with the MVC pattern. For
example, you have a ListView and when it's ready to display, say row 3,
it calls your delegate and request you to return the item that should be
visible on row 3. Then it's up to you to store the items in some
appropriate data structure, like a list or array.
I don't know if a delegate is enough to implement the pattern. What you
need is a set of delegates that perform operations on the container. Oh
wait, that's an interface!
One interesting difference between an interface and a delegate is that an
interface is a single pointer, whereas a delegate is two. With the
context-pointer design, many more features are possible. For instance,
struct interfaces would be easy, as well as easily tacking on an interface
to a class.
In any case, Windows Forms is probably the easiest UI toolkit I've worked
with (which isn't saying much), I don't think it's a bad design. That
could be the Visual Studio talking though :)
-Steve
