Fakes are indispensable in my opinion and I've started moving away from mocks whenever I have situations like this. Also, just watching your video made me think that a fake of an implementation is a sister of the Null Object Pattern. While used differently, they're of the same species at least. In addition to this, this is a great way to Mr. Miyagi someone into understanding the strategy pattern!
Nice! I really dig this way of working. Question: Are you always using "Providers" to integrate with 3rd party solutions or do you also use "Services"? Sometimes I think it's hard to see the difference 😅 Also, would love to see a video of how to test each of the implementations. Would you in those cases use mock with http fake to fake the expected output of the api?
9 месяцев назад+2
Both! I try not to dig too much into nomenclature, so here’s a concrete example: you need to accept payments using different providers. I like to approach this by having a “PaymentService”, or “PaymentGateway” interface. Similar to the videos. Then I might have a “StripeGateway”, “NmiGateway”, etc. If the logic is simple, then maybe everything is encapsulated inside that class. More often than not, it isn’t that simple, so I end up also creating objects solely responsible for talking to these providers, and they’re not aware of the “PaymentGateway”, which is an app-level concern. Payment Gateways take inputs that are relevant to their context, map them to something the actual integration will understand, and then parse that response. For example… you might have a SaleRequest for NMI using Saloon that takes a certain object shape and returns a PSR-7 Response. I’d like to have that integration work by itself, and not be coupled to anything. Then, on my Gateway, or Service, whatever you want to call it, you can take a common object between all implementations (since it follows the contract), map it to something that “SaleRequest” understands, and then map its response back to something that your app understands. In short: Your domain is aware of PaymentGateway Specific payment gateways are aware of its integrations (e.g NmiGateway is aware of Nmi\SaleRequest) Nmi\SaleRequest isn’t aware your app even exists Your domain is not aware of Nmi or any other specific implementation I’m on my phone and I’m not sure it made a lot of sense in writing. I can try making a diagram or some code examples later. 👍
A very wonderful video, this is purely adapter design pattern. Nice to see more example about it
Glad you like it!
Keep them coming! Super informative!
Thanks! Will do!
Great job, Mateus! Any plans on doing something related to Rails anytime soon? Big fan over here, keep it up!
Fakes are indispensable in my opinion and I've started moving away from mocks whenever I have situations like this. Also, just watching your video made me think that a fake of an implementation is a sister of the Null Object Pattern. While used differently, they're of the same species at least. In addition to this, this is a great way to Mr. Miyagi someone into understanding the strategy pattern!
thank you!
Nice! I really dig this way of working.
Question: Are you always using "Providers" to integrate with 3rd party solutions or do you also use "Services"? Sometimes I think it's hard to see the difference 😅
Also, would love to see a video of how to test each of the implementations. Would you in those cases use mock with http fake to fake the expected output of the api?
Both!
I try not to dig too much into nomenclature, so here’s a concrete example: you need to accept payments using different providers.
I like to approach this by having a “PaymentService”, or “PaymentGateway” interface. Similar to the videos. Then I might have a “StripeGateway”, “NmiGateway”, etc.
If the logic is simple, then maybe everything is encapsulated inside that class. More often than not, it isn’t that simple, so I end up also creating objects solely responsible for talking to these providers, and they’re not aware of the “PaymentGateway”, which is an app-level concern.
Payment Gateways take inputs that are relevant to their context, map them to something the actual integration will understand, and then parse that response.
For example… you might have a SaleRequest for NMI using Saloon that takes a certain object shape and returns a PSR-7 Response. I’d like to have that integration work by itself, and not be coupled to anything.
Then, on my Gateway, or Service, whatever you want to call it, you can take a common object between all implementations (since it follows the contract), map it to something that “SaleRequest” understands, and then map its response back to something that your app understands.
In short:
Your domain is aware of PaymentGateway
Specific payment gateways are aware of its integrations (e.g NmiGateway is aware of Nmi\SaleRequest)
Nmi\SaleRequest isn’t aware your app even exists
Your domain is not aware of Nmi or any other specific implementation
I’m on my phone and I’m not sure it made a lot of sense in writing. I can try making a diagram or some code examples later. 👍
Also - do you use a factory pattern like managers (or drivers) and could you show a bit more about that as well as a Null object pattern?
Yeah I’ll add it to the backlog 👍
I tried to listen but the cat made too much noise.
he’s noisy!