I can''t seem to grasp the general ideas behind Attributes and reflection in C#? Can someone point me out what it is, what the use of it is and the finer details? I read "A Programmer''s Introduction to C#" but I can''t really grasp the concept from there. The same goes for interfaces and delegates. What''s the idea behind those? Toolmaker

quote:Original post by Toolmaker
I can''t seem to grasp the general ideas behind Attributes

Attributes are metadata about constructs in your program.

Some predefined attributes have magical special meanings to the compiler, such as Conditional. Some other attributes have special meanings to the linker, such as DllImport.

Attributes that you define yourself have no special meaning to the system. For example, there is currently no way to define an attribute that automatically causes a complex function to cache return values. Later versions of C# could allow attributes to be used in this way, but I would guess it''s unlikely to happen in the near future.

So what use are custom attributes? You can use reflection to extract custom attributes from constructs. The C# manual gives an example of a HelpAttribute attribute that specifies where to find help about a construct. If you were writing a C# IDE, you could use that attribute to show context sensitive help.

Another possible use would be a TransientAttribute class which you could attach to fields which should not be serialised (such as fields whose values can be determined from other fields, or fields that you don''t want to store on disk, such as passwords). This might be useful if you wanted to write the state of a game to disk, but didn''t want to have to write serialisation methods for each class.

quote:
and reflection

Reflection allows you to examine the structure of classes, fields, methods and other constructs of the C# program. Note that you can''t use reflection to examine the statements and expressions of method bodies -- that information is not available after compilation.

quote:
in C#?

Can someone point me out what it is, what the use of it is and the finer details? I read "A Programmer''s Introduction to C#" but I can''t really grasp the concept from there.

The same goes for interfaces

Loosely, an interface defines a kind of class. Whilst a class contains definitions of fields and methods, an interface contains only declarations of fields and methods.

When a class derives from an interface, it is essentially saying: I provide the methods and fields declared by this interface.

Deriving from a class is slightly different: The subclass might not provide the methods and fields defined in a superclass, because it may just use the superclass''s versions of those.

<Aside>
IMO, C# gets interfaces wrong. Interfaces should define a kind of class, but classes should automatically be considered implementations of the interface if they provide the fields and methods that the interface declares. However, this does mean that some classes could appear to implement an interface whilst they actually don''t, which could be bad.

A good middle ground which wouldn''t break existing code could be to allow ''retroactive abstraction'' -- allowing statements of the form class Foo: IBar; to indicate that the previously defined class Foo implements IBar.
</Aside>

quote:
and delegates.

Delegates are like function pointers, except that they are pointers to methods bound to a particular instance. Essentially, when a delegate for theInstance.theMethod is called, the method is called on that particular instance. It''s useful if you want a particular method to be called when something happens -- register the delegate with some source of notifications, and it''ll invoke the delegate when it happens.

quote:
What''s the idea behind those?

Toolmaker

That makes sense . I don''t think I am going to use reflection/attributes in the near future, but having some basic knowledge is usefull.

So, interfaces are more or less abstract classes(Or in C++ speak, pure virtual classes) which forces the implementing class to override them.

One thing I don''t get about it, why just don''t use abstract classes in this case? Or am I getting it wrong here? Or do you use interfaces as a generic interface? E.g, some functions wants a reference of ICustomArray for handling(For instance, foreach) data in it. Wether ICustomArray is hardcoded, linked listed, stored inside a database or uses the surface of the moon to get it''s data isn''t of importance. All have to do it implement the interface, create an instance of CMyClass and cast it back to ICustomArray and then pass this to the function? But doesn''t a base class work there too?

I am aware foreach uses IEnumberable, but it was as an example.

Toolmaker


My site
/* -Earth is 98% full. Please delete anybody you can.*/

quote:Original post by Toolmaker
So, interfaces are more or less abstract classes(Or in C++ speak, pure virtual classes) which forces the implementing class to override them.

More or less. Of course, as in C++, you don''t have to implement a particular method, but you end up with a class you can''t construct.

quote:
One thing I don''t get about it, why just don''t use abstract classes in this case? Or am I getting it wrong here? Or do you use interfaces as a generic interface? E.g, some functions wants a reference of ICustomArray for handling(For instance, foreach) data in it. Wether ICustomArray is hardcoded, linked listed, stored inside a database or uses the surface of the moon to get it''s data isn''t of importance. All have to do it implement the interface, create an instance of CMyClass and cast it back to ICustomArray and then pass this to the function? But doesn''t a base class work there too?

Yes. However, sometimes you need to have a class that supports more than one distinct set of features. For example, a database might have a RecordSet class that needs to support certain features common to all database classes (for example, an Owner property), but also needs to act as a Container, since it contains Records.

C# doesn''t allow you to subclass both Container and DatabaseObject -- you can only inherit from one class, even if the other classes are entirely abstract. Thus, interfaces are used as a replacement for abstract classes.

There is, in principle, no difference between interfaces and abstract classes. The difference is only there because you aren''t allowed to inherit from more than one class.