david stanek's digressions

In a previous post I complained about developers using worthless names for Classes. A couple of people called me on the fact that I never really defined what a good name is or how I come up with them. During the application design process I'll typically do a little domain modeling. Each problem space usually already has its own terminology and concepts. This is where I get the bulk of the names I use for Classes. For example, at a bank you may find terms like Customer, Account and Interest. There are also common names I use when implementing a pattern. These common names are almost always used in conjunction with a domain term. A couple of quick examples:

1. CustomerFactory
2. HttpAdapter
3. SmtpAdapter
4. AccountAdapter

This is not rocket science. As an object oriented developer I want to model a solution in terms of real world objects or at least concepts from the problem domain. Why would I call an Account a PiggyBank or a Customer a John? I wouldn't. Would you? Try asking the project stakeholder to define withdrawal rules for a John getting some spending money from the PiggyBank.