[swift-evolution] [Review] SE-0026 Abstract classes and methods
david.screve at dlta-studio.com
Thu Mar 3 15:46:08 CST 2016
> It's the difference between forgetting to do two things and forgetting to do just one.
> Let's say I have a framework that requires me to supply a subclass of Foo to do something useful.
> With abstract classes, I just need to subclass Foo, and the compiler tells me what implementations I need to provide.
> With the protocol-based "solution" being proposed, I need to subclass Foo *and* I need to remember to declare conformance to FooProtocol. Then and only then can the compiler enforce anything.
> 2 != 1
In addition, there is a different meaning between protocol and inheritance. When you inherit, you specialize a behavior with some piece of code. For example, consider UIView class. When you want to make a custom class, you inherit UIView and with a custom drawRect. This has no meaning to create a protocol to implement the drawRect because drawRect handle a behavior (specializing UIView) and not a delegate or datasource external interface (i.e protocol).
* Protocol is the right choice to provide external interface such as datasource, event handler, delegate.
* Extension is the right behavior for extension.
* Inheritance is the right choice for specialization.
These 3 needs does not compete each other but are required for a multi-paradigme language that should handle severals kind of architecture designs.
That’s the reason I pull abstract class proposal because in our company we have the 3 kinds of architecture patterns.
That’s not easy to provide a simple and readable example for abstract classes, but there is actually a need. In some design, POP is a workaround for abstract classes. This works, but according to architecture design, it is a workaround.
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 4233 bytes
Desc: not available
More information about the swift-evolution