SOLID principals in D

[Joakim]

On Sunday, 17 June 2018 at 01:38:17 UTC, evilrat wrote:
> 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;
> --------------

Thought I'd add a link to Walter's good article laying out the 
case for such component programming with ranges:

http://www.drdobbs.com/architecture-and-design/component-programming-in-d/240008321