Hacker News Reader

Comment by DrJokepu | Hacker News Reader

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?

View on HN

I 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.

Yeah, but good luck trying to reuse the same basic instructions to scan non-paper objects without multiple inheritance.

Ruby does this with mixin modules :)

     interface ICopyable {...}

Back in the days at PARC, that was "IXeroxable".

See: Mixins, Traits, Apects. Whatever your language wants to call them, they're fundamentally the same, and solve the issue you're raising.

I 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?

Agreed. 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?)

It 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?

    what 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.

In 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.

He does say, at the end of the piece, that nouns that happen to end in -er are an exception.

Aren't all words which end in -er, and used as class names, nouns ?

Sorry. Meant to upvote you, but downvoted by mistake.

> Guess what a photocopier does? Or a scanner? An eraser? An elevator?

Or a Coffee-Maker... Instant factory pattern.

Reply on news.ycombinator.com