Scott Meyer's argument that non-member functions increase encapsulation and allow for more elegant design (designwise) seems very valid to me. See here: Article
Yet I have problems with this. (And seemingly others too, especially Library developers, who usually completely ignore this)
Code usually looks better and more logical when I use member functions. This may be an acquired taste though and just takes some getting used to looking at algorithms first and then on the objects. (shudder)
So maybe I have only one problem:
With member functions, me AND my IDE know what the class can do.
For me this is huge! I use nothing that doesn't support member function code completion for programming. In well designed libraries it completely replaces documentation for me. And even if I would look at the api doc, looking through the member list just feels absolutely natural, logical and I can be sure that, well, this is the end. If the method is not in there, I can safely assume it doesn't exist and I can write my non-member non-friend.
I put up with this in the STL, because, well, it makes sense to see algorithms apart from basic components and because of the you get used to it factor.
I haven't seen an IDE that can tell me what non-member functions work on a particular class.
And this actually is my question: Is there an IDE (or IDE feature) out there that helps with this code convention?
I've come across this thing in the past.
My idea then was rather clumsy, but got the job done: namespaces.
What I did was
namespace myclass
{
class MyClass
{
...
};
MyClass operator+(const MyClass& lhs, const MyClass& rhs){...}
}
Meyers is certainly correct that using non-members increases encapsulation, by minimising the number of functions that could potentially access the private state. However, encapsulation is just one of many (often conflicting) aspects of code quality.
He does make a valid point that the library writer won't necessarily write functions for every possible usage of the class (since there may be usages that they don't think of). This means that you may well have to add non-member "helper" functions yourself, just as they would do if they followed Meyers's advice. So there's no way of knowing that the set of member and friend functions is indeed the only set of functions that act on the class.
As a technoluddite, the "IDE" that I favour (a text editor and a shell) has the following "feature" that's pretty good for finding the functions acting on a class:
find . -name '*.h' -o -name '*.cpp' | xargs grep MyClass
I can't comment on "real" IDEs.
I don't believe it is possible for an IDE to tell you all non-member functions that you can use with your class. Using templates, it is simply too difficult to make a list of all such functions. IMO, the best you can hope for is for an IDE to be able to tell you before compilation whether a call you're trying to make is valid. And even that requires some serious compilation-like process inside the IDE.
I understand how you use member functions as a replacement for documentation in classic classes. But the design Scott Meyer suggests isn't about classes that provide complex functionalities, just basic ones. Complex functionalities come from elsewhere, the original class may or may not know about it, it does not really matter. It's all part of the idea. But you are right. In that case, there is a renewed need for well-thought documentation.
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With