is private method an antipattern

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

Clean SpringTest-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.

10 Responses to is private method an antipattern

  1. fijiaaron says:

    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.

  2. szczepiq says:

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

  3. Radoslaw Maruszewski says:

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

  4. szczepiq says:

    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.

  5. Johannes says:

    Private methodes are just functions in the object’s scope, and thats exactly what you want to avoid in OOP. So instead of writing private methods, you should create new classes.


  6. Tom says:

    I have to agree it is an anti pattern. An anti pattern is: ineffective and/or counterproductive in practice (taken from wiki: So with TDD making a methods private is counter productive as you need to be able to test the method.

    I always struggle to come up with an example of when to use private, so whould appreciate if anyone can provide a good one.

    If I dont want a function to be called from outside my class I make it protected. Thus giving me or anyone the option to override the function and allow for it to be tested.

  7. You realize, of course, that programming languages that follow OOP principles well provide abstractions such as Abstract Classes, Interfaces (C++, Java), and Protocols (Clojure) which are __far better suited__ towards “Program to an Interface, Not an Implementation” than an instance object’s public methods?

  8. We are a group of volunteers and opening a new scheme in
    our community. Your website provided us with valuable info to work on.
    You’ve done a formidable job and our entire community will be grateful to you.

  9. official site

    is private method an antipattern | monkey island

  10. managing arthritis

    is private method an antipattern | monkey island

%d bloggers like this: