3 ms·

I think this is possibly the most dangerous sweeping generalisation that I've ever read here. I've found throughout my career that the opposite is true. The mo

I think this is possibly the most dangerous sweeping generalisation that I've ever read here. I've found throughout my career that the opposite is true. The more encapsulation the more solid the system. Making the world public encourages unnecessary dependencies.

dasil003 17y ago
Agreed. The whole idea is coming straight out of left field: Sometimes, private methods are created to split complex logic or processes into small, easily digested pieces. Often, such private methods have gnarly dependencies because they directly access or modify internal state. Moving these methods to appropriate collaborators (again, creating new classes as necessary) exposes such dependencies. Eliminating these dependencies simplifies the new API, which improves readability and understanding. Here he seems to be complaining about bugs that arise due to overly complex mutable state. However that has nothing to do with private methods. The defensible assertion here might be that if you have a big ugly method that has too many state dependencies, then refactoring it into private methods isn't really an improvement even if it appears more readable. However that's a string of failures that only incidentally have anything to do with private methods. It would be more accurate to just state that non-functional code is a smell, increasing in putrescence as a function of the quantity of moving parts. The resulting code is simpler, more testable, more reusable, more cohesive, and less coupled. Again, the correlation of privateness to these concerns is dubious. Separation of concerns should be on a logical basis, not based on the structure of the implementation. Every additional class adds mental overhead. Decoupling is useful as a means of reusing code, but only if there is a case for reuse. It's also useful as a way to tease apart complex dependency graphs, but only if the resultant sets of dependencies make sense on their own. Also, let's not forget that encapsulating concerns in separate objects is no more functional than a bunch of private state if you end up passing around objects anyway... Law of Demeter and all that. What I suspect here is that the author saw some bad code that used a lot of private methods and then honed in on that as a smell even though it has little general applicability. The bar needs to be much higher for declaring any core language construct to be a smell.
blasdel 17y ago
Encapsulation doesn't make this problem go away at all -- it just replaces interface proliferation with secretive state. I don't like having state spread everwhere, but I hate being lied to about it.
- joe_the_user 17y ago
  Encapsulation can an excellent step in making a problem go away. First a mistake is made all over your code. Then it's made only in the private method. Then it can be changed easily -- and reverted easily if the change doesn't work. Of course, this isn't always a good idea. But there are many times that it can be a good idea.

dasil003 17y ago

Agreed. The whole idea is coming straight out of left field: Sometimes, private methods are created to split complex logic or processes into small, easily digested pieces. Often, such private methods have gnarly dependencies because they directly access or modify internal state. Moving these methods to appropriate collaborators (again, creating new classes as necessary) exposes such dependencies. Eliminating these dependencies simplifies the new API, which improves readability and understanding. Here he seems to be complaining about bugs that arise due to overly complex mutable state. However that has nothing to do with private methods. The defensible assertion here might be that if you have a big ugly method that has too many state dependencies, then refactoring it into private methods isn't really an improvement even if it appears more readable. However that's a string of failures that only incidentally have anything to do with private methods. It would be more accurate to just state that non-functional code is a smell, increasing in putrescence as a function of the quantity of moving parts. The resulting code is simpler, more testable, more reusable, more cohesive, and less coupled. Again, the correlation of privateness to these concerns is dubious. Separation of concerns should be on a logical basis, not based on the structure of the implementation. Every additional class adds mental overhead. Decoupling is useful as a means of reusing code, but only if there is a case for reuse. It's also useful as a way to tease apart complex dependency graphs, but only if the resultant sets of dependencies make sense on their own. Also, let's not forget that encapsulating concerns in separate objects is no more functional than a bunch of private state if you end up passing around objects anyway... Law of Demeter and all that. What I suspect here is that the author saw some bad code that used a lot of private methods and then honed in on that as a smell even though it has little general applicability. The bar needs to be much higher for declaring any core language construct to be a smell.

blasdel 17y ago

Encapsulation doesn't make this problem go away at all -- it just replaces interface proliferation with secretive state. I don't like having state spread everwhere, but I hate being lied to about it.

joe_the_user 17y ago
Encapsulation can an excellent step in making a problem go away. First a mistake is made all over your code. Then it's made only in the private method. Then it can be changed easily -- and reverted easily if the change doesn't work. Of course, this isn't always a good idea. But there are many times that it can be a good idea.