Partial class implementation

[janderson]

Robert Fraser wrote:
>> That article is indeed well-reasoned, however it fails to take into
> account other features. In particular (this may come off as Java-fanboy
> nitpicking):
>> 
>> 1. It encourages a large public interface: if functions that depend
> soley on the "public interface" are non-members, to achieve the same
> level of accessibility, the initial public interface of a class may need
> to be expanded. 

Classes should be small and as minimal as possible.  I think this is 
part of Meyers argument.  Anything that can be placed outside the class 
should be.  If it can't because that gives assess to something that 
could potentially be misused by the world outside the class, thats a 
case to make it a member.  Therefore you get this highly easy to use 
class that is less bug prone.  It knows what is job is, its small so its 
easy to maintain.

> In particular the getter/setter/property pattern is
> encouraged by such a design, and overuse of this pattern can degrade a
> class to a simple aggregation of data, defeating the purpose of
> encapsulation entirely.
>> 

This is true.  I don't think the example of a point was the best 
example. Herb Sutter and Bjarne Stroustrup's often argue that if the 
class variables have not constraints (invariants) then the class should 
really be a C struct (where everything is public).


> 2. The architecture is less nimble for client code. If a function
> that at one time needed only access to the public interface later
> needs member access, the non-member function will become a simple
> proxy for the member function, or, worse, the public interface could
> be expanded.

But this is a good thing.  It means you either have to go back to the 
drawing board with the class interface or add the non-member into the 
interface. Its pretty easy to remove a non-member function.  Its much 
harder to remove a function once it becomes part of a class.  Note that 
if you want to extend a class there are other ways to do it (namely 
using a  component).

Also if you find your creating proxies, then there was probably 
something wrong with the design in the first place.

> 
> 3. Sending messages directly to a class is (IMO) clearer, prettier,
> and better for auto-complete tools & lookup (manual or
> go-to-definition) than a free function.

There is no real point in arguing this.  My main argument is based on 
code refactorbility and design.  I find free functions are much more 
reuseable then member functions, look at algorithms in std (find, sort 
ect...).

> 
> But to each his own, I guess. That article certainly had some good
> points.
> 
> That said, I was thinking about partial class implementation mainly
> with regards to related virtual functions (i.e. Implementing the same
> abstract/interface/override function across multiple subclasses all
> in the same file, while other parts of those clases are defined
> elsewhere. This will help logically group large clas hirearchies,
> IMO.

While I'm not against the idea.  I think, its a much better idea to have 
lots of small cohesive component classes rather then a large class. 
I've seen so many large classes and I've always been able to break them 
down into small chunks.  I must admit though it can sometimes be quicker 
in the short run to simply throw everything into the same class.

Here's some more information:

http://www.artima.com/intv/goldilocks.html


> Tristam MacDonald Wrote:
> 
>> This might be an interesting perspective on the kind of harm such an option might cause:
>> http://www.ddj.com/dept/cpp/184401197
>>
>> Robert Fraser Wrote:
>>
>>> Random, C#-inspired thought:
>>>
>>> It would be nice if it were possible to implement parts of classes in different modules than other parts. This would allow logical grouping of methods for a set of related classes.
>>>
>>> This is already possible via template mixins (sort of, but alias template params are required to access fields), but explicit partials might be quite helpful.
>