One of the things I run into regularly is naming objects, entities, classes, operations, parameters, variables, etc.
I am fully aware that it is very important to get the name right because once chosen it will always be named like that in the back of your head and when it is wrong it might cause a lot of confusion, now or in the future when the name you came up with no longer fits the object or the name got a new meaning due to a new song from some popstar or a new disease.
When naming technical software bits it is quite easy to get it right: many times a (design) pattern or mechanism provides you with a very logical and easy to remember name. E.g., Handler, Manager, View, Controller, Publisher, Client, Proxy, etc.
Functional bits are harder. Normally I’d try to find out what the business people name the object and try to stick to that. Sometimes (read: almost always) it is very hard because the business people do not agree or the the names they use were created/driven by the previous IT solution. E.g., a company selling cars uses a standard (and customized) version of an of-the-shelf webstore application. The webstore application wasn’t built with cars in mind so the application stores the cars as products. And then, after 10 years, all the business people call their cars products. Modeling (finding out attributes and operations of) cars can (and will) be very different from modeling products.
| Car | Product | |
| Attributes | Color Number of doors Fuel type Weight Maximum Speed … |
Size Weight Manufacturer Date of Production … |
| Operations | Start() Brake() Park() … |
Sell() Create() Resell() … |
A while ago I ran into this problem at a company. The business name was ‘object’. As soon as you try to envision C# code that uses this class you will understand my worries. A big problem was also that ‘object’ has such a high abstraction level and is not restricted to either the technical or function domain. Ambiguity everywhere.
So what to do? I chose to make it a bit more specific in business terms. I won’t state my solution here, I do not want to name or imply the company, but extending the car example in the same fashion: Vehicle.
For an even geekier solution I hereby propose the official renaming of object orientated:
Thing Oriented
Surely there are no businesses that sell ‘Things’, right?
I frequently encounter messages saying “How to sell things online and make money”, so I think you have to look for an other (even geekier?) solution.
By the way, I think all the attributes and operations of Product you named in your example apply to Car too …
Erno: your word was spread and a first book is already available: Thing-Oriented Programming!
http://www.springerlink.com/content/12e68nxt7elf4edw/
Awesome! I didn’t know that… too bad it was published in 2004… ah well… I honestly never heard of it before.
As for your first remark: yes, that is one of the very interesting side effects of getting the classes at an abstraction level that is too high; in the end you’ll endup with object with very generic attributes and operations. The problem is that you’ll miss out on specific attributes and operations.
An interesting book (in my opinion) that adresses the topic of matching your class model with the domain model is:
[url]http://www.amazon.co.uk/Domain-driven-Design-Tackling-Complexity-Software/dp/0321125215/ref=sr_1_1/277-5523371-0584439?ie=UTF8&s=books&qid=1260867290&sr=1-1[/url]