To interface or not to interface

[Jacob Carlborg]

On 2010-05-25 15.38, Steven Schveighoffer wrote:
> 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!

What I was trying to say is that a ListView should not contain a data 
structure. I try to explain that I want to say in code instead:

auto data = new Item[10];
auto listView = new ListView;
listView.numberOfRows = size_t delegate (ListView lv) {
    return data.length;
}
listView.itemAtRow = Item delegate (ListView lv, size_t row) {
     return data[row];
}

Now Item could be an interface but it don't have to be. I suggest you 
have a look at Apple's documentation of NSTableView:

* 
http://developer.apple.com/mac/library/documentation/Cocoa/Reference/ApplicationKit/Classes/NSTableView_Class/Reference/Reference.html 


* 
http://developer.apple.com/mac/library/documentation/cocoa/Conceptual/TableView/Tasks/UsingTableDataSource.html#//apple_ref/doc/uid/20000117

> 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 :)

I suggest you have a look at Cocoa, it uses the MVC pattern.

> -Steve


-- 
/Jacob Carlborg