4 ms·

I read it and I don't quite understand it. Many of Fowler's articles have a point where it just clicks and I want to rewrite my code (I'm looking at you event s

I read it and I don't quite understand it. Many of Fowler's articles have a point where it just clicks and I want to rewrite my code (I'm looking at you event sourcing), but this one didn't. Both the logging and database examples made perfect sense, at this moment I can't relate it to the overall concept

jfb 13y ago
It's gibberish.
AndrewDucker 13y ago
Do the two examples connect as part of a common theme for you? To me they seem related as in both cases you're ensuring that each part of the code only has to deal with functionality it directly cares about, through interfaces that ensure that it isn't overloaded with extra information. (I hate the name though. Because that's never clicked with me at all.)
- 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 ago
    It'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 ago
      Makes sense. So basically this is DI for adapters/gateways?
      - AndrewDucker 13y ago
        That's my understanding. But I'm not 100% I haven't missed some subtlety.
  - stonemetal 13y ago
    Click 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.
tbrownaw 13y ago
1. None of your objects should know how to create objects from other modules (just in case you happen to need the flexibility later). 2. Everything used in the same place should use the same set of concepts (aka "level of abstraction", even tho abstractions can't always be split into clear levels). So instead of your code knowing how to do something simple like create and use a database connection, you pass it a wrapper around a database connection and have it know how to use (but not create) that instead. I'm not entirely clear on where the inversion-of-control (framework vs library) part fits in tho...

jfb 13y ago

It's gibberish.

AndrewDucker 13y ago

Do the two examples connect as part of a common theme for you? To me they seem related as in both cases you're ensuring that each part of the code only has to deal with functionality it directly cares about, through interfaces that ensure that it isn't overloaded with extra information. (I hate the name though. Because that's never clicked with me at all.)

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 ago
  It'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 ago
    Makes sense. So basically this is DI for adapters/gateways?
    - AndrewDucker 13y ago
      That's my understanding. But I'm not 100% I haven't missed some subtlety.
- stonemetal 13y ago
  Click 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.

tbrownaw 13y ago

1. None of your objects should know how to create objects from other modules (just in case you happen to need the flexibility later). 2. Everything used in the same place should use the same set of concepts (aka "level of abstraction", even tho abstractions can't always be split into clear levels). So instead of your code knowing how to do something simple like create and use a database connection, you pass it a wrapper around a database connection and have it know how to use (but not create) that instead. I'm not entirely clear on where the inversion-of-control (framework vs library) part fits in tho...