One of the arguments for doing it this way is that having three examples to abstract from is more likely to give a generally useful abstraction than the first two. It's not a hard and fast rule though - sometimes when you need the second instance, it's obvious there will be more later, sometimes you find several instances later that the abstraction could be improved and go back to the first few instances to refactor them.
And trying to force a specific use case that doesn't really fit to the wrong abstraction because otherwise you might repeat some bits of it is a symptom of the same problem. Sometimes it means your abstraction would benefit from having parts refactored out separately, sometimes it's better just to have a comment saying "this looks like , but that's not a good fit because ". But if you find the same comment being written three times, rethink the refactor....
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
One of the arguments for doing it this way is that having three examples to abstract from is more likely to give a generally useful abstraction than the first two. It's not a hard and fast rule though - sometimes when you need the second instance, it's obvious there will be more later, sometimes you find several instances later that the abstraction could be improved and go back to the first few instances to refactor them.
And trying to force a specific use case that doesn't really fit to the wrong abstraction because otherwise you might repeat some bits of it is a symptom of the same problem. Sometimes it means your abstraction would benefit from having parts refactored out separately, sometimes it's better just to have a comment saying "this looks like , but that's not a good fit because ". But if you find the same comment being written three times, rethink the refactor....