Hacker News Reader

Comment by viggity | Hacker News Reader

I disagree, I'm a big fan of encapsulation/information hiding. I'd rather have this stuff hidden 20-30 classes than have 200 new classes cluttering my intellisense

View on HN

I agree with your sentiment. Further, new classes have a small (but not immeasurable) hit to performance as each object, when created, must be initialized and tracked in memory.

Now, I think he is talking about increasing the encapsulation through collaborator classes so he's not against encapsulation.

I still agree that there aren't any inherent problems with the several-private-methods-level of data abstraction. Rather, a program's level of data abstraction should follow the needs of the application as a whole.

Wait a minute. How would using a collaborator class as a "functor" for your formerly private methods improve encapsulation? At worst, if the collaborator were public, now other people with no use for your methods would be able to use them; at best, if it were a "friend" class or the equivalent, you would be exactly where you started, and only the caller would be using the method.

I think the approach the author is talking about is creating an internal class (either private or public).

It's common approach for large libraries. Each STL container has a public iterator class contained in it and rails is filled with internal, private classes that implement the public functionality.

That said, I don't think such constructs necessarily make code more understandable. Unless your project is really large scale, they're more like an exercise in showing the language and design constructs you've learned.

Reply on news.ycombinator.com