I wish the author had provided more examples of the kind of code they wish had not been written because "it might change in the future", because I'm not quite s

I wish the author had provided more examples of the kind of code they wish had not been written because "it might change in the future", because I'm not quite sure what they're advocating against. Wrapping external libraries ? It depends on the level of maturity of the library. I have seen HTTP libraries change their API often enough for a long time. I wrapped them because it did _change_. (Although I'd rather have fetch_my_foo wrapping calls to the lib that does http call, rather than having fetch_my_foo calling a wrapper that calls a lib) Wrapping input / output ? That can have _some_ uses in testing (Although it might be better to have unwrapped code doing the I/O, calling code that does the logic.) Hiding a class behind an interface that will only have a single Impl ? It the class is doing I/O, it might very well need at least a test implémentation. 'new FileInputStream(new Buffered stream(new Buffer(new Encoding( new ...' ? Yeah, this is typically the case where a proper API need to have 'File.read("xxx")' from the get go rather than force people to either wrap or share a wrapper. Etc,etc...