First time I've heard "strategy pattern". However, I have implemented something like this many times. Dependency Injection? Composable Interfaces? Traits? Heck, even a C header declaration can do this.
The strategy pattern is definitely a form of the above! It's the basic idea is dependency injection, allowing the "strategy" used to be chosen at runtime. For example, you may use a `StripePaymentProvider` if a user wishes to pay by card, or a `PayPalPaymentProvider` in a different case. Use of the strategy pattern will typically have a function that will return the required type at runtime.
Good to know! I wouldn't generally recommend specifying properties on interfaces or protocols, though. It's better to leave the underlying implementation to users of the interface, rather than trying to force them down a specific path with your interface
I was nodding along thinking 'ok this is cool but i'll just stick to abc' until i got to 5:35 🤯 really nice video
Thank you!
Just stumbled across your channel and found this video very informative, subbed 😊
I'm glad you liked it, and thank you!
First time I've heard "strategy pattern". However, I have implemented something like this many times.
Dependency Injection?
Composable Interfaces?
Traits?
Heck, even a C header declaration can do this.
The strategy pattern is definitely a form of the above! It's the basic idea is dependency injection, allowing the "strategy" used to be chosen at runtime. For example, you may use a `StripePaymentProvider` if a user wishes to pay by card, or a `PayPalPaymentProvider` in a different case.
Use of the strategy pattern will typically have a function that will return the required type at runtime.
You can use the @property decorator on methods in protocols to make it mean a normal property
Good to know! I wouldn't generally recommend specifying properties on interfaces or protocols, though. It's better to leave the underlying implementation to users of the interface, rather than trying to force them down a specific path with your interface