Naming mostly-abstract implementations - Google Gruppi: "If it's hard to think of a name for a class, I sometimes find it helpful to inline everything back to an unstructured mass, and then extract different methods and classes back out again. Removing existing structure helps me see opportunities for a better new structure. And inlining and extracting is very easy in refactoring IDEs.
...
Interfaces that end in "Manager" or "Service" are a strong hint. Interfaces named like this often define what I call a "CRAP" -- a Class That's Really a Procedure" --
...
Two techniques I find useful are:
- Define interfaces to identify only what clients need, not what implementors provide.
...
- Name interfaces in domain terms of the client, rather than using technology terms, pattern names, or vague words such as "Manager" or "Service". This ends up guiding the code towards a Hexagonal architecture (or hexagons within hexagons within...).
--Nat"
