
Configurable Types in Swift - ingve
https://www.swiftbysundell.com/posts/configurable-types-in-swift
======
WoodenChair
It's a good article, but it reminds me that sometimes I feel like with
protocol-oriented programming we're just reinventing class hierarchies with a
new kind of polymorphism and finding a way to do things with composition
instead of inheritance, just because that's the new right way to do
everything. Other than value types vs reference types, what would be the
downside of FileImporter being a base class with a few subclasses for each
file type? The base class could have a factory method that returns one of the
subclasses.

And could we achieve much of what we want with protocol-oriented programming
crossed with value types if structs could have inheritance? I know that sounds
strange.

In short, I totally get the elegance of protocol-oriented programming, but I
wonder if for most of its applications a traditional class hierarchy would be
more than good enough. I'm not sure inheritance is as bad a word as people
make it out to be.

~~~
0815test
The controversy over inheritance has to do with _implementation_ inheritance,
where any method that's defined on a base class can depend on methods that may
have been overridden in some derived class, or rely on some non-codified
invariants that a derived class might break: this is known as the "fragile
base class" problem. By using composition over inheritance, this is not
something that can happen by default, because there is no provision for a
method call on some "base" method to dispatch on the object's "actual" type,
or more broadly to rely on anything but what's defined in the base object
itself. You _can_ recover that dispatch-like behavior ("open recursion"), but
it's something you have to code yourself and opt into explicitly. This is good
for rigor and auditability, as well as just being all-around simpler and
easier to understand. Implementation inheritance is too general of a feature,
and just not a good abstraction.

~~~
WoodenChair
I'm very aware of the fragile base class problem. But it's a non-problem for
many of the small class hierarchies that protocol-oriented programming
examples are often used as examples of replacing. Surely, there would be no
fragile base class problem here with a total of 1 base class and 3 subclasses.

If you're doing something like the Swift standard library, protocol-oriented
programming is a huge win. If you're doing a small class hierarchy as you
would be to do this example, I don't see the big win.

------
throwaway34241
I don't understand the issue with the switch statement at the beginning. It's
said that it "isn't great from a flexibility point of view" and "is more or
less guaranteed to grow out of control".

In the hypothetical example of a note taking app, what bad thing would happen
by keeping the switch statement? Adding two lines to a switch statement seems
like a trivial step compared to all the other work required to write an
importer for something like markdown.

The switch statement is trivially easy to read and understand, more so IMO
than replacing it with a FileImportResult enum, a generic FileImporter class,
creating static factory methods for each import category, etc. I'd like to
understand the benefits of programming in that style over something more
simple.

