Comments on: is private method an antipattern

By: Tom

Tom — Thu, 08 Jul 2010 13:51:33 +0000

I have to agree it is an anti pattern. An anti pattern is: ineffective and/or counterproductive in practice (taken from wiki: http://en.wikipedia.org/wiki/Anti-pattern) 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.

By: Johannes

Johannes — Thu, 15 Apr 2010 18:40:39 +0000

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.

Greetings,
Johannes

By: szczepiq

szczepiq — Tue, 26 Feb 2008 14:07:07 +0000

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.

By: Radoslaw Maruszewski

Radoslaw Maruszewski — Mon, 25 Feb 2008 10:40:53 +0000

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

By: szczepiq

szczepiq — Mon, 14 Jan 2008 23:35:49 +0000

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

By: fijiaaron

fijiaaron — Mon, 07 Jan 2008 16:37:45 +0000

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.