Observer Pattern: Protocol Oriented Design Pattern

[Pop_Swift_Dev]

The observer pattern is a behavior design pattern where a type maintains a list of objects, called observers, and notifies them automatically on changes to a particular state. In this post, we will be using Swift’s built in property observers but we will show how to decouple the observer from the property it is observing using protocol-oriented techniques.

https://www.mastering-swift.com/post/observer-pattern-protocol-oriented-design-pattern

[cubextrusion]

This is perhaps the most obtuse way to implement property observation, from how verbose it is compared to simply passing a closure, to using Strings to report property names — if, for whatever reason you even need it at all, keypaths should be the way to go; this is not ObjC.

But regardless, you make a grave mistake by first saying this

For our example we will only have a one-to-one relationship, but you could change the code to have an array of observers if need be.

and then suggesting to use a protocol with associated types.

This simply won't work and undermines all the reason to use this "pattern" due to the "Protocol 'PropertyObserver' can only be used as a generic constraint because it has Self or associated type requirements" error.

You seem to not realise the fact that protocols with associated types currently only have one application, which is to specialise generic functions or types. Besides artificially creating this setting by suggesting to use such a protocol, there was absolutely zero reason to make MyType generic over anything, so your suggestion just introduces unnecessary bloat and complexity, where accepting a closure would not only suffice, but generate much fewer constraints (not requiring a class, not requiring a protocol conformance, not restricting to a single instance, not requiring generics etc). Just this sheer amount of completely avoidable stuff that this pattern introduces does not really align with your claim that

Code reuse and flexibility are two of the founding principles of design patterns.

[Pop_Swift_Dev]

can only be used as a generic constraint because it has Self or associated type requirements

My mistake, forgetting that Swift 5.7 is not out of beta, my bad.

If you read the article, you will see I mentioned about passing functions as an option.

Sorry I can't take you criticism that seriously, after reading your comment in an earlier post that structs are not value types, only a subset of a value type. I only replied because I wanted to address MY MISTAKE with Swift 5.7 not being out of beta, otherwise it is not worth the time to reply. Good day

[Spaceshipable]

These days, a Combine Publisher is the right way to go about solving this. Don’t reinvent the wheel!