10

Just wondering, when should we actually must use private or protected for some methods in the model?

Sometimes I can't not be bothered to group my methods in private nor protected. I just leave it as it is. But I know it must be a bad practice, otherwise these 2 groupings won't be created in programming.

Thanks.

Andrew Grimm
  • 78,473
  • 57
  • 200
  • 338
Victor
  • 13,010
  • 18
  • 83
  • 146

3 Answers3

15
  • If you plan to call a method externally, record.method(), then "public"
  • If it will be used only internally, self.method(), then "private"
  • If you plan to use it internally, but also in descendants, self.method() # in subclass, then "protected"
clyfe
  • 23,695
  • 8
  • 85
  • 109
  • 2
    This sounds a little off to me... your **3rd point**. A subclass can access the `private` methods of its superclass internally. A `protected` method gives you the ability to pass in an object of the same class and execute protected methods on that object. – slindsey3000 Jan 04 '12 at 19:34
  • http://weblog.jamisbuck.org/2007/2/23/method-visibility-in-ruby "protected methods may actually be called any time the receiver is of the same class as ‘self’" – clyfe Jan 04 '12 at 20:24
2

I'll give my opinion, and maybe I'll get a kicking for it, but I don't bother with protected or private in Ruby. The reality is, Ruby treats you like an adult, if you want to run a private method from outside the class, you can (there are ways). You can run protected methods outside the class. You can even reassign constants... you can do whatever you like, basically.

And that's why I like it, it's your responsibility. My feeling is, that to mark something as protected or private you are doing two things:

  1. Indicating that you don't think a consumer will need it.
  2. Second guessing what someone else needs.

and in addition, you're making it harder to test, as it can be a real pain testing private methods (see What's the best way to unit test protected & private methods in Ruby? for ways around it)

For those last two reasons, I don't bother with them. If you really wanted some kind of barrier between your classes/methods and the consumers (be they code or developers) then there are other, more effective ways (proxies, obfuscation, encryption, password protected methods etc). Otherwise, why not give them access to the same tools you used?

Community
  • 1
  • 1
ian
  • 12,003
  • 9
  • 51
  • 107
  • 1
    +1 I have similar thoughts. The only reason why **I** use it: rdoc has the option `--visibility`. With public, protected and private I can generate different versions of documentation with more or less details. – knut Jan 04 '12 at 20:39
  • @knut that's an interesting idea, I'll have to keep that in mind. I tend to use yardoc and it has the `@private` tag, but I'd never seen what use it could be. Thanks. – ian Jan 05 '12 at 23:01
0

I don't know Ruby as a special case, but I assume the answer would be the same as for other languages too, so here it is:

A private method can only be accessed by members of the same class, whereas a protected is also available for member of classes that extend the base class where the method is declared.

fkerber
  • 1,032
  • 9
  • 24
  • Yupp, it's a general programming question. I have read what `private` and `protected` does, but when must we not ignore it? – Victor Jan 04 '12 at 16:44
  • Do you mean the case, where a method isn't declared as being public, private or protected at all? – fkerber Jan 04 '12 at 16:47
  • @Victor You don't 'ignore' encapsulation, but generally speaking keep things `private` unless there is a good reason for them to be `protected` or `public` – T I Jan 04 '12 at 16:49
  • @fkerber `private` members are only visible to the class, `protected` members are visible to children of that class and `public` members are visible to all classes. If these are instance members then they are, and perhaps more pertinently, encapsulated within the instance of that class (i.e. an object) – T I Jan 04 '12 at 17:01
  • 1
    @Tom `private` members are available to subclasses as well in Ruby. – slindsey3000 Jan 04 '12 at 19:37