Names and Namespaces - my dilemma
Writing Gravyframe has been a great learning experience. I have been able to experiment with different ways of doing things, but have been at a bit of a dilemma when it comes to choosing a good name for the types of my business objects. It’s not hard to choose names, type names should be nouns after all explaining what they represent.
Let’s take the example of News, News is a good name, it’s short and is self-explanatory. My dilemma arises when you extend the type for use in a particular concrete implementation. Gravyframe has a collection of services to fulfill different requirements a website might have, and one of them is news. There is a base type for News objects that has common properties, however an implementation of the news service for Umbraco will need extra properties on News that only the implementation needs and should know about. I have been asking myself, “What should I call the News type for the Umbraco implementation?”
My first answer is UmbracoNews, and that is what it is called currently. This name does not sit with me well though, because UmbracoNews is in the Gravyframe.Models.Umbraco namespace. I am just repeating myself by including Umbraco in the type’s name. I want to change this to just News and the context of the name space will supply the rest of the information. My only concern with removing context from the name and using the namespace is readability and understandability.
I think with our powerful IDEs it should not be an issue removing the context from the name and relying on the namespace. Now that I am thinking about this there is other places in Gravyframe where this is also something to consider. The Gravyframe.Service.News namespace has a type called NewsService, is this a good thing or not? After all the namespace already gives me that information. I think this blog will spawn a large refactoring of names over the next few weeks and I will report back on what I end up doing.