4 ms·

There's case for having a "convenience" or "easy mode" wrapper where the amount of configuration is lower, hence the underlying dependency is more straightforwa

There's case for having a "convenience" or "easy mode" wrapper where the amount of configuration is lower, hence the underlying dependency is more straightforward to reuse. For example, I would point to 3D graphics APIs as a reasonable case for this. All the ones in use today assume a lot of low-level detail about buffers and pointers and strides and attribute flags, which makes building up test cases challenging: you have to consider dozens to hundreds of options, and setting one wrongly will result in no image or a crash. So, instead, many folks turn to copy-paste of known working examples, give them a minimal amount of additional configuration, and extend that into the frontend that they habitually use, rather than directly accessing the API in question. The full power is still there - it's not really abstracted - but the workflow has been pushed towards the average case.

Nursie 8y ago
I wouldn't necessarily consider that a wrapper, personally, but a reasonable set of functionality behind an interface to said functionality. The only thing I'm really arguing with is the insistence that one should wrap everything as a matter of course. Reduction of complexity, like your example, is great. Increasing levels of indirection thoughtlessly is adding to it, IMHO.
- jstimpfle 8y ago
  But that's exactly what I was describing all the time...
  - Nursie 8y ago
    I got the impression you were saying every dependency should always be wrapped, regardless. I was a C coder for many years, these days I seem to be doing java. There are dependencies in my recent projects that just do what I need, no particular domain translation required. Particularly things like the Apache commons libraries, which provide well formed utilities for common operations. It would be a waste of time and energy to wrap them simply for the sake of having a wrapper. If this sort of thing isn't what you were driving at, then we've just been miscommunicating. I am 100% for encapsulation of functionality into good, discrete modules which provide sensible interfaces and minimal (but expressive APIs). I just don't like the blind application of "this isn't our code therefore we must provide an interface"
    - jstimpfle 8y ago
      Yes I wouldn't wrap a Hashmap or anything I can write myself in less than 100 lines. Particularly if it has a simple and familiar interface.

Nursie 8y ago

I wouldn't necessarily consider that a wrapper, personally, but a reasonable set of functionality behind an interface to said functionality. The only thing I'm really arguing with is the insistence that one should wrap everything as a matter of course. Reduction of complexity, like your example, is great. Increasing levels of indirection thoughtlessly is adding to it, IMHO.

jstimpfle 8y ago
But that's exactly what I was describing all the time...
- Nursie 8y ago
  I got the impression you were saying every dependency should always be wrapped, regardless. I was a C coder for many years, these days I seem to be doing java. There are dependencies in my recent projects that just do what I need, no particular domain translation required. Particularly things like the Apache commons libraries, which provide well formed utilities for common operations. It would be a waste of time and energy to wrap them simply for the sake of having a wrapper. If this sort of thing isn't what you were driving at, then we've just been miscommunicating. I am 100% for encapsulation of functionality into good, discrete modules which provide sensible interfaces and minimal (but expressive APIs). I just don't like the blind application of "this isn't our code therefore we must provide an interface"
  - jstimpfle 8y ago
    Yes I wouldn't wrap a Hashmap or anything I can write myself in less than 100 lines. Particularly if it has a simple and familiar interface.