My co-workers tend to think that it is better to limit non-domain type suffixes to a small fixed set of OOP-pattern inspired words, e.g.:*Service*Repository*Factory*Manager*ProviderI believe there is no reason to not extend that set with more names, e.g. (some translation to the previous vocabulary is given in brackets):*Distributor (=> *DistributionManager or *SendingService)*Generator*Browser (=> *ReadonlyRepositoryService)*Processor*Manipulator (=> *StateMachineManager)*Enricher (=> *EnrichmentService)(*) denotes some domain word, e.g. Order, Student, Item etc.The domain is probably not complex enough to use specialized approaches such as DDD which could drive the naming.
Should I limit my type name suffix vocabulary when using OOP?
design patterns;object oriented;naming;conventions
You can have any vocabulary you want, as long as everyone in team understands and agrees on what it means.The reason why design patterns exist is that their names are (usually) widely known and even someone else outside your team knows what you mean when you say This is a Builder. The problem I see with your proposal is just that. I have no idea what any of those mean. If you can agree with your team that you are using some pattern and agree on what that pattern is, then giving it some fitting name is obvious final step.