To interface or not to interface

[Steven Schveighoffer]

On Tue, 25 May 2010 10:01:48 -0400, Jacob Carlborg <doob at me.com> wrote:

> 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];
> }

Yes, I get that.  What I'm saying is this is basically an interface.  The  
difference is that the interface is not required to be declared on the  
container class, and requires 2 words of storage in the ListView per  
function instead of 1 word for all the functions.

Another way to do this is:

listView.items = data;

Where listView.items is an interface that contains the functions you  
need.  If the set of functions is complex, then using the delegates could  
be tedious.

It's just a different way of doing it.  There are benefits to both ways.   
Using the delegates is more flexible because a delegate does not need to  
be defined in a class with a predefined interface being implemented.  It's  
also much easier to build a bunch of delegates on the fly rather than  
build an interface implementation.

-Steve