Well, I for one frequently encounter places where the factory / interface / adapter paradigm is a good solution. And, it's not just to be clever. This typical

Well, I for one frequently encounter places where the factory / interface / adapter paradigm is a good solution. And, it's not just to be clever. This typically occurs when 1) I am doing enterprise application development, and there are many different instantiations of a particular application, or 2) I am doing enterprise integration, and I have many different libraries and services to work with, sometimes legacy, and often with complex business logic that selects some over others. Granted, I've seen this pattern used all too often and seen over-abstraction, in general. But, I need to be brave and defend this, given that no one else seems to want to. It does have some legs. I use this when working with a lot of different teams / companies and coordinating them all and agreeing to how things will work in production. That's especially true when some of those teams / companies may be interchanged with others. This type of solution makes a lot of sense. However, I would much prefer a dynamic typed solution to avoid the unnecessary boilerplate. And, even better, I would prefer to work only with self-contained software companies that have complete control over their code-base and restrained domain logic. That would be awesome! (but wishful thinking).