Swift: Sharing logic tied to state when composition isn't a good option - ios

Question

Let's say you have two classes conforming to a protocol and you want some logic to be shared between them. In languages like Java, you'd typically create an abstract class with the shared logic and make use of it in subclasses. In Swift, abstract classes aren't supported. What's the recommended approach for accomplishing this?
One answer is composition, but what if the common functionality can't be divided into smaller components in a clean and sensible way?
Another answer is to implement common functionality in the protocol itself, but what if it's heavily tied to state?
Some context:
I'm working on an iOS app in which two screens use the same view for different purposes. I'm using the MVP pattern and would like to share common logic among the two presenters. There is state involved, and there isn't really a clean way to pull shared logic into separate components since it's so closely tied to the view interface.
Here's a minimal example of this situation:
protocol View {
func doSomething()
}
class ViewController : UIViewController, View {
func doSomething() { }
}
protocol Presenter {
func tellViewToDoSomething()
}
struct Presenter1 : Presenter {
let view: View
init(withView view: View) {
self.view = view
// then do something unique to presenter 1
}
func tellViewToDoSomething() {
view.doSomething()
// then do something unique to presenter 1
}
}
struct Presenter2 : Presenter {
let view: View
init(withView view: View) {
self.view = view
// then do something unique to presenter 2
}
func tellViewToDoSomething() {
view.doSomething()
// then do something unique to presenter 2
}
}
I'm asking this as a general question rather than in terms of my current situation because I'd like to understand general approaches for sharing common logic in Swift.
I'm coming from an OOP background and it's likely that I'm fundamentally misunderstanding something, so maybe someone could enlighten me.

Answer 1

Could a protocol extension help here? The thing that makes protocol-oriented programming tricky from an OOP perspective, of course, is that there is no super. But nothing stops you from just calling the protocol's built-in functionality:
protocol View { func doSomething() }
protocol Presenter {
var view : View {get set}
}
extension Presenter {
func tellViewToDoSomething() {
self.view.doSomething()
}
}
struct Presenter1 : Presenter {
var view: View
func tellViewToDoSomethingAndThenSome() {
self.tellViewToDoSomething()
// and then some
}
}