On Sunday, 20 April 2014 at 11:12:42 UTC, Lars T. Kyllingstad
wrote:
On Sunday, 20 April 2014 at 11:01:27 UTC, Gary Willoughby wrote:
‘kitchen sink’ classes that are filled with every conceivable
method. The desired approach is to have the class implement
the bare minimum of functionality, and add other functionality
with extension methods (that do not have access to the class’
private state)."
However, in D, all functions defined in the same module as a
class will have access to the private state of that class, on
an equal footing with its member methods. Therefore, the above
statment doesn't really help in deciding which to use.
Writing classes like this allows for better encapsulation
because only the required behaviour is contained within the
class keeping it focused. [...]
I'm also pretty sure Walter has repeatedly stated that the
module is the unit of encapsulation in D, not the class.
Wouldn't this be "worked around" by packages?
You place your class in a non-public subpackage package. Then you
implement the non-member functions in the module proper.
MyModule
|
+--MyPackage
| |
| +-MyClass
|
+--MyNonMemberFunctions
Not sure this is "worth it" though.
