6

I recently just started looking at Func in C#, and as far as I can tell, they pretty much are the same as methods, which is fair enough. However, I was wondering if there is any point in using them, because as far as I can tell they seem to just be a slightly less version of methods. Consider the following:

Func<int,int> SquareTheNumber = x => { return x * x };

public int ReturnTheSquare (int x)
{
    return x * x;
}

So is there any instance where a Func should be used over a method?

|improve this question
  • method are bind to a class, where it exists a this which refer to the instance of the current object. This is the main difference in every language between function and method. Note that a static method don't have a this since the goal of static method is to be used without having instanting the class – Walfrat May 11 '16 at 9:00
  • @Walfrat: IMO, the main difference between a function and method in C♯, and also Java and Scala, for example, is that function are objects and methods aren't, which, seeing as we are talking about an object-oriented language, is a much more important distinction than whether they take an invisible argument. – Jörg W Mittag May 11 '16 at 11:14
  • @JörgWMittag Function doesn't exists in java outside of a class, so function doesn't exists at all in Java. The nearest thing is anonymous class that implements an interface with only one method. Furthermore, Method are objects in Java (see reflection). In C/C++, you can pass either a function or a method as an argument. Those points are totally language dependant. Seeing this link stackoverflow.com/questions/2202381/…, method seems to be an objet in C# too, so you could pass them as parameter too. SO i think you're statement is incomplete – Walfrat May 11 '16 at 11:23
  • A Func (and any other delegate) can be defined inside a method, so that it has local scope. But maybe, in C# 7, we can define inline methods as well. – Dennis_E May 13 '16 at 7:45
14

A Func is just a special kind of (well a family of, really) delegate. Naturally, C# would be turing-complete even without them, so of course nobody "needs" them, it's just that they make a lot of things A LOT simpler design- and syntax-wise.

They take on a similar role to function pointers in languages like C. It's basically a way for you to decouple yourself from a specific method, and instead depend on a polymorphic class ("class" in a non-OOP sense) of methods.

One pretty simple example when they are useful is the map method in the IEnumerable<T> functor (named Select in C#):

public static IEnumerable<TResult> Select<T, TResult>(this IEnumerable<T> xs, Func<T, TResult> f)
{
    foreach (var x in xs) yield return f(x);
}

This can now be called via new[] {1,2,3}.Select(x => x*2) instead of defining som one-method interface and creating a whole class just for multiplying a number by 2.

Explicitly naming and placing each small lambda in a class in a namespace would just bloat things and add no clarity.

|improve this answer
  • 1
    Consider changing the name "Double" to "MultiplyByTwo" to avoid confusion with the floating point type – Caleth May 11 '16 at 9:52
  • 1
    Whoops, my mistake, I'll fix it – sara May 11 '16 at 13:38
5

I recently just started looking at Func in C#, and as far as I can tell, they pretty much are the same as methods, which is fair enough.

Funcs (and Actions) are objects. Methods aren't.

In an object-oriented language, where everything you do is done by manipulating, constructing, passing, returning, and storing objects, something not being an object is an extremely severe restriction. So, no, they are not "pretty much the same", they are in fact fundamentally different. In some sense, they could not be more different.

  • You can pass a Func as an argument. You can't do that with a method, because you can only pass objects as arguments and methods aren't objects.
  • You can return a Func. You can't do that with a method, because you can only return objects and methods aren't objects.
  • You can assign a Func to a variable. You can't do that with a method, because you can only assign objects to variables and methods aren't objects.
  • You can construct a Func at runtime. You can't do that with a method.

[I'm ignoring reflection here. I'm also ignoring automatic conversion from method group references to delegates.]

|improve this answer
  • 3
    Eh... The fact that you're ignoring the automatic conversion here makes this answer largely irrelevant to the question and its tags (the .Net framework). While you're correct, the framework makes this difference completely invisible to Average Josephine Developer. – RubberDuck May 11 '16 at 13:46
  • 4
    I'm with @RubberDuck here. Your answer may be technically correct, as far as it goes. However, the fact that you ignore delegates, and the syntactic sugar around implicitly converting between method groups and delegates, make your answer unhelpful. So downvoted. – David Arno May 11 '16 at 13:59
  • "You can assign a Func to a variable. You can't do that with a method," Wrong, a method that returns a value could be assigned to a variable. – usefulBee Jun 28 '17 at 17:43
  • 3
    @usefulBee: Not in C♯. The question is explicitly asking about C♯ and in C♯, you can only assign values to variables, and methods aren't values, therefore you cannot assign a method to a variable. Whether or not the method returns a value is completely irrelevant, it only influences what type the hypothetical variable would have, if you could assign a method to it. But since you can't do that, the distinction is irrelevant. I don't see why this is so controversial. This is the way it works in most OO languages: methods belong to objects but aren't objects themselves. – Jörg W Mittag Jun 28 '17 at 19:54

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.