Sorry for the confusing title - this is best illustrated by an example (hypothetical but hopefully illustrative).
For 99% of my application a Zip Code is considered as a string, so I consistently use the name zipCode for parameters, variables, property accessors etc. (obviously with initial capitalization as appropriate)
However, for the 1% of my application that needs to understand the internals of a zip code (e.g. for mapping), I need a ZipCode class. The natural naming convention is to use the name "zipCode" for a variable of type ZipCode.
This creates an inconsistency which is a code smell for me - sometimes a variable called zipCode will be a string and sometimes it will be a ZipCode object.
I could go through my whole code base and use only ZipCode objects everywhere, but that seems excessive as most of the time I only need the string representation, and there are some times when I must use a string (e.g. a URL parameter)
Alternatively I could call my class something like ZipCodeObject, or I could always use zipCodeString when referring to it as a string, but both of those seem like a bad naming convention too.
My current pragmatic solution is to use the name zipCode for both. Only if a method or class needs to have awareness of both representations, then I use the variable name zipCodeObject or zipCodeString to differentiate.
Does anyone else have a better solution to this conundrum?