Partial class implementation

[janderson]

James Dennett wrote:
> Robert Fraser wrote:
>> janderson Wrote:
>>
>>> 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.
>>>
>> I agree so far...
>>
>>>> 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).
>> I disagree here, because you are making the assumption that there
>> will never be a need to refactor
> 
> No such assumption is present.  In fact, quite the reverse;
> KISS helps to keep refactoring easy, by dumping unnecessary
> complexity that impedes change.  And also for one more reason,
> that you touch on further down...
> 
>> (with D's property syntax, this is somewhat mitigated since a
>> public field can be turned into a method without breaking client
>> code, however if something that was a stack-allocated class later
>> needs to be given dynamic dispatch, this is not as much as possibility).
>>
>> Further, however, this mindset encourages thinking of classes/structs
>> as aggregations of data.
> 
> It doesn't, but that's the reason why it's helpful when keeping
> code amenable to refactoring.
> 
> Sometimes types are present to express behavior.  Those should
> be designed in terms of operations, with the representaton of
> their state hidden.
> 
> Other types genuinely are just collections of data.  Such are
> rarer than beginner programmers tend to think, but more common
> than many OO textbooks would tend to admit.
> 
> It's the "mere aggregations of data" that are mostly clearly
> expressed in terms of data.
> 
> It's true that once in a while, during evolution of a system,
> something that was just dumb data turns out to be usefully
> converted into a smarter object.  If you ruthlessly kept your
> code simple (e.g., by using simple structs where appropriate)
> then (in C++ at least) it's trivial to make such a change (as
> C++ has less difference between struct and class than current
> D).  If you build in speculative complexity in case of change,
> you ironically end up making evolution harder.
> 
> (This is one of the pieces of XP that I've found has held up
> well in the face of experience and experimentation.)
> 
>> For a better example than a point, think
>> about an AST node in a compiler (what I was thinking about
>> when I wrote the OP, though now we're pretty off-topic).
>> A generalized AST node will have a set of children and a
>> parent, and a subclass implementing a conditional expression
>> may have a condition, a then expresson and an else expression.
>> It's possible that all this should be properties with getters
>> and setters. However, if you think more deeply about it (I'd
>> suggest staring at a picture of a bonsai tree...), the parent,
>> condition, then expression and else expression will only be set
>> once, and, depending on how you generate the tree, this may be
>> at construction time. So, having setters for these properties
>> is unnecessary and potentially dangerous if other coders will
>> be using your class.
> 
> Right; a bunch of setters/getters is worse than either (a) a
> simple data object or (b) an object exposing behavior and hiding
> unnecessary access to its state.
> 
>> In fact, very few classes I write have explicit getters/setters
>> /properties. Classes, IMO, are aggregations of methods, not data,
>> and the data serves to hold state relating to invocations of
>> those methods.
> 
> That's the common case; I think Bjarne, Herb, Scott etc. are
> assuming that you know this, and highlighting the exceptions.
> 
> -- James

I couldn't have put it better.  Thanks James.