protected vs. private

Lesetipps

1. Testing in the Dark – protected und private Methods
2. Sichtbarkeit in der OOP
3. Die Modifiers in PHP – Teil 2

Unglaublich, es ist 9:30 Uhr (zumindest als ich angefangen habe mit schreiben) und ich bin wach. Wäre ja nichts besonderes, wenn es nicht der Neujahresmorgen wäre und das schlimme ist, ich kann schon seit 7 nicht mehr pennen. Ein guter Grund also hier was zu schreiben.

Wie bereits angekündigt wollte ich ja mal was dazu schreiben, wann man private und wann man protected als Sichtbarkeit auf Klassenebene verwenden sollte. Auch wenn es wahrscheinlich eh jeder weiß, hier noch einmal schnell die Bedeutung dieser zwei Schlüsselwörter:

• private – Eine private Methode darf nur im Kontext der Klassen aufgerufen werden, in der sie definiert wurde. Das gleiche gilt für Attribute. Leitet man eine Klasse ab, so wird der Zugriff auf diese Methoden/Variablen verboten. Von “außen” kann man natürlich auch nicht darauf zugreifen.
• protected - Der Zugriff von “außen” ist hier natürlich auch gespannt, nur können diesmal abgeleitete Klassen diese Methoden aufrufen.

Ich weiß, ein alter Hut. Ich wollte aber sicher sein, dass es jetzt wirklich jeder weiß. Und außerdem ist ein wenig Buzzword-  (aka. Bullshit-) Bingo ja auch eine feine Sache.

Ich kenne einige Projekte und auch Entwickler, die erst mal jede Methode als protected definieren, denn man könnte sie ja in einer Unterklasse überschreiben wollen. Klingt ja eigentlich gar nicht so dumm. Als zweites Argument hört man die Testbarkeit (hier Unit Tests). Protected Methoden kann man durch eine “Proxyklasse”, die man von der Superklasse ableitet und alle Methoden auf public setzt testen. Vielleicht schreibe ich da ja mal ein Beispiel, obwohl ich das gar nicht mal für eine saubere Sache halte.

Dabei vergisst man aber vielleicht, dass man nur öffentliche Methoden testet. Private und protected machen gar keinen Sinn, da man mit Unit Tests nur das Verhalten nach Außen testet. Eine Art Blackboxtest also. Das Argument, dass man die Methode vielleicht einmal überschreiben will, lasse ich auch nicht gelten. Denn wenn ich sie später überschreibe, dann kann ich sie da auch noch auf protected setzen. Nach dem Motto “You ain’t gonna need it” sollte man auch hier sparsamer sein. Viele Methoden sollten auch per Definition nicht überschreibbar sein. Setter und Getter eines Attribute sollten auf jeden Fall private oder protected sein, das Attribut aber selbst “nur” private. Vorteil hiervon ist eine aufgeräumtere Klasse. Man hat wirklich nur die Methoden zum Aufruf zur Auswahl, die auch Sinn machen.

In unserem aktuellen Projekt sind wir sogar noch einen Schritt weiter gegangen. Wir haben das komplette Model (MVC) “neu” geschrieben, da wir viel zu viele public Methoden gehabt haben, die gar nicht öffentlich sein sollten. Ok das Ding war auch so ziemlich Kacke und in PHP4 geschrieben, was natürlich auch die hohe Anzahl der öffentlichen Methoden erklärt. Dabei haben wir das Model von ca. 50, auf 10 öffentliche Methoden reduziert, was die Handhabung auf jeden Fall vereinfacht. Da lohnt sich auch ein Refactoring.

Als Fazit kann man also sagen, dass man nicht pauschal protected verwenden sollte, sondern vorher darüber nachdenken sollte, ob es wirklich nötig ist. In vielen Fällen is es garantiert eine gute Idee, aber in einigen wohl eher nicht.

Da fällt mir gerade ein, ich habe ja total vergessen euch ein gutes neues Jahr zu wünschen, was ich hiermit machen will.

7 Kommentare »

• 
  

  Nils Langner

  am 1. Januar 2009 um 10:29 Uhr

  Wie ich gerade sehe, ist der Google Pagerank gerade von 3 auf 4 gestiegen. Ich glaube es wird ein tolles Jahr 2009.

• 
  

  PHP hates me - Der PHP Blog » PDT 2.0

  am 2. Januar 2009 um 17:12 Uhr

  [...] wollte ja heute eigentlich einen Artikel über “private vs. protected” verfassen, dann bin ich aber ein wenig durch die unendlichen Weiten des Internets gesurft [...]

• 
  

  mark

  am 3. Februar 2011 um 01:35 Uhr

  Bin gerade bzgl meiner Recherche auf diesen Blogeinträg gestoßen.
  Ich muss sagen, dass ich anderer Meinung bin.
  Definitiv protected immer private vorziehen – eben genau aus dem von dir genannten Grund, dass die Klasse ableitbar bleibt. Was bringt dir die tollste Klasse, wenn man sie nicht ordentlich benutzen kann?

  Private macht nur in einem einzigen Fall Sinn:
  Wenn eine (aus welchem grund auch immer) private Methode als einziges auf eine Variable zugreift. Diese wird sonst nirgendwo verwendet, ergo: private machen.

• 
  

  Nils Langner

  am 3. Februar 2011 um 10:07 Uhr

  @Mark: Dann spinnen wir das doch mal weiter. Warum nicht alles public machen? Dann kann ich auch von außen alles nutzen und bin so flexibel wie es nur geht.

  Datenkapselung ist ein wichtiger Bestandteil von OOP und ich glaube wenn man was darüber liest, wird einem klar, dass private vielleicht doch nicht so böse ist.

• 
  

  mark

  am 3. Februar 2011 um 16:17 Uhr

  das hat doch damit gar nix zu tun
  public = von AUSSEN drauf zugreifbar (bei attributen oftmals schlechter stil, setter und getter benutzen soweit möglich)

  protected = abgeleitete klassen (und die wirds immer geben!) können zumindest den code weiterbenutzen

  private = nix geht

  und coden wir für uns selbst? meistens eher für einen höheren zweck…
  niemand kann so egoistisch sein und alles private machen und meinen, da gibts nix mehr zu extenden! das is einfach kurzsichtig.

• 
  

  Nils Langner

  am 3. Februar 2011 um 16:44 Uhr

  @Mark: Nein das ist OOP, wir definieren Schnittstellen, die dann verwendet werden müssen. “Information Hiding” bedeutet, das man so wenig wie möglich nach Außen gibt.

  Wie sieht es denn aus, wenn du deine Klassen refaktorst? Hältst du alle Schnittstellen stabil? Also auch alle protected Methoden? Ich glaube nicht, dass du so sinnvoll deinen Code verbessern kannst.

  Natürlich Code ist für mich selbst, aber es gibt andere Mittel Tools/Funktionalitäten zu erweitern, als Ableitung. Dekorierung und Obeserver-Pattern nur mal als Buzzwords.

• 
  

  mark

  am 3. Februar 2011 um 17:58 Uhr

  >> “Information Hiding” bedeutet, das man so wenig wie möglich nach Außen gibt

  Du sagst es bereits selbst. Nach “Außen”.
  Wenn jemand eine klasse ableitet, verwendet er sie immernoch intern. Er erweitert sie ja. Vielleicht bin ich im moment zu sehr im Framework-Denken (also in meinem Fall CakePHP). Aber selbst bei Standalone Klassen verbaut man sich mit dem ganzen private zeugs jegliche Modifikation.

  beispiel class Foo:

  private $value = 0;

  public function getFinalValue() {
  return $this->value * 0.4;
  }

  wenn ich in meiner MyFoo extends Foo class nun getFinalValue überschreiben möchte (weil ich 0.5 haben will), kann ich das aufgrund des egoistischen denkens des programmers nicht.

  korrekt wäre hier:

  //Foo
  protected $value = 0;

  //MyFoo
  /**
  * @override (0.4 is not enough!)
  */
  public function getFinalValue() {
  return $this->value * 0.5;
  }

  ok?
  verbauen wir uns doch nich sinnlos zeugs. dafür is private nicht gedacht gewesen. und dank protected kann trotzdem niemand in der tatsächlichen verwendung
  echo $MyFoo->value machen (was ja eben durch den getter getan werden soll)

RSS Feed für Kommentare zu diesem Artikel. TrackBack URL

Hinterlasse einen Kommentar