Are .net delegates real objects?

I have been working for some years in C# and one thing always bugs me. Delegates. They have no state, they are pointers to object methods, and the only way to go when dealing with threads or any other type of parallel programming technique that .net has to offer.

My main concern is that when programming in an object oriented style, the fact that delegates break the paradigm by breaking the notion that if you go Object Oriented then the design phase using UML and CRC should map to the language that you use.

So as the title asks, are delegates real objects or a programming anomaly, something that is required to be done outside the scope of Object Oriented Design.

Is it possible therefore for an object to be an object if it has no state and can a delegate be modelled in UML?

A well-know开发者_Python百科n person once gave a public lecture on astronomy. He described how the earth orbits around the sun and how the sun, in turn, orbits around the center of a vast collection of stars called our galaxy. At the end of the lecture, a little old lady at the back of the room got up and said: "What you have told us is rubbish. The world is really a flat plate supported on the back of a giant tortoise." The scientist gave a superior smile before replying, "What is the tortoise standing on?" "You're very clever, young man, very clever", said the old lady. "But it's turtles all the way down! ---- Stephen Hawkins

I think this relates very well to objects and the fundamental types they sit upon. Can you really say its objects all the way down?

---

They're real objects.

When you're modeling with UML it's common to use interfaces. Do they have state? No. Are they any less object-oriented? Of course not.

Of course a delegate can be modeled in UML.

I think they represent a more functional approach, because they are functions that are first class objects. That might concern you, but it doesn't detract from the fact that they are indeed objects.

---

It's become clear that this point isn't going to get across without somebody wielding the closure hammer. No, not the "close this question" hammer.

Action @ICanHazState()
{
    int callcount = 0;
    Action retval = delegate {
       System.MessageBox("I haz bin calld " + callcount.ToString() + " tims b4");
       if (++callcount > 5) throw new InvalidOperationException("Call limit exceeded.  Kaboom!");
    };
    return retval;
}

Complete compilable example here

More complex example (requires C# 4 e.g. Visual Studio 2010)

---

From wikipedia (Object (computer science): In the domain of object-oriented programming an object is usually taken to mean a compilation of attributes (object elements) and behaviors (methods or subroutines) encapsulating an entity. Delegates all are subclassed from the Delegate class in .Net. The Delegate class certainly has attributes (i.e. properties): Method & Target. The class also has behaviors (methods): Combine, CreateDelegate among others.

Delegates are not pointers, as a simple pointer to a method could not encapsulate the 'this' pointer, which delegates do. As Gabe pointed out, delegates also have state, they could be empty (in which case invoking them does nothing) or they could have one or more methods in their list.

Having satisfied the criteria for an object, they are objects.

Q.E.D.

---

Yes. They don't break the object oriented paradigm. They just embrace and extend it ;)

---

Define "object."

Your definition seems to be that to be an object, 'thing' must have mutable state and be inheritable.

By that definition, delegates are not objects. However, I consider that definition to be extremely, extremely limited. Entire categories of 'objects' in real-world applications fail by that definition. Functors, to start with. Many decorator types would also fail by that definition, as well as things like filter objects.

If you go back to Smalltalk, for instance, both true and false are objects. By your definition, they would not be.