giovedì 16 aprile 2015

Naming mostly-abstract implementations

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...).