SOLID principals in D

[evilrat]

On Saturday, 16 June 2018 at 19:20:30 UTC, FromAnotherPlanet 
wrote:
> Hi, I come from a C# background and have been looking at D. How 
> well does D implement solid principals? I've grown to really 
> enjoy the SOLID style.
>
> For those unfamiliar, SOLID is an acronym for:
>
>  - Single purpose: Meaning every unit of code (whether it's a 
> function or class) should only
> have one reason to change.
>
>  - Open/Close principal: Things should be open to extension but 
> closed to modification. The example I like to use is some sort 
> of IConverter object. Things can implement IConverter, but if 
> you need a new way to 'convert' things, you don't extend an 
> existing object, but instead create a new class that implements 
> IConverter.
>
>  - Liskov substitution principle: Essentially says if I have a 
> method/function that takes a base class, then the behavior of 
> that method shouldn't change when passing in derived objects. I 
> think the term people like to use is whether or not you use a 
> base/derived class it shouldn't effect the 'correctness' of the 
> program.
>
>  - Interface segregation principal: Essentially breaking the 
> program up into smaller interfaces. Sometimes only consistent 
> of one or two methods/properties (can feed into 'S' of SOLID 
> quite nicely).
>
>  - Dependency inversion principle: Things should depend on 
> abstractions not concretions. Strongly enables dependency 
> injection.
>
> D seems to have all of the features *required* to make this 
> happen, but I guess the real question is the last two, and more 
> specifically the last one.

I am still not a D pro, so some thoughts maybe a bit off...

(intro part)
The "true D" guru's would tell you "in D your typical code would 
be mostly ranges(or templates) instead of classes", there is a 
good portion truth, but IMHO I find it overly attached.
D uses duck typing for ranges, which means for example very basic 
(input) range have this protocol of 3 primitives - popFront(), 
front, empty
Ranges heavily used in conjunction with templates, and templates 
is static thing, but with clever use of duck typing and that 
range protocol usually you don't care about specific type at all 
when dealing with ranges. Of course there is polymorphic 
interface(as in C#) for ranges too.


Now how it applies to S and O? Ranges is basically an essence of 
S principle, they do exactly single thing, and most functions 
taking ranges as well.
Just look at this "Sort lines" or some other examples on main 
page:
-----------------
stdin
   .byLineCopy
   .array
   .sort!((a, b) => a > b) // descending order
   .each!writeln;
--------------
stdin is console input stream, what happens next? all four 
functions above operates on ranges, and you can clearly tell what 
is their purpose. In this simple example they started operate on 
stdin, but in no way limited to it. It can be file, network 
stream or whatever else as long it is implements range protocol. 
Even though these functions may have different interface this is 
still the possibility for open/close principle. (yep, I agree 
this isn't the best example)

(sorry, this part is not about SOLID at all)
This is how most of standard library built, sure this isn't C# 
BCL and there is so very few things comparing to it, and there is 
very few use of polymorthic types in it, but it is highly generic 
because of use of templates.

But enough about standard library, you are not forced to do 
everything that way, there is of course classes and interfaces, 
they work same as in C#, mostly. In own code you can do pretty 
much anything you can in C# (not actually sure what you can't) 
using classes and interfaces.

I skip the Liskov principle. Classes and interfaces is enough to 
cover it, but again D is not limited to them, so you may even 
find your own discoveries.


A word about DI in both D and D in SOLID:
This isn't actually limited to just classes, basically it means 
that you(client code) provide dependencies(whatever things needed 
to be operational) for function/class you use to do the work, so 
they don't just 'new' it on their own.
There is even a DI framework[1] (don't mind the names in API, I 
think it is heavily inspired by Java's Spring)


Since you are coming from C# background the current state of 
tooling may shock you, the standard library is not a swiss knife 
and doesn't have all the goodies BCL has, I even pointed out 
there is not that much OOP stuff and polymorphism in it. There is 
also some language design choices that may surprise(both good and 
not so good ways) you.



[1] https://code.dlang.org/packages/aedi