Wed Oct 17 - Avoiding Code Smells by Walter Bright

[H. S. Teoh]

On Fri, Nov 02, 2018 at 12:25:21AM +0000, unprotected-entity via Digitalmars-d-announce wrote:
[...]
> "Encapsulation is sometimes referred to as the first pillar or
> principle of object-oriented programming. According to the principle
> of encapsulation, a class or struct can specify how accessible each of
> its members is to code outside of the class or struct. Methods and
> variables that are not intended to be used from outside of the class
> .. can be hidden to limit the potential for coding errors or malicious
> exploits."
>
> https://docs.microsoft.com/en-us/dotnet/csharp/programming-guide/classes-and-structs/

That is a narrow definition of encapsulation that is very OO-centric,
and IMO, it sorta misses the larger point behind encapsulation, focusing
instead on the mechanics of it, and that the specific implementation of
it in the OO paradigm.  The concept of encapsulation goes beyond OO and
classes; it has to do with modularity and well-defined interfaces
between modules (or units of encapsulation -- this is not necessary the
same thing as a D module).

It's fine to explain how OO's concept of classes and methods implement
encapsulation, but to *define* encapsulation in terms of classes and
methods is IMO missing the forest for the trees.  If *that's* your basis
for understanding encapsulation, it would it explain a lot of your
reactions to this thread.  But there is more to the world than the
narrow realm of the OO paradigm, and in a multi-paradigm language like
D, it doesn't seem to make sense to be handicapped by a definition of
encapsulation that really only makes sense in the context of an OO
language.

What encapsulation is really about, is the ability to modularize your
code into self-contained units which have well-defined interfaces, with
private code and data that cannot be accessed outside of that unit.  In
OO languages, this unit would be the class.  But in D, it's the module.
That doesn't make D non-encapsulated; it just means we're using a
different unit than an OO language.  It's just a difference between
pounds and dollars, not some fundamental discrepancy.  You just have to
convert one currency to another, that's all.


> D simply has *zero* support for encapsulation of classes or structs,
> within the module (only encapsulation from code that is outside the
> module).
> 
> Any programmers interested in enforcing encapsulation in D (the first
> pillar of OOP), are *forced* (because the language doesn't provide the
> tool to do anything else) to use the one class, one struct, per file
> solution. Which seems really silly to me. D forces you into Java like
> programming - just to encapsulate a little class or struct.
> 
> Speaking of 'structs', I don't see anyone in the D community, telling
> others to use 'one struct per module'.

Because we love UFCS, and structs just lend themselves very well to that
sort of usage.

And along that line, recent wisdom is that it's better to move things
*out* of classes (and structs) if they don't need access to private
members. (Sorry, I wanted to include a link for this, but I couldn't
find the article -- the title eludes me and google isn't turning up
anything useful.)  Class and struct APIs should be as minimal as
possible -- just enough to do what needs to be done and no more, and the
rest of the syntactic sugar (that makes it more palatable to your users)
belongs outside as optional convenience functions.


T

-- 
There is no gravity. The earth sucks.