SOLID principals in D

[FromAnotherPlanet]

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.
>

Also if there is any good literature that explains the 'D' way of 
going about these principals or even how it enhances them that 
would be helpful.
>  - 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.