6 ms·

It's just basic separation of concerns. I've seen too many development organizations brought to their knees by the fact that they don't have any layering betwee

It's just basic separation of concerns. I've seen too many development organizations brought to their knees by the fact that they don't have any layering between their logic and the libraries/frameworks they use. It's a very real problem.

e28eta 13y ago
That's interesting. I don't have much experience with it, but when I've seen similar stuff it looked like an anti-pattern to me. Why should developers need to learn your specific wrapper on top of a popular 3rd party component? The internal thing is most likely not documented as well, and common problems don't have answers on Stack Overflow. It requires extra work to use additional features of the library. I'm similarly wary of convenience libraries that provide marginally simpler APIs on top of standard libraries. I'm not convinced it's a good idea. I wish I had your experience. Any good reading material?
- philbarr 13y ago
  > Any good reading material? "Working Effectively With Legacy Code", by your esteemed parent poster... :)
- hand_of_henry 13y ago
  Chapter 8 of Clean Code. Anything on the Adapter pattern. Wrapping a library in your own concept allows you to define what's right for your application. It has the effect of pushing the third party library out to the edges of your system, replaced with whatever you wrapped it with. This makes replacing it, for testing or any other reason, much easier than if it's proliferated throughout your code unwrapped. Wrappers should be simple so creating them and documentation, beyond a few integration tests to understand how the library works, shouldn't be a huge concern. I've been doing a lot of Javascript stuff lately and libraries like Dojo have 5 different ways to locate an element in the DOM. I have no idea if all these ways will be around in a future release, or, right now, which one is better. Unifying the Dom select code behind our own interface keeps things uniform throughout the app, instead of each of us using a different function, and lets us try out the different library functions, or different libraries, easily.
michaelt 13y ago
Let's say I'm using the libraries joda-time, log4j and junit. Currently I'm using them directly. How should I be doing it?
einhverfr 13y ago
But where design comes into place is to determine where and when you need to separate these concerns. There are always times to do this. There are also times not to. For example (Perl example here), in LedgerSMB we layer some things. We layer the templating engine. We layer (now, for 1.4) arbitrary precision floats. We layer datetime objects. Many of these are layered in such a way that they are transparent to most of the code. But there are a lot of things that aren't layered because there isn't a clear case for so doing right now. (As a footnote, PGObject requires that applications layer the underlying framework because there are certain decisions we don't feel comfortable making for the developer, such as database connection management.)

e28eta 13y ago

That's interesting. I don't have much experience with it, but when I've seen similar stuff it looked like an anti-pattern to me. Why should developers need to learn your specific wrapper on top of a popular 3rd party component? The internal thing is most likely not documented as well, and common problems don't have answers on Stack Overflow. It requires extra work to use additional features of the library. I'm similarly wary of convenience libraries that provide marginally simpler APIs on top of standard libraries. I'm not convinced it's a good idea. I wish I had your experience. Any good reading material?

philbarr 13y ago
> Any good reading material? "Working Effectively With Legacy Code", by your esteemed parent poster... :)
hand_of_henry 13y ago
Chapter 8 of Clean Code. Anything on the Adapter pattern. Wrapping a library in your own concept allows you to define what's right for your application. It has the effect of pushing the third party library out to the edges of your system, replaced with whatever you wrapped it with. This makes replacing it, for testing or any other reason, much easier than if it's proliferated throughout your code unwrapped. Wrappers should be simple so creating them and documentation, beyond a few integration tests to understand how the library works, shouldn't be a huge concern. I've been doing a lot of Javascript stuff lately and libraries like Dojo have 5 different ways to locate an element in the DOM. I have no idea if all these ways will be around in a future release, or, right now, which one is better. Unifying the Dom select code behind our own interface keeps things uniform throughout the app, instead of each of us using a different function, and lets us try out the different library functions, or different libraries, easily.

michaelt 13y ago

Let's say I'm using the libraries joda-time, log4j and junit. Currently I'm using them directly. How should I be doing it?

einhverfr 13y ago

But where design comes into place is to determine where and when you need to separate these concerns. There are always times to do this. There are also times not to. For example (Perl example here), in LedgerSMB we layer some things. We layer the templating engine. We layer (now, for 1.4) arbitrary precision floats. We layer datetime objects. Many of these are layered in such a way that they are transparent to most of the code. But there are a lot of things that aren't layered because there isn't a clear case for so doing right now. (As a footnote, PGObject requires that applications layer the underlying framework because there are certain decisions we don't feel comfortable making for the developer, such as database connection management.)