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
