Criteria to decide what is private? (was: Encapsulation vs Extensibility)

"Mark Nicholls" <Nicholls.Mark@xxxxxxxxx> wrote:

But who is 'advocating' the use of private 'so much' ??

It follows from the opinion that implementation inheritance is
overused, so rather than use protected, use private and 'seal' your
implementations....

I don't think the public/protected/private choice has anything to do
with implementation inheritance being overused.

I suggest making a field private when there is some invariant
relationship between it and some other field that the class also
contains. That way no outside code can break the invariant. (If the
field in question has no such relationship with any other fields in the
class, maybe it's in the wrong class.)

I suggest making a method private when there is some invariant that the
method in question can't ensure on its own. That way no outside code can
break the invariant. (If the method can't ensure the invariant, then
maybe it's in the wrong class.)

If neither of the above pertains, then you might as well make the
field/method public. I can't think of any reason to make a field or
method protected off hand.

Based on these rules, most fields will end up private, most methods will
end up public.
.

Relevant Pages

  • Re: Criteria to decide what is private? (was: Encapsulation vs Extensibility)
    ... I don't think the public/protected/private choice has anything to ... I suggest making a field private when there is some invariant ... That way no outside code can break the invariant. ... it's all about protecting the integrety of the object's ...
    (comp.object)
  • Re: Criteria to decide what is private? (was: Encapsulation vs Extensibility)
    ... I don't think the public/protected/private choice has anything to ... I suggest making a field private when there is some invariant ... That way no outside code can break the invariant. ... it's all about protecting the integrety of the object's ...
    (comp.object)
  • Re: Criteria to decide what is private? (was: Encapsulation vs Extensibility)
    ... It follows from the opinion that implementation inheritance is ... I don't think the public/protected/private choice has anything to do ... I suggest making a field private when there is some invariant ... That way no outside code can break the invariant. ...
    (comp.object)
  • Re: Encapsulation vs Extensibility
    ... Making X.REP private conflicts with the open-closed principle. ... The example of Line given in the link, has a "Representation Invariant" ... If Y implementors are refused the right to manipulate X.REP in a manner ... ADT developers provide *REP invariants*. ...
    (comp.object)
  • Re: Encapsulation vs Extensibility
    ... substitutability of base class directly corresponds to the notion of ... and private prohibits it. ... The REP invariant is the constraint you mention. ... implementors cannot do something stupid is killed by ADT theory. ...
    (comp.object)