To interface or not to interface

[Steven Schveighoffer]

On Tue, 25 May 2010 09:26:20 -0400, Jacob Carlborg <doob at 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