Method overloading is not to be considered as Polymorphism feature
Polymorphism is often referred to as the third pillar of object-oriented programming, after encapsulation and inheritance.
It has been a discussion point that method overloading is considered as Polymorphism feature?
And the answer is method overloading is not considered as Polymorphism any more as per the old books we have read.
MSDN says "Polymorphism is often referred to as the third pillar of object-oriented programming, after encapsulation and inheritance. Polymorphism is a Greek word that stands for "many-shaped" and it has two distinct aspects:
Ø At run time, objects of a derived class may be treated as objects of a base class in places such as method parameters and collections or arrays. When this occurs, the object's declared type is no longer identical to its run-time type.
Ø Base classes may define and implement virtual methods, and derived classes can override them, which means they provide their own definition and implementation. At run-time, when client code calls the method, the CLR looks up the run-time type of the object, and invokes that override of the virtual method. Thus in your source code you can call a method on a base class, and cause a derived class's version of the method to be executed."
And method overloading is something which happens at compile time. You have multiple methods with the same name, but different parameters. When you call one of the methods, the compiler will decide which of the method overloads best matches based on the parameters you supplied.
Please find below mentioned link where people who don't agree on overloading as Polymorphism will get clear picture and clear their confusion.
Reference: http://social.msdn.microsoft.com/Search/en-US?query=polymorphism%20Overloading&ac=3
, everyone has their preferences and styles when it comes to coding. And in the CF world there are those who prefer strong typing and those who don't. And we just happen to fall on the opposite sides of that fence. I just felt that it came across in the podcast that to do OO in ColdFusion you SHOULD use interfaces (even though you might not have intended it to come across that way), and I think it's important for people to know that there are different ways for people to implement in ColdFusion and that it doesn't make your code any less if you don't use interfaces. (And as much as I respect you, Mickey, I don't think it's cool to dismiss people's points of view as nonsense , be they Helms/Cornfield, or Joe Blow Developer. We should all keep an open mind about stuff, as you yourself said in the last podcast).My experience was coming from front-end HTML/JS development to back-end procedural CF development before I got into OO CF. I don't have any experience with statically-typed OO languages, which is probably why I had such a hard time seeing the point of hard typing and interfaces in a dynamically-typed language. Whereas I can see why people with a Java or C# background coming to CF would prefer to use interfaces because they are used to that sort of thing. When I first started doing OO, I hard-typed everything, but then when I switched over to duck typing I found that it gave me a lot more freedom and it just fit a lot better to the way I do things and I experienced no drawbacks, really. I'm not saying everyone should do things my way, but it's just one way of doing things.A couple of other points:Mikey, I am not against “coding to an interface". I think that's really important. But people should realize that “coding to an interface" is a principle of OOprogramming and doesn't necessarily require the use of “interface" (the language construct).Brian – you mentioned that strong typing gives the developer the benefit of type-safety at compile time. That's true – in Java! In CF, there is no compile step, so any errors you run into are going to happen at runtime. Hard typing an argument in a CFC isn't going to prevent you from accidentally passing in an object of the wrong type in your code and you won't catch that until run-time. Just like if you duck type your argument and you accidentally pass in an object that doesn't have the right method signatures, you'll get a runtime error.Also, my opinons about interfaces aren't just because I'm blindly following Helms and Corfield. But once I found out that these CF “luminaries" (who also have a lot of experience on other dynamic and static OO languages) shared my views, I felt more confident that I wasn't way off with what I was thinking.