Blog - BlogPost - BlogPostComment vs Blog - Post - Comment

Question

Don't really know how to formulate the title, but it should be pretty obvious from the example.

More specifically, what rules do you use for naming "dependent" classes. For example, Blog is a pretty descriptive name itself, but how do I deal with posts? BlogPost or Post? Clearly, first name clearly expresses that it's a "subordinate" class, but this can quickly get out of hand with BlogPostComment, BlogPostCommentAttachment, etc. Post, on the other hand, looks like an entity completely unrelated to Blog and is easier on the eye.

What are your rules/best practices?

Answer 1

I personally like the latter best. And wouldn't a good namespace-name disambiguate Post?

Answer 2

In the case you mention, the problem is so well known as it makes no difference to be terse, and it actually saves you typing. Other types of relationships between classes aren't so cut-and-dry.

Another plus to using "Blog", "Post" and "Comment" is that you could reuse Post and Comment for other stuff not necessarily blog-related, and they'd fit better there (ok, it's just a rename anyway).

My rule would then be 'be as clear as you can'. I do tend to assume that, before you come barging in on my code, or I start a project guns ablaze, we have read a bit about the problem space.

Furthermore: most web frameworks I know make things much easier to use terse names like Blog, Post, etc. for model names.

Answer 3

Interesting question. I would use either depending on the situation.

For example a simple News and NewsItem would be fine as it's a basic model and the naming convention makes the relation clear in this case.

However, for larger developments with more complex domain models and well maintained namespacing (for example a blog) I would say it's must less convoluted and cleaner to name the types Blog, Post, Comment.