Tag Info

Hot answers tagged

20

When talking about overloads, the name of the function is overloaded, not the function itself. The functions overloading the name are "overloads" and overload the name, but not each other. In your example, "public void foo()" and "public void foo( string bar )" both overload the name "foo". Therefore, you cannot speak in terms of overloader and overloadee of ...


18

This is a relatively minor issue compared to many other bad readability practices you could be susceptible to, so I'd say it's mostly a matter of taste how you name your methods. With that said, if you are going to do something about it, I would follow this practice: Overload if... The methods obey nearly the same contract but simply operate on different ...


16

Who told you PHP doesn't support function overloading?!!! Actually PHP does support function overloading, but in a different way. PHP's overloading features are different from Java's: PHP's interpretation of "overloading" is different than most object oriented languages. Overloading traditionally provides the ability to have multiple methods with the ...


14

I can see where they're coming from, but as rules I would say these are way too specific for 100% restriction in a language design. Gigantic 18+ layer convoluted inheritance schemes are pretty well-established as an anti-pattern for instance but inheriting 1-3 levels deep can be perfectly reasonable for solving certain problems depending on what other ...


13

Classes, method overloading, operator overloading... they are all tools. They are suitable in some circumstances, not in others. Don't try to apply labels like "evil" to such things; instead, strive to understand them so you can decide for yourself whether they are useful or not.


11

I would simply say foo is overloaded. There is certainly no master/slave or parent/child relationship going on here.


11

Quoting http://marc.info/?l=php-internals&m=121578194822276&w=2 Was static member overloading added in PHP 5.3? I noticed that static method overloading was (__callStatic). The two would complement each other and it just seems natural to add these as well. I did notice that they are apart of the "static-class" RFC and a bug report, but ...


10

If the language supports them properly (e.g. type-safety, if applicable), I would prefer optional arguments for the following reasons: They convey your intent better so noone suspects that your function overload will do something different (which it probably shouldn't anyway). Less code to maintain, even if the function overload only delegates to the more ...


8

I vote for "Giving the methods different names" option especially if performance matters. Don't use method1(int[][]) and method2(int[][]). Use method(int[][]) and method_transposed(int[][]) for example. Method name should always help the reader to understand what it does.


6

Not a "Traditional Overloading" full support, only partial. A DEFINITION: "Traditional Overloading" provides, when calling method, the ability to have multiple methods with the same name but different quantities and types of arguments. For method declaration, it provides the option to express a separate/isolated declaration for each overloaded function. ...


4

If you rename a method, it is no longer going to be overloaded. In and of itself, overloading doesn't necessarily make code less readable, however it can make the implementation more difficult to follow if the syntax isn't clear. Many languages use method overloading as a means to present an interface to functionality where the parameters may be optional ...


4

I would recommend using a different name, in every case. It's possible that at some time in the future, you'll want to add another method, say List<Car> findByMake(String make), in contrast to List<Car> findByModel(String model). So suddenly, calling everything find stops making sense. Your methods also less likely to inadvertently be used ...


4

Syntax-wise, I'd create an intermediate query-building object with a fluid interface: // all the basic, cheap to query fields AssetDto a = AssetRetriever(asset_id).fetch() // some common expensive fields AssetDto a = AssetRetriever(asset_id).withOwner().withQuestion().fetch() // numerous less common fields may not command dedicated methods AssetDto a = ...


4

Method overloading is typically used for variants of the same behavior: Do the same thing for different types A default version with fewer parameters and a complex version that allows more control via additional parameters. A good example are the various massively overloaded methods in java.util.Arrays: they do the same thing on arrays of the various ...


4

However, that only makes sense if I create a different class for each different element, which doesn't seem right To me, this feels perfectly right, since, it is just an application of the classic "strategy" pattern (in this case a RoundScoreCalculationStrategy). I would design this in a way like this: interface RoundScoreCalculationStrategy { ...


3

Version #2 is FAR preferable, although the overall design is often considered a code smell. Note that more recent C# dialects allow for optional parameters, so you could combine your base and overload. class foo { public foo(string a, bool no_tricks = false) { variable = a; if(no_tricks == false) { TrickyFunction(a); } } } (And, of ...


3

I would say that overloading is appropriate when both of the methods are semantically equivalent. To steal from dukeofgaming's examples: These are overloaded appropriately: public int sum(int a, int b){ return a+b; } public double sum(double a, double b){ return a+b; } These are not: public int sum(int a, int b){ return a+b; } public ...


3

Essentially to have the parameters of the method dictate how the method will behave. A quick example would be: class Calc{ //... public int sum(int a, int b){ return a+b; } public double sum(double a, double b){ return a+b; } //... } If you pass the method sum(a,b) a couple of integers it knows that it should call ...


3

You need to be careful designing APIs that have methods overloaded on parameter type: the methods need to do exactly the same things, otherwise the users will be confused. Two methods that take a matrix, one taking a "straight" one and the other taking a transposed one, are definitely not doing the same thing, so overloads on different types is an unlikely ...


2

I think that a good way to express this is to focus on the final result, not on changes made to the class over time. Thus, instead of saying "I overloaded 'foo' with 'foo(other parameters)'," you say "foo is an overloaded function, with 'foo()' and 'foo(other parameters).'"


2

You overload when you wish to support different types: public overload void MyMethod(int value) { } public overload void MyMethod(bool value) { } public overload void MyMethod(string value) { } or to support a progressive interface using different parameter lists: public overload void MyOtherMethod() { this.MyOtherMethod(DefaultValue); } public ...


2

When dealing with large object, this is really common. While adding new methods increases performance, it significantly decreases the maintainability. And again you need to choose between those two. I suggest you have a method that returns (not necessarily the smallest) commonly used data, another that returns the whole object, and probably a few more for ...


2

I believe the common approach is to encapsulate some (or all) of the parameters into a class and have that as a parameter: DoThing(string foo, string bar, DoThingParameters parameters = null); If you use C#, you can then write those parameters directly inline when calling the method: DoThing(foo, bar, new DoThingParameters { More = value, AndMore = ...


2

The premise of your question is flawed: GOO supports both overloading and classes.


2

As you stated, there isn't a way (until Java 8) for an interface to require a static method. There also isn't a way to override a static method, so which documentation could actually be inherited? I see a few options: If the documentation on the interface describes the method (which I would expect - how are implementers supposed to know about the load() ...


1

You get consistency in naming. The real issue is human memory for method names, right? we find it easier to remember names that are commonly used and economy of typing, allowing for shorter method names? fewer different names means (mathematically) that the name itself carries less information. Below is scenario :: function Person FindPerson(string ...


1

Remember: Java does not do "dynamic method invocation", there is nothing dynamic about the invocation of an overload or override, these are invocations decided at compile-time. The issue you're seeing is due to the fact that a base class lacks details of sub classes, thus the compiler cannot automatically convert a base class at compile time to any given ...


1

I've been through this same problem recently and adopted the following solution: Data access methods should get data only from a single resource (e.g., database table), and if the process needs related objects appended to the main object it should call for the method responsible for those respective objects. This way if you need an asset with it's ...


1

Assuming a constructor kind of situation: I often choose a fluent builder pattern to prevent situations with many options. Eg.Ordering.natural().onResultOf(function).reverse().compound(Ordering.natural().onResultOf(function2)) is an example of calling a fluent builder interface implemented in Guava. Of course you now need a separate object to hold the ...


1

Use different method names if the parameter types are the same. Simple enough, no?



Only top voted, non community-wiki answers of a minimum length are eligible