Still creating objects ending with 'er'

A couple of weeks ago I came across a blog entry giving an interesting advice for programmers. The advice is as follows:  

Don't make objects that end with 'er'. 

The thing was really surprising for me due to a pair of simple reasons: firstly, I do pay reasonable attention to proper naming while creating programs and do aknowledge the importance of names - moreover due to lack of experience I am interested in exploring different naming practices and conventions, and secondly, I've made plenty of objects that end with 'er'. The blend of these two reasons made me stumble over the article and remember it.

Each time I was writing design papers or code subsequently I remembered the advice. I really tried avoiding the "improper" names, however the result didn't satisfy my. The matter is that avoiding 'er' objects brought me to names describing processes or actions and, although I think that's the authors point, kind of thing he wants me to do (I'm not really sure about his opinion - that's the way I get it), I don't like it actually. For me there is substantial difference between objects and processes or actions. Although this idea seems simple and obvious, it wasn't that easy for me to explain the difference. I suppose an example from some distant field may help.

Consider manufactoring some product - shining Audi A8 car for example. Each Audi A8 is definitely a result of huge efforts made by lots of people and machinery: such a thing usually starts from creating concept, which is followed by developing design, building prototypes, testing, buying materials and outsourced parts, deploying machinery, building up transport network and so on. Each of these activities as well as the whole thing may be considered a process. Our programms usually do the same: they test something, build things, throw it from here to there, assemble them into greater things etc. - so we do deal with processes while programming and it would be strange to disagree with that.

Nevertheless getting back to our manufacturing example we'll see that it's not about processes only - every executive from Ingolstadt will actually mention people as an important thing involved into manufacturing process. Moreover if you speak to some Audi's department chief you'll hear words like machinery, resources, supplies, whatever. Every manufacturing process is linked to these things and highly depends on them. For me it's more usual to consider this kind of things objects, so, from my point of view, object is not the process itself - it is the whole bunch of things that makes the process go, assembles somehow independant actions into the process. In the case of manufacturing Audi cars objects are plants and workers, engineers and design papers, department chiefs and departments themselves, parts and machinery, while the processes are designing, testing, welding, dying, assembling, managing and so on.

Moreover we can see that after dying one Audi a german painter may dye another one, so he is definitely not a process - he implements actions which taken together form a process of painting a car. So an object is something that gets some other things (which may be objects too) and then, usually step by step, performs some actions with them resulting in new things produced. Some of these steps taken together may be considered a process and thus may be granted corresponding name like PaintCar, although the man who performed this actions sequence is still named Painter.

For me the described distinction is enough important to continue creating 'er' objects, because their names will ensure me that the object with such a name is really an object - not a process, so it can either be used in some process or perform some process itself. I feel more comfortable dealing with Painters or Drivers which can Paint or Drive than dealing with mere Paint or Drive - such an approach seems to emphasize distinction between processes and objects at least.

One more idea to mention: consider the famous GoF book filled with Object Oriented Design Patterns. The book definitely deals with objects - in fact all the patterns are objects and there are some ending with 'er'. I am pretty sure that the names chosen by GoF well describe the essence of the corresponding patterns.

In the end the issue may be just matter of taste, although my taste says that objects' names should mostly consist of nouns and adjectives - not verbs. Actually, saying who are you (e.g. programmer), you say what you do (e.g. create programs) accordingly, thus 'er' names do describe both objects and their activities well meanwhile emphasizing that you're dealing with object - not a mere actions sequence. Somehow it describes my understanding of Object Oriented programming paradigm.