Overloading methods that do logically different things, does this break any major principles?
- by siva.k
This is something that's been bugging me for a bit now. In some cases you see code that is a series of overloads, but when you look at the actual implementation you realize they do logically different things. However writing them as overloads allows the caller to ignore this and get the same end result. But would it be more sound to name the methods more explicitly then to write them as overloads?
public void LoadWords(string filePath)
{
var lines = File.ReadAllLines(filePath).ToList();
LoadWords(lines);
}
public void LoadWords(IEnumerable<string> words)
{
// loads words into a List<string> based on some filters
}
Would these methods better serve future developers to be named as LoadWordsFromFile() and LoadWordsFromEnumerable()? It seems unnecessary to me, but if that is better what programming principle would apply here?
On the flip side it'd make it so you didn't need to read the signatures to see exactly how you can load the words, which as Uncle Bob says would be a double take. But in general is this type of overloading to be avoided then?