Partial class implementation

[Robert Fraser]

I agree, but with a good IDE, this is a non-issue. I refer to the fields directly when I'm coding and run a 30 second refactoring in Eclipse to generate getters and setters and refer to them instead of the field before I do a check-in.

Still, there's something to be said for abstracting field access within a class (although, again, D's property syntax makes this unnecessary.)

janderson Wrote:

> Robert Fraser wrote:
> > Hi Joel,
> > 
> > Indeed, my company style guide requires that getters/setters exist for all variables, most of which are private and used internally by other methods of the class. These and the constructors are the only methods allowed to refer to the variables directly. Personally, I find this going _way_ overboard (plus, the class internals start to get out of sync if legacy properties are supported for non-existent fields), but it's actually saved me once or twice.
> > 
> 
> Personally I hate writing tons of getter setters.  Its like smashing my 
> head against concrete.  I hate having to write 5 lines simply to add a 
> new variable.  Then if anything changes you've got 5 more lines per 
> getter/setter to maintain.  So I try to keep the number of setters low, 
> most data private and have actually useful functions for managing them 
> instead.  Sometimes its possible to use a strut component (as a param to 
> a setter or getter) to minimize getters setters.  Many times I return a 
> object which can be modified.  That object has its own set of 
> validations.  Although I can see setter/getter they add superior 
> interface benefits.
> 
> I think programming is a balancing act in every reguard.
> 
> -Joel