4 ms·
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
by 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 agoMost 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 agoThere 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.