Functions Can Be Your "Friend", Maybe
I would like to talk theory for a little bit about friend methods. There has been some talk over whether you should or should not use friend methods. If you take a look into the .NET framework API's you are bound to find heavy use of friend methods, properties, and classes. However, some people have said never to use them.
I see wisdom in both lines of arguments. Friend functions can be a problem because if you rely on them heavily, it opens the constructors, methods, and properties up to many possible internal access points, which could result in overwriting previous values. In my own coding experiences, I've seen several times where the use of several friend functions made the code more bogged down through the approach I used, instead of using an alternative approach with public properties/methods instead. A method in one class called a method in another, and it created sort of a networking scheme of friend function calls, which can become unmanagable. Instead, a refactored approach made it more manageable.
However, there were times, when being consistent with friend functions, increased the efficiency of the API. In one example, because of loading data in a consistent way, using a friend function in the class that was having the data loaded made it more manageable when editing code dealing with that class; all data access code was centrally stored in this one object. Then, the parent object that needs to populate it can call this loading method to load the data. Any object needing to load the data can also do so, using one method call.
I think friend functions need to be limited in their use, but not eliminated. When using them, extra care is needed to ensure that it isn't making the code unmanageable and adding extra complexity. Keep in mind all of the access points that friend functions open your code up to, and try to keep it to a minimal set. Sometimes, realizing an alternative approach can lead to a better design.
Comments
