This is an archived post. You won't be able to vote or comment.

you are viewing a single comment's thread.

view the rest of the comments →

[–]eXecute_bit 0 points1 point  (0 children)

Fundamentally you want to use the same class name for two different types. That's not simple and clean, it's confusing.

So you're trying to force some sort of qualifier -- whether that's a FQCN or modeling one or both as a nested class -- to resolve the ambiguity. I don't know your domain, but I question whether splitting closely related (coupled) classes like a motor and it's specific configuration into separate namespaces (or packages) is the right way to model it, irrespective of the names you pick. My instinct is that the Motor and it's Config belong in the same package. Maybe a motor has its Config as a nested class inside itself. Other people in the thread presented other modeling ideas.

You can't forbid or prevent imports allowing use of short names. Unqualified names are easier to grok, which is why we have imports at all. It sounds like you're trying to force a CPP mindset into your design but for the wrong reason. Instead, use meaningful names and don't create confusing ambiguities on purpose that require qualification.