> + *
> + * Unless required by applicable law or agreed to in writing, software
> + * distributed under the License is distributed on an "AS IS" BASIS,
> + * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
> + * See the License for the specific language governing permissions and
> + * limitations under the License.
> + */
> +package org.jclouds.googlecomputeengine.domain;
> +
> +import static com.google.common.base.Objects.equal;
> +import static com.google.common.base.Preconditions.checkNotNull;
> +
> +/**
> + * @author Adam Lowe
> + */
> +public class MachineTypeInZone extends SlashEncodedIds {> should it move to org.jclouds.googlecomputeengine.compute.domain That would still be in a domain package, and that's what doesn't feel quite right to me. `RegionAndName` may well be a couple of IDs encoded with a slash, but the name represents a _domain_ concept, not a _type of representation_. I couldn't find any reference in the API docs to a first-class concept called "SlashEncodedIds" (but didn't look very hard), hence the feeling that this doesn't really belong. If we were doing something like Scala I'd say this looks more like a _trait_ than a _parent class_. In Java, my gut feel would be to extract the encoding logic into a `util.SlashEncodedIds` class and simply call that, rather than making it part of the inheritance hierarchy. If necessary, this could be `implements SlashEncodedIds` if we want to impose some kind of "contract". Does that make some kind of sense? --- Reply to this email directly or view it on GitHub: https://github.com/jclouds/jclouds-labs/pull/16/files#r5380268
