I've just added yet another 3rd-party component to my .net project that contains a class called Client and it got me thinking about common class names.
Do you name your public classes something as common as Client, or do you try to make the name more specific?
In the past I would have said Client was fine, since it can always be accessed explicitly via its namespace (Company.Product.Client) but MS seem to stick to more descriptive class names in the .net framework, such as WebClient, TcpClient and SmtpClient.
I think names like MessagePub.Client look quite neat, and MessagePub.MessagePubClient much less so, but then having lots of Clients floating about also feels quite messy.
All of these 3rd-party components I'm using are actually open source, so is it recommended to refactor and change their class names to something more descriptive to make my code more readable or is accessing via their namespace a better idea? Or does it just not matter? :-)
I think a more descriptive name almost always is better. Its not just a technical issue, but certainly also a semantic one : for one thing it obliges you to think what kind of class you're dealing with exactly and helps you to set the boundaries.