3 ms·

I am unconvinced. Any absolute deserves close scrutiny, and "real nouns only" is an absolute. In this case, it fails my test. I find that many things I work wit

by mcherm 15y ago

I am unconvinced. Any absolute deserves close scrutiny, and "real nouns only" is an absolute. In this case, it fails my test. I find that many things I work with (especially huge Java libraries) tend to have convoluted and difficult-to-understand webs of classes with the most confusing pieces named things like "FooManager" or "FooController". So the author of this piece is reacting to a genuine excess. But Travis is overreacting. The REAL goal is to find a collection of abstractions that is powerful enough to accomplish what the program requires but as simple as possible (and as local as possible) to allow humans to comprehend (and maintain) it. There are quite a few times when I have found that one of these "verb-like" abstractions (a word ending in "-er") made things more comprehensible. For example: the Gang-of-Four patterns "Builder" and "Observer" both end in "-er" and strike me as being well-named. "Builder" is an object with no purpose other than to create (initialize) another object or data structure. HAVING such an object is useful when something requires extensive setup or initialization, because it is easier to understand if the extensive initialization is kept separate from the core functionality. "Observer" is the name for an interface of things that observe... the names of interfaces FREQUENTLY work well as "verbs" since the interface frequently represents "anything that does X". Similarly, I have often had a class such as "DatabaseConnection" and then created "DatabaseConnectionWrapper" -- a class whose purpose is to wrap a DatabaseConnection to do something like logging, error reporting, pool flushing, driver-bug-patching, and so forth. Suggestions that I call these "LoggingDatabaseConnection", "ErrorReportingDatabaseConnection" and so forth misses the key point: a different mix of features may be required at different times (eg: logging in QA but not in Prod); the fact that they are transparent wrappers that can be added (or not) in any order is a key feature of the design. So my own advice would be weaker than Travis'. Instead of "Don't make objects that end with -er.", I would say "Be wary of confusing objects; those ending in -er are often confusing."

pestaa 15y ago
I think there is a more fundamental misunderstanding in OO than bad naming convention. You are right about the usefulness of -er named objects -- but then again, are they really objects, or just functionality wrapped into a wrongly chosen language construct? Following your example, you could have implemented the strategy pattern into DatabaseConnection to freely inject functionality into the object when X happens. Assuming these functions do not have additional data members other than the parent object, they easily can be simple functions or even lambdas. (Of course it's easier to restrict to classes, because you can validate against interfaces in case a function signature doesn't cut it.) What Travis is suggesting, when you have an object that defines both data and behavior, the object context should be determined by the data, not the behavior. If done properly, you end up with less names that end in -er.
- deleted 15y ago
  [deleted]
- diminish 15y ago
  Most OO examples talk about commonly known external objects; yet programmers need to invent classes for objects too, because they are inventing and classifying an unclassified world. So they create Drivers, Managers etc; I agree with Travis to certain degree, but on the abstract object creation sometimes objects are identified by behavior rather than data; especially data manipulating objects; queue managers, drives ... I sometimes think human language is not enough for programmers, and there must be an easier way to create non-existing objects; maybe similar to German language word creation.
- mcherm 15y ago
  There are many times when the objects really do have both data and behavior -- glancing at the real code that was the basis of my example, I see that the LoggingDatabaseConnection has real state (the place to log to) and the pool flushing one has real state (keeps track of open cursors so they can be auto-closed when it is returned to the pool). Of course, you also could be (and I was) using a deficient language like Java which doesn't HAVE any way to use a function or lambda. But I agree with you: a simple lambda a better solution where it is available. And this kind of use is quite far from what Alan Kay intended when he designed SmallTalk. The original idea was that the objects would correspond to real-world entities. I would contend that since then OOP has evolved, and now the key idea of an object is the pairing of data and methods. Choosing the abstractions which will make the code most readable is one of the great challenges of programming well, and I find that just going for the nouns every time is NOT the best answer.
vl 15y ago
>The REAL goal is to find a collection of abstractions that is powerful enough to accomplish what the program requires but as simple as possible (and as local as possible) to allow humans to comprehend (and maintain) it. I like to think that practicing OOP in some sense is a process of defining new language and then using this language to programs something. This can be said about almost any programming in general, but in OOP you can see bad abstractions very well. The real problem of OOP is that most "average" programmers are bad at defining languages. From my unscientific observations in any large C++ project only few developers actually produce usable class hierarchies. Same applies to large Java projects to somewhat lesser degree - Java has better defined patterns and more extensive standard library.

by mcherm 15y ago

pestaa 15y ago

I think there is a more fundamental misunderstanding in OO than bad naming convention. You are right about the usefulness of -er named objects -- but then again, are they really objects, or just functionality wrapped into a wrongly chosen language construct? Following your example, you could have implemented the strategy pattern into DatabaseConnection to freely inject functionality into the object when X happens. Assuming these functions do not have additional data members other than the parent object, they easily can be simple functions or even lambdas. (Of course it's easier to restrict to classes, because you can validate against interfaces in case a function signature doesn't cut it.) What Travis is suggesting, when you have an object that defines both data and behavior, the object context should be determined by the data, not the behavior. If done properly, you end up with less names that end in -er.

deleted 15y ago
[deleted]
diminish 15y ago
Most OO examples talk about commonly known external objects; yet programmers need to invent classes for objects too, because they are inventing and classifying an unclassified world. So they create Drivers, Managers etc; I agree with Travis to certain degree, but on the abstract object creation sometimes objects are identified by behavior rather than data; especially data manipulating objects; queue managers, drives ... I sometimes think human language is not enough for programmers, and there must be an easier way to create non-existing objects; maybe similar to German language word creation.
mcherm 15y ago
There are many times when the objects really do have both data and behavior -- glancing at the real code that was the basis of my example, I see that the LoggingDatabaseConnection has real state (the place to log to) and the pool flushing one has real state (keeps track of open cursors so they can be auto-closed when it is returned to the pool). Of course, you also could be (and I was) using a deficient language like Java which doesn't HAVE any way to use a function or lambda. But I agree with you: a simple lambda a better solution where it is available. And this kind of use is quite far from what Alan Kay intended when he designed SmallTalk. The original idea was that the objects would correspond to real-world entities. I would contend that since then OOP has evolved, and now the key idea of an object is the pairing of data and methods. Choosing the abstractions which will make the code most readable is one of the great challenges of programming well, and I find that just going for the nouns every time is NOT the best answer.

vl 15y ago

>The REAL goal is to find a collection of abstractions that is powerful enough to accomplish what the program requires but as simple as possible (and as local as possible) to allow humans to comprehend (and maintain) it. I like to think that practicing OOP in some sense is a process of defining new language and then using this language to programs something. This can be said about almost any programming in general, but in OOP you can see bad abstractions very well. The real problem of OOP is that most "average" programmers are bad at defining languages. From my unscientific observations in any large C++ project only few developers actually produce usable class hierarchies. Same applies to large Java projects to somewhat lesser degree - Java has better defined patterns and more extensive standard library.