Develop Reference

use delegate (or other) to do the same thing as lambda operator [duplicate]

I'm new to SO and programming and learning day by day with bits and pieces of tech (C#) jargons.
After Googling for a while, below is what I've researched about methods
A Method is a block of statements, which serves for code reusability
& it also supports overloading with different SIGNATURE....for ex:
drawShape(2pts), drawShape(3pts) etc...
An Anonymous method is one with block of statements, but no
name....(as its premature to ask, in wt situation we come across
anonymous method...any articles, samples ...)
Named method: Here's a link but at the end i didn't get what Named Method actually is...
Can anyone explain what a "Named" method is, and where do we use anonymous method?

A named method is a method you can call by its name (e.g. it is a function that has a name). For example, you have defined a function to add two numbers:
int f(int x, int y)
{
return x+y;
}
You would call this method by its name like so: f(1, 2);.
Anonymous method is a method that is passed as an argument to a function without the need for its name. These methods can be constructed at runtime or evaluated from a lambda expression at compile time.
These methods are often used in LINQ queries, for example:
int maxSmallerThan10 = array.Where(x => x < 10).Max();
The expression x => x < 10 is called a lambda expression and its result is an anonymous function that will be run by the method Where.
If you are a beginner, I would suggest you first read about more basic stuff. Check out the following links:
http://www.completecsharptutorial.com/
http://www.csharp-station.com/tutorial.aspx
http://www.homeandlearn.co.uk/csharp/csharp.html

Let's start from a simple method.
void MyMethod()
{
Console.WriteLine("Inside MyMethod"); //Write to output
}
The above method is a named-method which just writes Inside MyMethod to the output window.
Anonymous methods are some methods used in some special scenarios (when using delegates) where the method definition is usually smaller where you don't specify the name of the method.
For example, (delegate) => { Console.WriteLine("Inside Mymethod");}
Just start writing some simple programs and in the due course, when you use delegates or some advanced concepts, you will yourself learn. :)

Explanation by Analogy
Normally when we tell stories we refer to people by name:
"Freddie"
"Who's Freddie?"
"You know, Freddie, Freddie from Sales - the male guy with the red hair, who burned the building down...?"
In reality nobody cares who the person is, department he works etc. it's not like we'll refer to him every again. We want to be able to say: "Some guy burned down our building". All the other stuff (hair color, name etc.) is irrelevant and/or can be inferred.
What does this have to do with c#?
Typically in c# you would have to define a method if you want to use it: you must tell the compiler (typically):
what it is called,
and what goes into it (parameters + their types),
as well as what should come out (return type),
and whether it is something you can do in the privacy of your home or whether you can do it in public. (scope)
When you do that with methods, you are basically using named methods. But writing them out: that's a lot of effort. Especially if all of that can be inferred and you're never going to use it again.
That's basically where anonymous methods come in. It's like a disposable method - something quick and dirty - it reduces the amount you have to type in. That's basically the purpose of them.

Anonymous methods or anonymous functions, what seems to be the same, basically are delegates. As the link you point out: http://msdn.microsoft.com/en-us/library/bb882516.aspx describes, anonymous methods provide a simplified way to pass method to be executed by another method. Like a callback.
Another way to see it, is think about lambda expressions.
A named by the contrast is any common method.

From MSDN:
A delegate can be associated with a named method. When you instantiate a delegate by using a named method, the method is passed as a parameter. This is called using a named method. Delegates constructed with a named method can encapsulate either a static method or an instance method. Named methods are the only way to instantiate a delegate in earlier versions of C#. However, in a situation where creating a new method is unwanted overhead, C# enables you to instantiate a delegate and immediately specify a code block that the delegate will process when it is called. The block can contain either a lambda expression or an anonymous method.
and
In versions of C# before 2.0, the only way to declare a delegate was to use named methods. C# 2.0 introduced anonymous methods and in C# 3.0 and later, lambda expressions supersede anonymous methods as the preferred way to write inline code. However, the information about anonymous methods in this topic also applies to lambda expressions. There is one case in which an anonymous method provides functionality not found in lambda expressions. Anonymous methods enable you to omit the parameter list. This means that an anonymous method can be converted to delegates with a variety of signatures. This is not possible with lambda expressions. For more information specifically about lambda expressions, see Lambda Expressions (C# Programming Guide). Creating anonymous methods is essentially a way to pass a code block as a delegate parameter. By using anonymous methods, you reduce the coding overhead in instantiating delegates because you do not have to create a separate method.
So in answer to your question about when to use anonymous methods, then MSDN says: in a situation where creating a new method is unwanted overhead.
In my experience it's more down to a question of code reuse and readability.
Links:
http://msdn.microsoft.com/en-us/library/98dc08ac.aspx
http://msdn.microsoft.com/en-us/library/0yw3tz5k.aspx
Hope that helps

Method Overloading with different return type [duplicate]

This question already has answers here:
Function overloading by return type?
(14 answers)
Closed 9 years ago.
I am want to dig in that whether it is an ambiguity or an extra feature that is provided:
public class Foo
{
public int Bar(){
//code
}
public string Bar(int a){
//code
}
}
Any one having any experience with this, overloading on return type with different parameters should be a bad practice, is it?
But if the overloading was done on the basis of return type then why this is not working for.
public class Foo
{
public int Bar(int a){
//code
}
public string Bar(int a){
//code
}
}
As it will be unable to decide which function to call 1st or second, if we call obj.Bar(); , it should end in error do any one have any idea about it why it allows first code snippet to run.

The C# specification (section 10.6) states that overloaded members may not differ by only return type and as per http://msdn.microsoft.com/en-us/library/ms229029.aspx
As per your question regarding creating parameters simply to support differing return types? I personally believe that is a terrible solution to the problem. Code maintenance will become difficult and unused parameters are a definite code smell. Does the method really need to be overloaded in that case? Or does it belong in that class? Should something else be created to convert from one return type to another? All things you should ask to derive a more idiomatic solution.

This is logically impossible. Consider the following call:
object o = Bar(42);
or even
var o = Bar(42);
How would the compiler know which method to call?
Edit:
Now that I understand what you're actually asking, I think overloading by meaningless parameters is bad practice, and diminished readability, it is much preferable to distinguish by method name:
string BarToStr()
{
}
int BarToInt()
{
}

Others already explained the situation. I only would like to add this: You can do what you have in mind by using a generic type parameter:
public T Bar<T>(int a) {
// code
}
And call it like this:
int i = Bar<int>(42);
string s = Bar<string>(42);
The problem is that it is often difficult to do something meaningful with a generic type, e.g. you cannot apply arithmetic operations to it (at least before C# 11). Sometimes generic type constraints can help.
Starting with C# 11 you can declare abstract static interface members:
public interface IFactory<T> where T : IFactory<T>
{
static abstract T Create(int input);
}
Applied in the Bar method:
public T Bar<T>(int a) where T : IFactory<T> {
return T.Create(a);
}

You can not overload the function by differing only their return type.
You can only overload the function in the following ways
Parameter types
Number of parameters
Order of the parameters declared in the method
You can not come to know which function is actually called (if it was possible).
One more thing I would like to add is
function overloading is providing a function with the same name, but with a different signature. but the return type of a method is not considered as a part of the method's signature.
So this is another way to understand why method overloading can't be done only by return type.

any one having any experience with this, overloading on return type
with different parameters should be a bad practice, is it.
I'm taking that to mean - "is it bad practice to use differing parameter combinations to facilitate different return types" - if that is indeed the question, then just imagine someone else coming across this code in a few months time - effectively "dummy" parameters to determine return type...it would be quite hard to understand what's going on.
Edit - as ChrisLava points out "the way around this is to have better names for each function (instead of overloading). Names that have clear meaning within the application. There is no reason why Bar should return an int and a string. I could see just calling ToString() on the int"

C# does not allow it.
C# on the other hand does not support method resolution based on the
return type; this was a conscious decision by the language designers
not to expose the feature of the CLR which allows it. There's no
technical reason why they couldn't have done, they just felt it better
not to. Because the return value is not used for method selection a
C# method signature does not include it.

Check this.. You can't have method with same signature and just different return type. Recommended is mentioned in this question.
C# Overload return type - recommended approach

Your code will result in a Compiler Error. You can not have a Method of the same name with the same parameters and a different return type, the caller would not know which Method to call (will not be able to resolve the location in Memory of the Method to call, why the Compiler would not allow it). Your alternative would be to return an Object and Cast it based on what the Caller knows. Even then, that appears to be Bad design.
This will Work (meaning Compile), but still bad design.
public class Foo
{
public object Bar(int a)
{
return a;
}
}

You can't create method with same name, same number and types of parameters.
For more details refer this link.

Should I use Func<T> in place of a private method?

I'm posting it here and not code review because I want to know if the executing program can behave differently because of this (possibly something subtle).
Is a private method:
private int Foo()
{
return Bar().Bat();
}
Any different from a private Func?
private Func<int> Foo = () => Bar().Bat();
The only reason I'm doing it is to make the code more compact.

There is not much difference, but
you define templated type int (possibly type safe, even if it's not visible in current code provided)
you can use that function like a parameter to pass to another function, that you can do in the firts case too, naturally, but in first case you would need to declare a delegate type.
third is more compact, but the first is more readable, imo, so if you do not need some "functional" stuff, I would go for the first choice.

Funcs are delegates and encapsulates any methods that has equal signatur og Func. for layering I recomment that you use Private Methods

With the Func, you are actually saving a reference to an anonymous method. The compiler creates a named method out of it, and what you're doing is like saving an extra reference to it.
That being not too big of a deal, there isn't much of a difference, except the standard is naming the method. It is also more logical and readable.

Func<T, TResult> delegate real world uses

I've recently been playing around with the delegate Func<T, TResult> and creating methods that return different instances Func<T, TResult> containing lambda but what I have struggled to come up with is any good real world ideas of why one might want to return (or even create such an instance).
There is an example on MSDN where they do the following...
Func<string, string> convertMethod = UppercaseString;
private static string UppercaseString(string inputString)
{
return inputString.ToUpper();
}
And although it looks pretty and is an interesting concept I fail to see what advantages such code provides.
So could someone here please provide any real world examples where they have had to use Func<T, TResult> and in general why one might want to use this delegate?

If what you're asking, really, is why we have delegates in general:
If you've ever consumed an event, you've used a delegate
If you've ever used LINQ, you've used a delegate (technically, with an IQueryable provider you've used an expression, but for LINQ-to-Objects you've used a delegate)
Delegates provide a way of injecting your own behavior into another object. The most common usage is with events. An object exposes an event and you provide a function (anonymous or not) that gets called when that event fires.
If you're asking why we have the Func<T, TResult> (and similar) delegate, then there are two main reasons:
People were having to declare their own simple delegate types when they needed a particular delegate in their code. While the Action<> and Func<> delegates can't cover all cases, they are simple to provide and cover many of the cases where custom delegates were needed.
More importantly, the Func<T, TResult> delegate is used extensively in LINQ-to-Objects to define predicates. More specifically, Func<T, bool>. This allows you to define a predicate that takes a strongly-typed member of an IEnumerable<T> and returns a boolean by using either a lambda or ordinary function, then pass that predicate to LINQ-to-Objects.

You would use it a lot in LINQ. So, for example, to double all the numbers in a list:
myList.Select(x => x * 2);
That's a Func<TIn, TOut>. It's quite useful when creating concise code. A real-world example is in one of the many tower-defence games I made, I calculated the closest enemy to the tower using one line:
enemies.Select(x => tower.Location.DistanceTo(x.Location)).OrderBy(x => x).FirstOrDefault();

I think a great example is lazy initialization.
var value = new Lazy<int>(() => ExpensiveOperation()); // Takes Func<T>

The canonical example of a need for a function pointer is for a comparison function to pass to a sort routine. In order to have different sort keys, you create a lambda for the comparison function, and pass that to the sort function.
Or for a simple real-world example:
IEnumerable<Person> FindByLastName(string lastName)
{
return Customers.Where(cust => cust.LastName == lastName);
}
In this example, cust => cust.LastName == lastName is not just a lambda, but it creates a closure by capturing the lastName parameter. In othe words, it creates a function, which will be different every time FindByLastName is called.

The Func<T> delegate (and other overloads) give you new ways for writing abstractions in C#. To demonstrate some of the options, here are a couple of C# langauge constructs that could be written using delegates instead:
Thread.Lock(obj, () => {
// Safely access 'obj' here
});
Enumerable.ForEach(collection, element => {
// Process 'element'
});
Exceptions.Try(() => {
// Try block
}).With((IOException e) => {
// Handle IO exceptions
});
These are quite primitive, so it is good to have a language construct for them. However, it demonstrates that Func and lambda expressions add quite a lot of expressive power. It makes it possible to write new constructs such as parallel loop (using .NET 4.0):
Parallel.ForEach(collection, element => {
// Process 'element'
});

First of all, Func<T> is not a class, it's a delegate.
Basically, you can use it whenever you need a method argument or a property of delegate type if you don't want to declare your own delegate for that.

One great use of Funct<T>, besides the fact that it is embedded in many frameworks such as LINQ, Mocking Tools, and Dependency Injection containers is to use it to create a delegate based factory.

Recently, I wanted the external program calling my method to be able to modify the way it behaves.
My method in itself simply converts a file from XLS to XML. But it was necessary to allow the calling code to specify if needed an arbitrary number of transformations which should apply to each xls cell before being writing as a xml tag. For example : convert the "," decimal separator to ".", suppress the thousand separator, and so on (the transformations were all string replacements).
Then the caller code just had to add an arbitrary number of entries in a dictionary where the key is the pattern and the value is the replacement string for this pattern. My method loops over the dictionary and creates a new Func<string,string> for each entry. Then for each cell the Func<string,string> are applied in sequence.

Good practice to create extension methods that apply to System.Object?

I'm wondering whether I should create extension methods that apply on the object level or whether they should be located at a lower point in the class hierarchy. What I mean is something along the lines of:
public static string SafeToString(this Object o) {
if (o == null || o is System.DBNull)
return "";
else {
if (o is string)
return (string)o;
else
return "";
}
}
public static int SafeToInt(this Object o) {
if (o == null || o is System.DBNull)
return 0;
else {
if (o.IsNumeric())
return Convert.ToInt32(o);
else
return 0;
}
}
//same for double.. etc
I wrote those methods since I have to deal a lot with database data (From the OleDbDataReader) that can be null (shouldn't, though) since the underlying database is unfortunately very liberal with columns that may be null. And to make my life a little easier, I came up with those extension methods.
What I'd like to know is whether this is good style, acceptable style or bad style. I kinda have my worries about it since it kinda "pollutes" the Object-class.
Thank you in advance & Best Regards :)
Christian
P.S. I didn't tag it as "subjective" intentionally.

No, that is not good practice. You want to apply extension methods at the lowest possible point. I believe there a time and a place for (almost) everything, but extension methods System.Object would almost never be appropriate. You should be able to apply extension methods such as this much further down the inheritance stack. Otherwise it will clutter your intellisense and probably end up being used/depended-upon incorrectly by other developers.
However, extension methods for data objects for dealing with Null values is a very good use of extension methods. Consider putting them right on you OleDbDataReader. I have a generic extension method called ValueOrDefault that . . . well, I'll just show it to you:
<Extension()> _
Public Function ValueOrDefault(Of T)(ByVal r As DataRow, ByVal fieldName As String) As T
If r.IsNull(fieldName) Then
If GetType(T) Is GetType(String) Then
Return CType(CType("", Object), T)
Else
Return Nothing
End If
Else
Return CType(r.Item(fieldName), T)
End If
End Function
That's VB, but you get the picture. This sucker saves me a ton of time and really makes for clean code when reading out of a datarow. You are on the right track, but your sense of spell is correct: you have the extension methods too high.
Putting the extension methods into a separate namespace is better than nothing (this is a perfectly valid use of namespaces; Linq uses this), but you shouldn't have to. To make these methods apply to various db objects, apply the extension methods to IDataRecord.

Extension method pollution of System.Object can be quite annoying in the general case, but you can place these extension methods in a separate namespace so that developers must actively opt in to use those methods.
If you couple this with code that follows the Single Responsibility Principle, you should only have to import this namespace in relatively few classes.
Under such circumstances, such extension methods may be acceptable.

An excerpt from the book "Framework design guidelines"
Avoid defining extension methods on
System.Object, unless absolutely
necessary. When doing so, be aware
that VB users will not be able to use
thus-defined extension methods and, as
such, they will not be able to take
advantage of usability/syntax benefits
that come with extension methods.
This is because, in VB, declaring a
variable as object forces all method
invocations on it to be late bound –
while bindings to extension methods
are compile-time determined (early
bound). For example:
public static class SomeExtensions{
static void Foo(this object o){…} } … Object o = … o.Foo();
In this example, the call to Foo will fail in
VB. Instead, the VB syntax should
simply be: SomeExtensions.Foo(o)
Note that the guideline applies to
other languages where the same binding
behavior is present, or where
extension methods are not supported

The Framework Design Guidelines advice you not to do this. However, these guidelines are especially for frameworks, so if you find it very useful in your (line of) business application, please do so.
But please be aware that adding these extension methods on object might clutter IntelliSense and might confuse other developers. They might not expect to see those methods. In this case, just use old fashion static methods :-)
One thing I personally find troubling about sprinkling extension methods everywhere it that my CPU (my brain) is trained to find possible `NullReferenceException`s. Because an extension method looks like an instance method, my brain often receives a `PossibleUseOfNullObject` interrupt by the *source code parser* when reading such code. In that case I have to analyze whether a `NullReferenceException` can actually occur or not. This makes reading through the code much harder, because I'm interrupted more often.
For this reason I’m very conservative about using extension methods. But this doesn’t mean I don’t think they’re useful. Hell no! I've even written a library for precondition validation that uses extension methods extensively. I even initially defined extension methods on System.Object when I started writing that library. However, because this is a reusable library and is used by VB developers I decided to remove these extension methods on System.Object.

Perhaps consider adding the extension methods to the IDataRecord interface? (which your OleDbDataReader implements)
public static class DataRecordExtensions
{
public static string GetStringSafely(this IDataRecord record, int index)
{
if (record.IsDBNull(index))
return string.Empty;
return record.GetString(index);
}
public static Guid GetGuidSafely(this IDataRecord record, int index)
{
if (record.IsDBNull(index))
return default(Guid);
return record.GetGuid(index);
}
public static DateTime GetDateTimeSafely(this IDataRecord record, int index)
{
if (record.IsDBNull(index))
return default(DateTime);
return record.GetDateTime(index);
}
}

I know its not best practice, but for my projects I like to include this extension for converting data types, i find it much easier than the Convert class..
public static T ChangeType<T>(this object obj) where T : new()
{
try
{
Type type = typeof(T);
return (T)Convert.ChangeType(obj, type);
}
catch
{
return new T();
}
}
It'll show up in every object but i usually just use this one instead of having a list of extensions..
Works like this...
int i = "32".ChangeType<int>();
bool success = "true".ChangeType<bool>();

In addition to the reasons already mentioned, it should be borne in mind that extension methods on System.Object are not supported in VB (as long as the variable is statically typed as System.Object and if the variable is not statically typed as Object you should better extend another more specific type).
The reason for this limitation is backward compatibility. See this question for further details.