To interface or not to interface

Jacob Carlborg doob at me.com
Wed May 26 03:55:14 PDT 2010


On 2010-05-25 17.03, Michel Fortin wrote:
> On 2010-05-25 10:01:48 -0400, Jacob Carlborg <doob at me.com> said:
>
>> 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:
>
> What Cocoa is doing is basically allowing 'optional' methods in an
> interface (a protocol in Objective-C). Taking your example, the
> NSTableViewDataSource protocol contains a lot of functions to provide
> the required data to a table. But many of them are optional: for
> instance a data source that does not implement the
> "...setObjectValue..." method will prevent the table's content from
> being edited, one that doesn't implement the
> "...sortDescriptorsDidChange..." method prevents the table from being
> sorted by clicking on its column headers, one that doesn't implement the
> various methods for drag and drop will prevent rows from being dragged.

I've always thought that this design and the similar Java uses with 
interfaces, anonymous classes and adapters is just a design chosen 
because the languages are limited, don't support delegates.

> (Note to Cocoa programmers: Prior to the Mac OS X 10.6 SDK,
> NSTableViewDataSource was an informal protocol implemented as a category
> of unimplemented functions in NSObject. The 10.6 SDK changed it to be a
> formal protocol with optional methods, a feature added to Objective-C 2.0.)
>
> In D, one could create one interface for each of these groups of things,
> but then you'll have a bazilion of small interfaces and either you lose
> the relation between them or you end up with a combinational explosion.
> For instance, let's create a bunch of interfaces for what I wrote above:
>
> interface TableDataSource {...}
> interface TableDataSourceEdit : TableDataSource {...}
> interface TableDataSourceSort : TableDataSource {...}
> interface TableDataSourceDrag : TableDataSource {...}
> interface TableDataSourceDropTarget : TableDataSource {...}
>
> Now, when I implement the table view I could have one data source
>
> class TableView {
> TableDataSource dataSource;
> }
>
> and then I'd dynamically check whether my data source implements each of
> the child interfaces:
>
> auto dataSourceEdit = cast(TableDataSourceEdit)dataSource)
> if (dataSourceEdit) {
> dataSourceEdit.setObject(object, row, column);
> } else {
> // data source cannot be edited
> }
>
> That's essentially what is done in Cocoa, except that in Cocoa an object
> usually checks for the existence of one of its delegate function prior
> calling it instead of having a whole lot of interfaces. This is why
> protocols are allowed to have optional methods.
>
> Perhaps interfaces could be allowed to have optional methods that would
> require you to check if they're implemented before use.

How would you check if a method is implemented or not ?

-- 
/Jacob Carlborg


More information about the Digitalmars-d mailing list