[Show all top banners]

cp21
Replies to this thread:

More by cp21
What people are reading
Subscribers
:: Subscribe
Back to: Computer/IT Refresh page to view new replies
 Method Overloading
[VIEWED 7050 TIMES]
SAVE! for ease of future access.
Posted on 10-27-15 1:44 PM     Reply [Subscribe]
Login in to Rate this Post:     0       ?    
 

Question for developers out there:

Method Overloading ko benefits k ho ani yo concept k ho?
 
Posted on 10-27-15 2:20 PM     [Snapshot: 31]     Reply [Subscribe]
Login in to Rate this Post:     0       ?    
 

Yo chandra prakash.  Since you deleted my post, I'm editing this one.  Why don't you delete this post too?
Last edited: 28-Oct-15 03:52 AM

 
Posted on 10-28-15 1:24 AM     [Snapshot: 176]     Reply [Subscribe]
Login in to Rate this Post:     2       ?     Liked by
 

अब म भाइ भन्छु है चन्द्र प्रकाश ! अब भाइ त भनि हाले, गालि न गर्नु नि ! जे भए पनि नेपाली हो नि, ठुला ले साना लाइ माया अनि साना ले ठुला लाइ आदर संस्कार त गर्ने पर्यो है, त्यो त हामि नेपाली को चिनारी नै हो !
भाइ ले मुख छाड्छउ कि जस्तो लागेर यत्ति भूमिका बाधेको किन कि भाइ को एक दुइ कमेन्ट पढेको थिए, आफु लाइ नै लाज लाग्यो त्यो पढेर ! फेरी हिरो किन पल्टिएको भन्ने न सोच है त भाइ.. म पनि तिमि अहिले चढेको नाउ चढेर यहाँ आइ पुगेको हो, तिमि ले हिड्न खोज्दै गरेको बाटो हिडेर यहाँ आइपुगेको हो ! हिरो पट्टक्कै हुन खोजेको हैन नि ! प्लिज फोर्गिव मि इफ आइ एम रिउड!
अब प्रस्न को जवाफ दिनु भन्दा पनि पहिला, भाइ लाइ एउटा सुझाब दिन्छु, हुन त हामि नेपाली लाइ सुझाब त पटक्कै पच्दैन, पक्का गालि भरिएको जवाफ पाउछु होला ! तर पनि अर्ति भनेको घर्ति को पनि लिनु पर्छ ! मलाई एउटा अत्ति न जान्ने अनि अत्ति अनपढ जस्तै ठानेर मेरो सुझाब तुरुन्त आफ्नो जीवन मा प्रयोग गर है त भाइ !

PLEASE STUDY !!! PLEASE DO LABOR BY YOURSELF !!! STOP MAKING YOURSELF AS A JOKE !!! IF YOU NEED A TRAINER , WE CAN HELP YOU FIND A GOOD ONE !!! YES !!! YOU MIGHT HAVE TO PAY FOR THE TRAINING !!! BUT I AM PRETTY SURE SOMEBODY WILL SUGGEST YOU A GOOD TRAINER !!!
YOU NEED A TRAINER NOW !!! AND DEFINITELY A POSITIVE ATTITUDE AND HARD LABOR!!!

PLEASE READ THIS !!! 

ALL COPIED FROM GOOGLE !!!

Method Overloading is a feature that allows a class to have two or more methods having same name, if their argument lists are different. In the last tutorial we discussed constructor overloading that allows a class to have more than one constructors having different argument lists.

Overloading

Just as a reminder, overloading is what happens when you have two methods with the same name but different signatures. At compile time, the compiler works out which one it's going to call, based on the compile time types of the arguments and the target of the method call. (I'm assuming you're not using dynamic here, which complicates things somewhat.)

Now, things can get a little bit confusing sometimes when it comes to resolving overloads... especially as things can change between versions. This article will point out some of the gotchas you might run into... but I'm not going to claim it's an authoritative guide to how overloading is performed. For that, read the specification - but be aware that you may get lost in a fairly complex topic. Overloading interacts with things like type inference and implicit conversions (including lambda expressions, anonymous methods and method groups, all of which can become tricky). All specification references are from the C# 4 spec.

This article is also not going to go into the design choices of when it's appropriate and when it's not. I'll give a little advice about when it might be potentially very confusing to use overloading, but anything beyond that will have to wait for another time. I will say that in general I believe overloading should be used for convenience, usually with all overloads ending up calling one "master" method. That's not always the case, but I believe it's the most common scenario which is appropriate.

In each example, I'll give a short program which will declare some methods and call one - and then I'll explain what gets called in which version of C#, and why. As I'm not trying to focus on the design decisions but merely the mechanical choices the C# compiler makes, I haven't tried to make the examples do anything realistic, or even given them realistic names: the overloaded method is always Foo, and it will always just print its own signature. Of course the action taken is irrelevant, but it makes it easier to grab the code and experiment with it if you want to.

Simple cases

Let's start off with a couple of really simple cases, just to get into the swing of things. First, the trivial case where only one overload is possible at all.

using System;

class Test
{
    static void Foo(int x)
    {
        Console.WriteLine("Foo(int x)");
    }
    
    static void Foo(string y)
    {
        Console.WriteLine("Foo(string y)");
    }
    
    static void Main()
    {
        Foo("text");
    }
}

This will print Foo(string y) - there's no implicit string conversion from string (the type of the argument here, "text") to int, so the first method isn't an applicable function member in spec terminology (section 7.5.3.1). Overloading ignores any methods which can't be right when it's deciding which one to call.

Let's actually give the compiler something to think about this time...

using System;

class Test
{
    static void Foo(int x)
    {
        Console.WriteLine("Foo(int x)");
    }

    static void Foo(double y)
    {
        Console.WriteLine("Foo(double y)");
    }
    
    static void Main()
    {
        Foo(10);
    }
}

This time, Foo(int x) will be printed. Both methods are applicable - if we removed the method taking an `int`, the method taking a `double` would be called instead. The compiler decides which one to pick based on the better function member rules (section 7.5.3.2) which look at (amongst other things) what conversions are involved in going from each argument to the corresponding parameter type (int for the first method, double for the second). There are more rules (section 7.5.3.3) to say which conversion is better than the other - in this case, a conversion from an expression of type int to int is better than a conversion from int to double, so the first method "wins".

Multiple parameters

When there are multiple parameters involved, for one method to "beat" another one it has to be at least as good for each parameter, and better for at least one parameter. This is done on a method-by-method comparison: a method doesn't have to be better than all other methods for any single parameter. For example:

using System;

class Test
{
    static void Foo(int x, int y)
    {
        Console.WriteLine("Foo(int x, int y)");
    }

    static void Foo(int x, double y)
    {
        Console.WriteLine("Foo(int x, double y)");
    }

    static void Foo(double x, int y)
    {
        Console.WriteLine("Foo(double x, int y)");
    }
    
    static void Main()
    {
        Foo(5, 10);
    }
}

Here the first method (Foo(int x, int y)) wins because it beats the second method on the second parameter, and the third method on the first parameter.

If no method wins outright, the compiler will report an error:

using System;

class Test
{
    static void Foo(int x, double y)
    {
        Console.WriteLine("Foo(int x, double y)");
    }

    static void Foo(double x, int y)
    {
        Console.WriteLine("Foo(double x, int y)");
    }
    
    static void Main()
    {
        Foo(5, 10);
    }
}

Result:

error CS0121: The call is ambiguous between the following methods or
properties: 'Test.Foo(int, double)' and 'Test.Foo(double, int)'

Inheritance

Inheritance can cause a confusing effect. When the compiler goes looking for instance method overloads, it considers the compile-time class of the "target" of the call, and looks at methods declared there. If it can't find anything suitable, it then looks at the parent class... then the grandparent class, etc. This means that if there are two methods at different levels of the hierarchy, the "deeper" one will be chosen first, even if it isn't a "better function member" for the call. Here's a fairly simple example:

using System;

class Parent
{
    public void Foo(int x)
    {
        Console.WriteLine("Parent.Foo(int x)");
    }   
}
    
class Child : Parent
{
    public void Foo(double y)
    {
        Console.WriteLine("Child.Foo(double y)");
    }
}
    
    
class Test
{
    static void Main()
    {
        Child c = new Child();
        c.Foo(10);
    }
}

The target of the method call is an expression of type Child, so the compiler first looks at the Child class. There's only one method there, and it's applicable (there's an implicit conversion from int to double) so that's the one that gets picked. The compiler doesn't consider the Parent method at all.

The reason for this is to reduce the risk of the brittle base class problem, where the introduction of a new method to a base class could cause problems for consumers of classes derived from it. Eric Lippert has various posts about the brittle base class problem which I can highly recommend.

There's one aspect of this behaviour which is particularly surprising though. What counts as a method being "declared" in a class? It turns out that if you override a base class method in a child class, that doesn't count as declaring it. Let's tweak our example very slightly:

using System;

class Parent
{
    public virtual void Foo(int x)
    {
        Console.WriteLine("Parent.Foo(int x)");
    }   
}
    
class Child : Parent
{
    public override void Foo(int x)
    {
        Console.WriteLine("Child.Foo(int x)");
    }   

    public void Foo(double y)
    {
        Console.WriteLine("Child.Foo(double y)");
    }
}
    
    
class Test
{
    static void Main()
    {
        Child c = new Child();
        c.Foo(10);
    }
}

Now it looks like you're trying to call Child.Foo(int x) in my opinion - but the above code will actually print Child.Foo(double y). The compiler ignores the overriding method in the child.

Given this oddness, my advice would be to avoid overloading across inheritance boundaries... at least with methods where more than one method could be applicable for a given call if you flattened the hierarchy. You'll be glad to hear that the rest of the examples on this page don't use inheritance.

Return types

The return type of a method is not considered to be part of a method's signature (section 3.6), and an overload is determined before the compiler checks whether or not the return type will cause an error in the wider context of the method call. In other words, it's not part of the test for an applicable function member. So for example:

using System;

class Test
{
    static string Foo(int x)
    {
        Console.WriteLine("Foo(int x)");
        return "";
    }
    
    static Guid Foo(double y)
    {
        Console.WriteLine("Foo(double y)");
        return Guid.Empty;
    }

    static void Main()
    {
        Guid guid = Foo(10);
    }
}

Here the overload of string Foo(int x) is chosen and then the compiler works out that it can't assign a string to a variable of type Guid. On its own, the Guid Foo(double y) would be fine, but because the other method was better in terms of argument conversions, it doesn't have a chance.

Optional parameters

Optional parameters, introduced into C# 4, allow a method to declare a default value for some or all of its parameters. The caller can then omit the corresponding arguments if they're happy with the defaults. This affects overload resolution as there may be multiple methods with a different number of parameters which are all applicable. When faced with a choice between a method which requires the compiler to fill in optional parameter values and one which doesn't, if the methods are otherwise "tied" (i.e. normal argument conversion hasn't decided a winner), overload resolution will pick the one where the caller has specified all the arguments explicitly:

using System;

class Test
{
    static void Foo(int x, int y = 5)
    {
        Console.WriteLine("Foo(int x, int y = 5)");
    }
    
    static void Foo(int x)
    {
        Console.WriteLine("Foo(int x)");
    }

    static void Main()
    {
        Foo(10);
    }
}

When considering the first method, the compiler would need to fill in the argument for the y parameter using the default value - whereas the second method doesn't require this. The output is therefore Foo(int x). Note that this is purely a yes/no decision: if two methods both require default values to be filled in, and they're otherwise tied, the compiler will raise an error:

using System;

class Test
{
    static void Foo(int x, int y = 5, int z = 10)
    {
        Console.WriteLine("Foo(int x, int y = 5, int z = 10)");
    }
    
    static void Foo(int x, int y = 5)
    {
        Console.WriteLine("Foo(int x, int y = 5)");
    }

    static void Main()
    {
        Foo(10);
    }
}

This call is ambiguous, because the one argument which has been given is fine for both methods, and both require extra arguments which would be filled in from default values. The fact that the first method would need two arguments to be defaulted and the second would only need one is irrelevant.

Just to be clear, this tie breaking only comes in after the methods have been compared to each other using the pre-C# 4 rules. So, let's change our earlier example a little:

using System;

class Test
{
    static void Foo(int x, int y = 5)
    {
        Console.WriteLine("Foo(int x, int y = 5)");
    }
    
    static void Foo(double x)
    {
        Console.WriteLine("Foo(double x)");
    }

    static void Main()
    {
        Foo(10);
    }
}

This time the method with the optional parameter is used because the int to int conversion is preferred over the int to double one.

Named arguments

Named arguments - another feature introduced in C# 4 - can be used to effectively reduce the set of applicable function members by ruling out ones which have the "wrong" parameter names. Here's a change to an early simple example - all I've done is change the calling code to specify an argument name.

using System;

class Test
{
    static void Foo(int x)
    {
        Console.WriteLine("Foo(int x)");
    }

    static void Foo(double y)
    {
        Console.WriteLine("Foo(double y)");
    }
    
    static void Main()
    {
        Foo(y: 10);
    }
}

This time the first method isn't applicable, because there's no y parameter... so the second method is called and the output is Foo(double y). Obviously this technique only works if the parameters in the methods have different names though.

Introducing a new conversion is a breaking change

Sometimes, the language changes so that a new conversion is available. This is a breaking change, as it means that overloads which were previously not applicable function members can become applicable. It doesn't even have to be a better conversion than any existing overloads - if you have a child class with a method which was previously inapplicable, and it becomes applicable, then that will take precedence over any methods in the base class, as we've already seen.

In C# 2 this occurred with delegates - you could suddenly build a MouseEventHandler instance from a method with a signature of void Foo(object sender, EventArgs e), whereas in C# 1 this wasn't allowed.

In C# 4 there's a more widely-applicable kind of conversion which is now available: generic covariance and contravariance. Here's an example:

using System;
using System.Collections.Generic;

class Test
{
    static void Foo(object x)
    {
        Console.WriteLine("Foo(object x)");
    }
    
    static void Foo(IEnumerable<object> y)
    {
        Console.WriteLine("Foo(IEnumerable<object> y)");
    }

    static void Main()
    {
        List<string> strings = new List<string>();
        Foo(strings);
    }
}

The C# 3 compiler will pick the overload Foo(object x). The C# 4 compiler, when targeting .NET 3.5, will pick the same overload - because IEnumerable<T> isn't covariant in .NET 3.5. The C# 4 compiler, when targeting .NET 4, will pick the Foo(IEnumerable<T>) overload, because the conversion to that is better than the conversion to object. This change occurs with no warnings of any kind.

Conclusion

This article may well expand over time, covering other oddities (such as params parameters, for example) but I hope I've given enough to think about for the moment. Basically, overloading is a minefield with lots of rules which can interact in evil ways. While overloading can certainly be useful, I've found that often it's better to create alternative methods with clear names instead. This is particularly useful for constructors, and can be a helpful technique when you would otherwise want to declare two constructors with identical signatures: create two static methods to create instances instead, both of which call a more definitive constructor (which would potentially have two parameters). The debate about static factory methods vs publicly accessible constructors is one for a different article, however.

Overloading causes a lot less of a problem when only one method will ever be applicable - for example when the parameter types are mutually incompatible (one method taking an int and one taking a string for example) or there are more parameters in one method than another. Even so, use with care: in particular, bear in mind that one type may implement multiple interfaces, and even potentially implement the same generic interface multiple times with different type arguments.

If you find yourself going to the spec to see which of your methods will be called and the methods are under your control then I would strongly advise you to consider renaming some of the methods to reduce the degree of overloading. This advice goes double when it's across an inheritance hierarchy, for reasons outlined earlier.


Method Overloading in Java with examples

Method Overloading is a feature that allows a class to have two or more methods having same name, if their argument lists are different. In the last tutorial we discussed constructor overloading that allows a class to have more than one constructors having different argument lists.

Argument lists could differ in –
1. Number of parameters.
2. Data type of parameters.
3. Sequence of Data type of parameters.

Method overloading is also known as Static Polymorphism.

Points to Note:
1. Static Polymorphism is also known as compile time binding or early binding.
2. Static binding happens at compile time. Method overloading is an example of static binding where binding of method call to its definition happens at Compile time.

Method Overloading examples:

As discussed above, method overloading can be done by having different argument list. Lets see examples of each and every case.

Example 1: Overloading – Different Number of parameters in argument list

When methods name are same but number of arguments are different.

class DisplayOverloading
{
    public void disp(char c)
    {
         System.out.println(c);
    }
    public void disp(char c, int num)  
    {
         System.out.println(c + " "+num);
    }
}
class Sample
{
   public static void main(String args[])
   {
       DisplayOverloading obj = new DisplayOverloading();
       obj.disp('a');
       obj.disp('a',10);
   }
}

Output:

a
a 10

In the above example – method disp() has been overloaded based on the number of arguments – We have two definition of method disp(), one with one argument and another with two arguments.

Example 2: Overloading – Difference in data type of arguments

In this example, method disp() is overloaded based on the data type of arguments – Like example 1 here also, we have two definition of method disp(), one with char argument and another with int argument.

class DisplayOverloading2
{
    public void disp(char c)
    {
        System.out.println(c);
    }
    public void disp(int c)
    {
       System.out.println(c );
    }
}

class Sample2
{
    public static void main(String args[])
    {
        DisplayOverloading2 obj = new DisplayOverloading2();
        obj.disp('a');
        obj.disp(5);
    }
}

Output:

a
5

Example3: Overloading – Sequence of data type of arguments

Here method disp() is overloaded based on sequence of data type of arguments – Both the methods have different sequence of data type in argument list. First method is having argument list as (char, int) and second is having (int, char). Since the sequence is different, the method can be overloaded without any issues.

class DisplayOverloading3
{
   public void disp(char c, int num)
   {
       System.out.println("I’m the first definition of method disp");
   }
   public void disp(int num, char c)
   {
       System.out.println("I’m the second definition of method disp" );
   }
}
class Sample3
{
   public static void main(String args[])
   {
       DisplayOverloading3 obj = new DisplayOverloading3();
       obj.disp('x', 51 );
       obj.disp(52, 'y');
   }
}

Output:

Im the first definition of method disp
Im the second definition of method disp

Lets see few Valid/invalid cases of method overloading

Case 1:

int mymethod(int a, int b, float c)
int mymethod(int var1, int var2, float var3)

Result: Compile time error. Argument lists are exactly same. Both methods are having same number, data types and same sequence of data types in arguments.

Case 2:

int mymethod(int a, int b)
int mymethod(float var1, float var2)

Result: Perfectly fine. Valid case for overloading. Here data types of arguments are different.

Case 3:

int mymethod(int a, int b)
int mymethod(int num)

Result: Perfectly fine. Valid case for overloading. Here number of arguments are different.

Case 4:

float mymethod(int a, float b)
float mymethod(float var1, int var2)

Result: Perfectly fine. Valid case for overloading. Sequence of the data types are different, first method is having (int, float) and second is having (float, int).

Case 5:

int mymethod(int a, int b)
float mymethod(int var1, int var2)

Result: Compile time error. Argument lists are exactly same. Even though return type of methods are different, it is not a valid case. Since return type of method doesn’t matter while overloading a method.

Guess the answers before checking it at the end of programs:
Question 1 – return type, method name and argument list same.

class Demo
{
   public int myMethod(int num1, int num2)
   { 
       System.out.println("First myMethod of class Demo");
       return num1+num2;
   }
   public int myMethod(int var1, int var2)
   {
       System.out.println("Second myMethod of class Demo");
       return var1-var2;
   }
}
class Sample4
{
   public static void main(String args[])
   {
       Demo obj1= new Demo();
       obj1.myMethod(10,10);
       obj1.myMethod(20,12);
   }
}

Answer:
It will throw a compilation error: More than one method with same name and argument list cannot be defined in a same class.

Question 2 – return type is different. Method name & argument list same.

class Demo2
{
   public double myMethod(int num1, int num2)
   {
      System.out.println("First myMethod of class Demo");
      return num1+num2;
   }
   public int myMethod(int var1, int var2)
   {
      System.out.println("Second myMethod of class Demo");
      return var1-var2;
   }
}
class Sample5
{
   public static void main(String args[])
   {
      Demo2 obj2= new Demo2();
      obj2.myMethod(10,10);
      obj2.myMethod(20,12);
   }
}

Answer:
It will throw a compilation error: More than one method with same name and argument list cannot be given in a class even though their return type is different. Method return type doesn’t matter in case of overloading.

In Java, what’s the difference between method overloading and method overriding?


The difference between overriding and overloading in Java is a common source of confusion – but it is fairly easy to understand with the examples we present below. Let’s start the discussion by talking more about method overloading first. Method overloading in Java occurs when two or more methods in the same class have the exact same name but different parameters (remember that method parameters accept values passed into the method). Now, two or more methods with the same name in the same class sounds simple enough to understand. But, what do we mean exactly by differentparameters? Well, let’s consider a very simple example.

Suppose we have a class called TestClass which has two methods, and both methods have the same name. Let’s say that name is “someMethod”. Those two methods would be considered to be “overloaded” if if one or both of these conditions is true:

The conditions for method overloading

1.) The number of parameters is different for the methods.
2.) The parameter types are different (like 
changing a parameter that was a float to an int).  

How to NOT overload methods:

It’s also very important to understand that method overloading is NOT something that can be accomplished with either, or both, of these two things:

1.  Just changing the return type of the method.  
If the return type of the method is the only thing 
changed, then this will result in a compiler error.  

2.  Changing just the name of the method parameters, but 
not changing the parameter types.  If the name of the 
method parameter is the only thing changed then this 
will also result in a compiler error.    

Confused? Well, here are some very helpful examples of where overloading would be both valid and invalid – pay attention to the comments as well:

Examples of Method Overloading in Java – both valid and invalid:

//compiler error - can't overload based on the   
//type returned -
//(one method returns int, the other returns a float):    

int changeDate(int Year) ;  
float changeDate (int Year);    

//compiler error - can't overload by changing just 
//the name of the parameter (from Year to Month):    

int changeDate(int Year);   
int changeDate(int Month) ;  
 
//valid case of overloading, since the methods
//have different number of parameters:        

int changeDate(int Year, int Month) ;  
int changeDate(int Year);    

//also a valid case of overloading, since the   
//parameters are of different types:    

int changeDate(float Year) ;  
int changeDate(int Year);  

Overloading happens at compile time

Another important point to remember is that overloading is a compile time phenomenon. This just means that the compiler determines whether a given method(s) is correctly overloaded, and if not a compiler error is returned as shown in the examples above.

What about method overriding?

Overriding methods is completely different from overloading methods. If a derived class requires a different definition for an inherited method, then that method can be redefined in the derived class. This would be considered overriding. An overridden method would have the exact same method name, return type, number of parameters, and types of parameters as the method in the parent class, and the only difference would be the definition of the method.

Example of method overriding

Let’s go through a simple example to illustrate what method overriding would look like:

public class Parent {

 public int someMethod() {
   
   return 3;
       
    }
}


public class Child extends Parent{

 // this is method overriding:
 public int someMethod() {

    return 4;
       
    }

}

In the sample code above, someMethod is an overridden method in the Child class, because it has the exact same name, number of parameters, and return type as the someMethod method defined inside it’s parent class (conveniently named Parent).

Overriding happens at run time

Another important point to remember is that overriding is a run time phenomenon – not a compile time phenomenon like method overloading.

PD9waHAgaW5jbHVkZSAoJ2Fkc2Vuc2UtbWVkLXJlY3QyMDE0LnBocCcpOyA/Pg==

Summary of differences between overloading and overriding

Let’s summarize the differences between overloading and overriding. When overloading, one must change either the type or the number of parameters for a method that belongs to the same class. Overriding means that a method inherited from a parent class will be changed. But, when overriding a method everything remains exactly the same except the method definition – basically what the method does is changed slightly to fit in with the needs of the child class. But, the method name, the number and types of parameters, and the return type will all remain the same.

And, method overriding is a run-time phenomenon that is the driving force behind polymorphism. However, method overloading is a compile-time phenomenon.


What is method overloading? [duplicate]

vorite

 

I've found resources that say method overloading is the ability for a language to use the same method with a different outcome, depending on context. Somehow, when I read other definitions, I fell like that's not the whole definition. Is there more to method overloading?

 

 

That's just a very general way of describing it. Method overloading allows you to use a single method name, but "overload it" (provide more than one version) depending on "context" (which is typically the type or number of arguments passed in). Since each method is separate, they can cause a "different outcome".

For example, using C#, you can write:

void Foo()  // Version with no arguments

{

}

 

void Foo(int arg) // Version with a single int

{

}

 

void Foo(string arg1, double arg2) // Version with string and double parameters

{

}




Last edited: 28-Oct-15 01:48 AM

 
Posted on 10-28-15 7:39 AM     [Snapshot: 224]     Reply [Subscribe]
Login in to Rate this Post:     0       ?    
 
 
Posted on 10-28-15 11:00 AM     [Snapshot: 315]     Reply [Subscribe]
Login in to Rate this Post:     0       ?    
 

Over Loading is not so important and not commonly used.
Try to understand Over riding. It has to do more with object oriented, inheritance implementation. If you do C#, try to understand Protected and Virtual methods
 
Posted on 10-28-15 11:00 AM     [Snapshot: 315]     Reply [Subscribe]
Login in to Rate this Post:     0       ?    
 

Over Loading is not so important and not commonly used.
Try to understand Over riding. It has to do more with object oriented, inheritance implementation. If you do C#, try to understand Protected and Virtual methods
 
Posted on 10-28-15 12:02 PM     [Snapshot: 340]     Reply [Subscribe]
Login in to Rate this Post:     0       ?    
 

@Radhakirshana,
Sujhawa ramro lagyo.
 
Posted on 10-28-15 12:22 PM     [Snapshot: 351]     Reply [Subscribe]
Login in to Rate this Post:     0       ?    
 

I do not agree with @NepaliBhai . If you think overloading is not important and not commonly used then I would say you haven't programmed much. Both overloading and overriding are equally important.
 


Please Log in! to be able to reply! If you don't have a login, please register here.

YOU CAN ALSO



IN ORDER TO POST!




Within last 365 days
Recommended Popular Threads Controvertial Threads
Lets play Antakshari...........
शीर्षक जे पनि हुन सक्छ।
NRN card pros and cons?
What are your first memories of when Nepal Television Began?
TPS Re-registration
Democrats are so sure Trump will win
is Rato Bangala school cheating?
What Happened to Dual Citizenship Bill
TPS Re-registration case still pending ..
Basnet or Basnyat ??
H1B fraud
nrn citizenship
इन्दिरा जोशीको चिन्ता लौच
Sajha has turned into MAGATs nest
Nas and The Bokas: Coming to a Night Club near you
श्राद्द
सेक्सी कविता - पार्ट २
डलराँ कमाएर ने .रु मा उडांउदा !@#
ChatSansar.com Naya Nepal Chat
Why always Miss Nepal winner is Newari??
Nas and The Bokas: Coming to a Night Club near you
राजदरबार हत्या काण्ड बारे....
Mr. Dipak Gyawali-ji Talk is Cheap. US sends $ 200 million to Nepal every year.
Harvard Nepali Students Association Blame Israel for hamas terrorist attacks
TPS Update : Jajarkot earthquake
is Rato Bangala school cheating?
NOTE: The opinions here represent the opinions of the individual posters, and not of Sajha.com. It is not possible for sajha.com to monitor all the postings, since sajha.com merely seeks to provide a cyber location for discussing ideas and concerns related to Nepal and the Nepalis. Please send an email to admin@sajha.com using a valid email address if you want any posting to be considered for deletion. Your request will be handled on a one to one basis. Sajha.com is a service please don't abuse it. - Thanks.

Sajha.com Privacy Policy

Like us in Facebook!

↑ Back to Top
free counters