Finally, I had to ask this. Whenever I pop open a MSDN sample I see classes grouped under one file. I rarely do this, I do it while I’m trying things out, but move them out. Sometimes, just for illustration purposes when I write up examples, and its a rather small project, I will have the classes in the same file to make it easier to display the code in the blog entry. But I’ve seen this in quite a few ‘real life’ projects- and there might be a reason as to why?
On stackoverflow a few issues are discussed, such as checking in files – if you have multiple classes in a file it’s not that easy to spot what was changed. Another issue is that classes should be decoupled, and having them in one file signals that they are coupled, which they shouldn’t be- at the same time there are times when it is unavoidable to have coupled classes.
One user commented that he does sometimes do that when the classes are tightly coupled, but that it is a good rule not to. When asked why he has tightly coupled classes he answered: It’s called avoiding overengineering. If you have a few tightly coupled classes and decoupling them would add a lot of complexity compared to the amount of practical flexibility it provides, then what’s the point?
Quite interesting, and a fair comment I think. I’m curious if more devs have any thoughts on this? I’ve chosen to keep them separate , unless it’s just to illustrate something as I mentioned above.