Sunday, January 15, 2006

More on interface delegations

As I explained here, Freya allows the programmer to implement an interface type by delegating the implementation of methods from the interface to an instance of an already existing implementation. This trick is borrowed from Delphi, and it's an effective and easy technique for reusing interface implementations. Then, I used this example:

Foo = class(IEnumerable)

implementation for Foo is

// A private instance field.
var Items: array of String := ['Freya', 'rules'];

// Just an implementation detail!
interface IEnumerable is Items;

Our Foo class must implement the IEnumerable interface type, and it does it by delegating the implementation to a string array; all array types implement that interface, don't they? The delegation member contains a mention to the private field Items... but our real interest is the value stored in that field and, since our field is already initialized, it's highly probable that Items won't be referenced from other methods in this class. Why, then, should we need to declare Items at all?
This is a new alternative technique for delegating interface implementation:
implementation for Foo is

interface IEnumerable := ['Freya', 'rules!'];

Now we can merge all what we need for the delegation in a single clause! Just think in all that can be done with this new feature. We have used a string list in our example, but it will be more common to find a regular constructor call as initializer:
implementation for Foo is

interface IEnumerator := new DriveEnumerator;

In short, now we have two kinds of delegation clauses. One of them refers to a field or property in the same class. In this case, you can initialize the field or property in a constructor, or using a field or property initializer. The second and shorter form assigns directly a value in the delegation clause using an initializer. In this case, the compiler declares a hidden field inside the class and takes care of its initialization.



At 2:56 AM, Blogger பாலசந்தர் கணேசன். said...

Can we know more how you have learned .NET. I want to become a .NET architect guide me on how I can learn more about .NET, CLR, ASP.NET, Server controls, Windows Forms, Windows Server Controls.

At 2:21 PM, Blogger Ian Marteens said...


I was not an "early adopter". The funny thing is that all information you need is already contained in the SDK documentation, in the help files. That could help you to save a lot of dollars. Of course, it's not an amenable resource. Books I recommend:

- Inside C#, by Tom Archer and Andrew Whitechapel. There's an edition for .NET 2.0. This was my initial reference for language things.
- The C# Programming Language, by Heljsberg et al. Once you master the fundamentals of C#, which is easy, the best way to learn more about the language is using the real reference. One warning: this book is already included in the SDK documentation! Of course, it is easier to read the paper copy.
- For ADO.NET: Microsoft ADO.NET Core Reference, by David Sceppa. Probably, it's not the best book ever written, but it was the most helpful back when I start reading about ADO.NET. There's a version for ADO.NET 2.

(...I'll split the post...)

At 2:37 PM, Blogger Ian Marteens said...

- For data binding and ADO.NET in depth: Data Binding with Windows Forms 2.0, by Brian Noyes. I love this book.

- Microsoft .NET Distributed Applications: Integrating XML Web Services and .NET Remoting, by Matthew McDonald. It's probably not the best book on each of the topics it covers, but the good thing about it is the wide picture about how you can ensemble the .NET data access puzzle. I don't know whether there's a v2.0 edition or not.

For CLR inners, you have this:

The Common Language Infrastructure Annotated Standard, by Miller and Ragsdale.

But again, you can download a Word copy from Microsoft: actually, this is the CLR standard.

I have collected more book links here:

And, of course, if you need something more specific, just drop me a message:



Post a Comment

<< Home