Return to Answer

With a using statement, like using Language or using Language.French, you can eliminate the need to call Language.Word(), and instead call Word().

This allows you to separate what entities are in what relationship, and to set them apart. These entities are grouped logically because they have to deal with language(s). This makes sense when the complexity increases. Maybe I would have a namespace for things that relate to French, and I would add French as a nested namespace under Language; e.g. Language.French.

This allows you to separate what entities are in what relationship, and to set them apart. These entities are grouped logically because they have to deal with language(s). This makes sense when the complexity increases. Maybe I would have a namespace for things that relate to French, and I would add French as a nested namespace under Language; e.g. Language.French.

With a using statement, like using Language or using Language.French, you can eliminate the need to call Language.Word(), and instead call Word().

var word = new Language.Word(); // out of namespace and even simpler

var word = new Word(); // inside namespace

var word = new Language.Word(); // if declared outside of namespace

or even simply

var word = new Word(); // if declared inside namespace

With this, naming schemas get cluttered real fast. In any large-ish application, you might have 50+ classes. Can you imagine trying to pass around data types like SortedDictionary<LanguageWord>? In my experience, long class names are hard to read, and harder to code down the line. Class names should (in my opinion) be as short as possible to represent the entity that it is modeling.

This method leaves no room for organization, which is extremely important, especially in languages like C#, Java, etc.

var word = new Language.Word();

This allows you to separate what entities are in what relationship, and to set them apart. These entities are grouped logically because they have to deal with language(s). This makes sense when the complexity increases. Maybe I would have a namespace for things that relate to French, and I would add French as a nested namespace under Language; e.g. Language.French.

With this, naming schemas get cluttered real fast. In any large-ish application, you might have 50+ classes. Can you imagine trying to pass around data types like SortedDictionary<LanguageWord>? In my experience, long class names are hard to read, and harder to code down the line. Class names should (in my opinion) be as short as possible to accurately represent the entity that it is modeling.

This method leaves no room for class organization, which is extremely important, especially in languages like C#, Java, etc.

var word = new Language.Word(); // out of namespace and even simpler

var word = new Word(); // inside namespace

This allows you to separate what entities are in what relationship, and to set them apart. These entities are grouped logically because they have to deal with language(s). This makes sense when the complexity increases. Maybe I would have a namespace for things that relate to French, and I would add French as a nested namespace under Language; e.g. Language.French.

I'll also mention that, as you see in the above example I don't need to use the prefix Language. while inside that namespace. So in ExtendedDictionary, I don't need to use Language.Word as the type in in the dictionary variable, because both entities are in the same namespace. This reduces a lot of name clutter. With the class prefix method, you can't avoid the clutter. With namespaces, it's part of the feature of the language and makes things inherently more readable.