6 ms·
I disagree with this advice and the reason I disagree with it because it completely disregards the human tendency to name objects (not OOP objects, but real-lif
by DrJokepu 15y ago
I disagree with this advice and the reason I disagree with it because it completely disregards the human tendency to name objects (not OOP objects, but real-life objects) based on their functionality. Guess what a photocopier does? Or a scanner? An eraser? An elevator? I don't think these are particularly bad names; quite the contrary, their meaning is very clear.
Why would it be any different for OOP objects? If there's an object with an internal state that chiefly responds to messages about scanning things, what's wrong with calling it NSScanner?
- nhebb 15y agoI was going to write basically the same thing. I used to combine data and action in the same classes but recently have begun refactoring them out into separate data and "-er" classes. Maybe somewhere an OOP purist is frowning, but I really prefer this naming convention. My FlowchartShape class included methods for formatting and positioning. I now have a FlowchartShapeFormatter class and a FlowchartShapePositioner class. Guess what they do?
- pgroves 15y agoAgreed. The reason I end up with some '-er' classes is to separate out immutable definitions and the classes that work on the definitions. In your example, by making the FlowchartShape a simple definition class, you can then write that to a file or send it over the network as a snapshot of the state of the -er classes. If the article's advice was taken, you'd end up renaming WebServer to be WebPage, but then would have nothing to name a WebPage. (Maybe WebPageSnapshot?)
- glhaynes 15y agoIt doesn't seem like it'd be any more difficult to write the FlowchartShape to a file or send it across the network if it had additional methods on it to manipulate and use its state, so I'm not sure what's gained by making two+ separate classes... what am I missing?
- kscaldef 15y agowhat am I missing? That it's quite possible that you don't want the guy on the other side of the wire to call those methods on the object. I find I quite frequently want to share a data model between my client and server code, but I certainly wouldn't want to expose all the stuff that the server does to those objects to the client directly.
- glhaynes 15y agoIn my experience, it seems like the vast majority of the time in which that would be the case, one isn't doing a native ("binary") object serialization such as would require the receiver to have the object code for the serialized class(es), but instead using some sort of intermediate format like JSON or XML or the like. But I suppose there might be instances... I just hate to throw away such a fundamental OOP concept as bundling of data and the methods that operate on that data unless there's a really good reason.
- ams6110 15y agoHe does say, at the end of the piece, that nouns that happen to end in -er are an exception.
- vinutheraj 15y agoAren't all words which end in -er, and used as class names, nouns ?
- kenjackson 15y agoSorry. Meant to upvote you, but downvoted by mistake.
- pyrhho 15y ago> Guess what a photocopier does? Or a scanner? An eraser? An elevator? Or a Coffee-Maker... Instant factory pattern.
- sethg 15y agoI think in the author’s ideal world, we would not have Photocopier, Scanner, and Eraser objects, but rather a Paper object that can copy, scan, and erase itself.
- languagehacker 15y agoYeah, but good luck trying to reuse the same basic instructions to scan non-paper objects without multiple inheritance.
- epochwolf 15y agoRuby does this with mixin modules :)
- ori_b 15y agointerface ICopyable {...}
- SimHacker 15y agoBack in the days at PARC, that was "IXeroxable".
- encoderer 15y agoSee: Mixins, Traits, Apects. Whatever your language wants to call them, they're fundamentally the same, and solve the issue you're raising.