If you write a framework, please do not use private. You may think that you know how I am going to use it. I promise, if it works as it should I will not try and override the basic functionality. However, if I am looking at the code to know it is private then I have a use case you did not expect.
My current example is rails active resource. This is a great framework if you are planning to use it to talk to another rails app. If your url does not end in .json then you have to override / reimplement many high level methods because of one or two private methods.
I know they teach you this in school. I know it makes you feel smart. Stop it. Private methods makes your frameworks less usable and less extensible.
Advertisement
Jun 24, 2010 @ 20:27:12
Thats why you should always implement an architecture based on interfaces…. period.
Jun 24, 2010 @ 21:19:59
Errm… Private is for stuff that isn’t guaranteed to stay the same for future versions. If you don’t mind that, then go for it!
you can always define your own headers and force a cast…
Jun 25, 2010 @ 03:53:59
Alternatively, one writes code such that all code normally marked private is made public (or even protected), and it is impossible to change anything for the next release, be it to fix bugs or add new features. (Or the framework changes things in spite of that, and then you complain that your code broke.) You may think that overriding some method does what you want now, but the author never guaranteed that method would be called as a hook in the contexts you wanted, and the next release could very easily change that.
Don’t confuse encapsulation and well-designed interfaces. If you find yourself needing to alter a private method, it’s a sign that the framework’s interface was poorly designed, not that the framework shouldn’t have labelled something private.
Jun 25, 2010 @ 14:05:01
If you really do know better than the author
, Ruby has your back:
class A
def one; 1; end
def two; 2; end
private
def three; 3; end
private :two
end
#=> A
a = A.new
#=> #
a.one
#=> 1
a.two
#NoMethodError: private method `two’ called for #
# from (irb):10
# from :0
a.three
#NoMethodError: private method `three’ called for #
# from (irb):11
# from :0
class A
public :three
end
#=> A
a.three
#=> 3
Jul 02, 2010 @ 17:58:12
I have to disagree. If I were writing a framework and left everything public, I’d expect a zillion questions from frustrated users who hung themselves by accessing members that should have been private. When they see that they’re public, they assume they can mess with it, and for good reason.
You’re using the framework in a way that the developer hadn’t intended. He has no way of knowing whether your way of using it will blow up in your face or not. For encapsulation purposes he should assume it will, and keep you from shooting yourself in the foot.
I always thought that either a) you are a user and you accept the framework as-written because you don’t know it well enough to screw with it, or b) you know it well enough and you screw with it by forking the source.
Can you tell I’m a QA guy?
Jul 02, 2010 @ 18:53:15
My issue is this.. subsclass is a “Is A” relationship. If the parent can do it, so should the child. If you want to hide it, model it so you are not subclassing. The issue I had was trying to get Ruby Active Resource to talk to a non ruby back end. Everything was public except for one line where the url is constructed. If they wanted to protect me from it.. they would have set up a service I could call or not.
Jul 02, 2010 @ 18:50:24
I can see why you are now a manager.
Jul 02, 2010 @ 18:53:27
Thppppbt.