In the spirit of giving other devs the benefit of the doubt, let's assume that when you just look at the presence of a particular string in a codebase that you'

In the spirit of giving other devs the benefit of the doubt, let's assume that when you just look at the presence of a particular string in a codebase that you're not familiar with, there's a good chance that you not knowing why it appears doesn't mean that there's no reason why it appears. As far as possible problems you could be working on where an AbstractAdapterFactory might be useful, a couple I can think of off the top of my head: Needing to work with a couple different but similar file formats. Needing to work with a couple different email services. Needing to support a couple different identity providers. Needing to couple new code to a legacy service in an enterprise application. In each of those cases, I'd also say the number of random protocols you might need to deal with before an AbstractAdapterFactory might become useful is 2. As soon as you've got a 2nd protocol to support, you open up the possibility that your languages type system could save you from having to bang out a lot of fiddly, brittle if-statements. And if there's any chance that you've got more than one different situation where that's useful, then it might already be worthwhile to take those different adapter factories and factor out a common, defined interface. Perhaps not because you'd ever actually use a reference that's typed to that interface, but just because it promotes standardization so you don't get a bunch of different devs dirtying up the project's code and semantic space with a bunch of different custom interpretations of the pattern.