4 ms·

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 intellise

• haseman 17y ago
  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.
• joe_the_user 17y ago
  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.
  • mquander 17y ago
    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.
    • joe_the_user 17y ago
      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.