Hacker News Reader

Comment by pgroves | Hacker News Reader

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

View on HN

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.

Reply on news.ycombinator.com