3 ms·
How is that different than the Gateway pattern that he mentions in the logging example? Lets say I was going to ship something building on what this article ta
by emehrkay 13y ago
How is that different than the Gateway pattern that he mentions in the logging example?
Lets say I was going to ship something building on what this article talks about. Instead of interacting directly with my shipping objects (Fedex, Usps, etc), I'd write a common interface for them (ShippingGateway). In addition Id need so sort of mapper for each shipping object that would translate my ShippingGateway calls to the respective object (FedexMapper etc).
My code would eventually look like:
shipping = new ShippingGateway(...)
estimate = shipping.estimate(address, 'fedex', ...)
and that should never have to change only the mappers and objects themselves would. What am I missing?
- AndrewDucker 13y agoIt's slightly more. Your code wouldn't create it's own ShippingGateway - it would be passed in (or "injected"). That Shipping Gateway could be a RealShippingGateway (for when the application is running in production) or a MockShippingGateway (for unit testing), or some other variant for when your test users don't want to actually ship things. It doesn't matter which of those it is to the object it's passed into, all it knows is that it has a ShippingGateway, and when/how to call it. So it's Adapter Pattern + Interfaces together that matter.
- emehrkay 13y agoMakes sense. So basically this is DI for adapters/gateways?
- AndrewDucker 13y agoThat's my understanding. But I'm not 100% I haven't missed some subtlety.
- stonemetal 13y agoClick through the gateway link. Notice the direction of the Arrows. Your high level code is still directly dependent on the current low level implementation. The "Gateway pattern" is nothing more than create an abstraction so your code can work with domain concepts instead of directly with the API. Now look at the arrows in the DIP example. There is an inverted arrow by comparison to the gateway diagram. This is because you have inverted the dependency so that your high level code no longer depends directly on the implementation.