After a conversation with my friend and after a cursory google search, here are my thoughts:
‘Private method a smell’ seemed to be ignited with the birth of TDD. Test-infected people wanted to know how to test their private methods. Gee… it’s not easy so the question evolved from ‘how‘ into ‘why‘: Why to test private method? Most of TDDers would answer instantly: don’t do it. Yet again TDD changed the way we craft software and re-evaluated the private methods 
Test-driven software tends to have less private methods. Shouldn’t we have a metric like: private methods to public methods ratio? I wonder what would be the output for some open source projects (like spring – famous for its clean code).
So, is private method an antipattern or not!?
If the class is so complex that it needs private methods, shouldn’t we aim to pull some of that complexity into its own class?
The code never lies: We looked at several distinctly big classes and put their private methods under magnifying glass. Guess what… Some of the private methods where clear candidates to refactor out to separate class. In one case we even moved whole private method, without a single change, into separate class 
Privacy may be an antipattern. Look at your private methods – I bet some of them should be public methods of different objects.
January 7, 2008 at 4:37 pm |
I don’t think private methods are an antipattern, but I do think that private methods are really only rarely used with any useful affect. The typical justification for private methods is so that someone doesn’t reach inside your API and have something that breaks with implementation changes, but that just isn’t the case. Once upon a time, in Windows people did that because the Win32 API was so broken, but so many people have gotten burned, that they either respect Microsoft’s APIs, or since the APIs themselves change so much, have just abandoned Microsoft.
Making methods private won’t protect against this, and since in practice it’s more likely that your API changes than your underlying (private) implementation, private methods often don’t make sense in the real world. There may be some highly structured organizations where it does, but I haven’t seen them.
January 14, 2008 at 11:35 pm |
Private methods are just an element of language – we should use them smartly to create simple and sexy code. I don’t think they are anti-pattern, too. However, calling them a smell may have a good effect: people will be more likely to refactor when private method gets too big or too ugly. At least I hope so
February 25, 2008 at 10:40 am |
Private methods are NEVER an anti-pattern. And they are NOT a bad smell in the code.
The main principles of a good OO design say that one should program to interfaces, not to classes, and that scoping of the class and methods should be as limited as possible. By widening the scope of your private methods you simply break both of these principles. Your unit tests should test the interface of your application (see BDD), and be completely unaware of the inner implementation.
That said it’s pretty obvious that private methods should follow other principles of OO design. They should be cohesive (bad cohesion is usually the main culprit of lengthy and ugly methods), loosely coupled with other methods (yes, coupling between class methods is also very important), but tightly coupled with class structure (thus private methods which could be declared ’static’ ARE a bad smell, as they usually don’t belong there).
February 26, 2008 at 2:07 pm |
First you say that private methods are NEVER an anti-patter. Then you say that static private methods are a bad smell. Make up your mind!
I don’t disagree with you in general. I just believe that taking private methods with a pinch of salt has positive effect on OO-thinking. I have a few friends who strongly believe that privacy is an anti-pattern. They all write absolutely awesome code.
Anyway, thanks for an interesting comment.