Partial class implementation

Robert Fraser fraserofthenight at gmail.com
Mon Jul 16 22:13:14 PDT 2007


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. 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.

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.

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.

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.

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.
> 




More information about the Digitalmars-d mailing list