OOP: Methodenimplementierung auslagern

[freakXHTML]

Hallo zusammen,
aus C++ bin ich gewohnt bei Klassendeklaration mit Headerdateien zu arbeiten. Dadurch werden die eigentlichen Klassendeklarationen nicht so riesig. Bis jetzt habe ich aber in PHP nur Klassen gesehen, bei denen die Methoden direkt in der Klassenvereinbarung auch ihren Anweisungsblock erhalten. Das resultiert dann bei mir in einer PHP mit endlos vielen Zeilen.

Ist das in PHP normal oder kann man auch hiert erstmal den Prototyp einer Methode erstellen und in einer anderen Datei dann implementieren?

Ich habe noch eine andere Frage. Ich habe eine Klassendeklaration, in der eine private und eine public Methode ist. Die public Methode ruft die private auf. Doch der Parser sagt mir folgendes:

Fatal error: Call to undefined function get_variables() in...

<?php
 class Login
 {
  
  private function get_variables($name_user_field, $name_pass_field, $name_mail_field)
  {
   //...
   
   return true;
  }
  
  public function register($name_form, $pass_form, $mail_form)
  {
   if(!get_variables($name_form, $pass_form,  $mail_form))  //Hier ist die Methode get_variables unbekannt! Warum?
    
   //...
  }
 }
 
?>

Vielen Dank
lg, freakXHTML

 

[crash]

$this->get_variables() wenn du auf Instanzmethoden zugreifen willst.

Statt Prototypen solltest du dir Interfaces ansehen.

 

[mermshaus]

...beziehungsweise aufhören, jede PHP-Mechanik von C++ ableiten zu wollen. ;) Die grundlegenden Konzepte (auf die kommt es beim Lernen an) sind zwar -- sofern in beiden Sprachen vorhanden -- dieselben oder zumindest prinzipiell sehr ähnlich, aber PHP-Syntax ist eben nicht C++-Syntax. Klar, es ist für einen Einsteiger nicht unbedingt offensichtlich, dass Prototypisierung eine Syntax-Eigenschaft von C++ ist, die so in PHP nicht auftaucht. Der Trick ist vielleicht, sich der neuen Sprache nicht negativ von einer anderen Sprache ausgehend zu nähern ("hat Eigenschaft xy wie in Sprache yz nicht"), sondern die in der neuen Sprache implementierten Konzepte positiv zu betrachten ("lockere Typisierung, hat Vererbung, Klassen-Methoden werden so und so deklariert, ...").

Die genauen Syntax-Eigenschaften einer Sprache sind in Büchern oder dem etwaigen Online-Handbuch beschrieben. Es gibt grundlegende Fragen, die sich wunderbar dort nachschlagen lassen, und zum Beispiel die in diesem Thread gehören dazu (PHP: Klassen und Objekte - Manual).

Es ist wichtig, auch ein Gespür dafür zu entwickeln, was sich wo nachlesen lässt. Dokumentationen lesen (und finden ;)) ist beim Programmieren essenziell. Wenn du wissen möchtest, wie etwas funktioniert: Lies die Doku. Wenn du wissen möchtest, warum etwas nicht funktioniert: Lies die Doku. Wenn du ein Problem hast, von dem du glaubst, dass es eine Anfängerfrage sein könnte: Lies die Doku. Wenn du dich in ein neues Thema einarbeitest: Lies die Doku. -- Na ja, you get the point. ;) Das spart Wochen und Monate der Frustration. Ich spreche aus Erfahrung.

Was Prototypen und Interfaces angeht: Interfaces sind -- wenn auch inhaltlich als "beste" Alternative zu Prototypen sicher nicht verkehrt -- nichts, was in PHP inflationär verwendet werden sollte. (Das ist 'ne subjektive Meinung.) Zumindest jedenfalls nicht aus dem Grund, eine möglichst exakte Entsprechung zu C++-Syntax zu schaffen. ;)

 

[crash]

Und Methoden und Eigenschaften bitte in lowerCamelCase, sowie Klassenname in UpperCamelCase.

 

[freakXHTML]

Hallo ihr beiden,
da habt ihr natürlich recht. Ich versuche ich noch viel zu stark an C++ entlangzuhangeln. Der Grund liegt eben darin, dass die PHP Syntax der von C++ sehr ähnlich ist.

Stimmt, in PHP muss ja immer mit $this gearbeitet werden. Das ist zum Beispiel in C++ anders :mrgreen:.

Dieses Gespür zum Lesen ist bei mir am wachsen. Bevor ich hier euch mit Fragen quäle, schaue ich mich zunächst immer um, vor allem auf php.net. Doch ist es häufig schwierig, genau die Information, die man benötigt, als Anfänger herauszufiltern. Daher bin ich euch immer sehr dankbar ;)

Vielen Dank für die tolle Unterstützung und bis dann
lg, freakXHTML

 

[struppi]

Das mit den Header Dateien in C/C++ ist ein völlig anderes Konzept und dient auch nicht der Übersichtlichkeit o.ä., sondern die header Dateien musst du einbinden, damit der Compiler die Funktionen kennt, da diese u.U. erst vom Linker eingebunden werden.

 

[freakXHTML]

Hallo,
da hast Du zwar recht, doch solange man die Methoden nicht inline haben möchte, dürfen sie nicht in der Klassendeklaration einen Rumpf bekommen. Diese steht dann meistens in der Headerdatei, die wiederum in eine .cpp eingebunden ist, wo dann die Methoden ihre Anweisungsblöcke erhalten.

Als Nebeneffekt wird meines Erachtens die Übersicht besser.

lg, freakXHTML

 

[freak131]

eine gute ide gibt dir wieder übersicht, zudem solltest du dir wirklich interfaces anschauen :)

 

[newlord]

Mal ganz blöd gefragt:

Was für einen Vorteil habe ich, wenn ich Interfaces verwende? Außer den sparat notierten Methoden-Köpfen und der mehrfachen implemtierung der Interfaces, sehe ich darin kein Mittel um sich vor Schreibarbeit zu drücken. Eher sieht es für mich so aus, als würde sich freiwillig mehr Arbeit, allein zugunsten einer besseren Übersichtlichkeit gemacht. Oder täuscht mich jetzt irgendwas?

Bei dem letzten Projekt wo ich mitgeholfen hatte, wurden die Methoden durchweg mittels require() oder include() in die jeweiligen Klassen eingebunden was heißt, dass jede einzelne Methode auch in einer separaten Datei inkl. Dokumentation der Funktionalität zu finden war. In gewisser Weise auch eine Form der ausgelagerten Methodenimplementierung.

Grüße

NewLord

 

[struppi]

da hast Du zwar recht, doch solange man die Methoden nicht inline haben möchte, dürfen sie nicht in der Klassendeklaration einen Rumpf bekommen. Diese steht dann meistens in der Headerdatei, die wiederum in eine .cpp eingebunden ist, wo dann die Methoden ihre Anweisungsblöcke erhalten.

Ich weiß jetzt nicht inwiefern das eine Antwort auf meine Aussage ist. Die Trennung hat nichts mit Übersichtlichkeit zu tun, die Headerdatei ist in dem Fall lediglich dafür da, dass der Compiler weiß, welche Funktionen zu Verfügung stehen. Das hat auch nichts mit Klassen zu tun, dass gilt für jede Funktion.

Und warum du überhaupt eine Verbesserung der Übersicht siehst, wenn man alles doppelt zu schreibt, verstehe ich auch nicht.

 

[crash]

Eine Schnittstelle (engl. interface) dient in der objektorientierten Programmierung der Vereinbarung gemeinsamer Signaturen von Methoden, welche in unterschiedlichen Klassen implementiert werden. Die Schnittstelle gibt dabei an, welche Methoden vorhanden sind oder vorhanden sein müssen.

Übersichtlichkeit würde ich nicht unbedingt sagen. Vorteile sind eher, dass dir das Interface hilft eine Klasse richtig zu implementieren: Methoden, Anzahl Parameter, Type-Hinting der Parameter und Default-Werte der Parameter. In strenger typisierten Sprachen noch Art des Rückgabewertes etc.

Gute Editoren zeigen dir beim implementieren eines Interfaces an, welche Parameter du zu implementieren hast und sogar die Kommentare über der Funktion. Dokumentation ist ein(e) oft vergessene(r) Vorteil/Aufgabe von Interfaces.

 

[newlord]

Moin Moin

Die Definition eines Interfaces war mir bereits bekannt. Mir gings eigentlich mehr um den Sinn bzw. Unsinn. Ich muss in sofern sagen, dass für's Kladde-Denken und eben für die Dokumentation der Methoden, Interfaces sehr nützlich sind. Was die Hilfsfunktionen mancher Editoren angeht, wenn man Interfaces verwendet: Mein bevorzugter Editor liefert mir auch so schon die entsprechenden Methodennamen, Rückgabewerte sowie Anzahl und Defaultwerte der Parameter. Wie dem auch sei: Ich persönlich komme auch ohne ganz gut klar bzw. meine Projekte waren bisher nicht derart umfangreich, dass ich darauf hätte zurückgreifen müssen.

Grüße und schönen Start in die Woche

NewLord

 

[mermshaus]

Der Sinn und Zweck von Interfaces ist ein endloses Thema. Es gibt definitiv Fälle, in denen ein Interface eingesetzt werden sollte/muss (und sei es nur aufgrund irgendeiner persönlichen Vorliebe oder einer Projekt-Konvention). Ich für meinen Teil nutze ohne triftigen Grund aber meist "normale" Klassen und Vererbung.

Tagesaktueller Thread dazu auf phpforum.de: http://www.phpforum.de/forum/showthread.php?t=254362

"Der übermäßige Einsatz von Interfaces könnte dazu verleiten, an einer ordentlichen Vererbungshierarchie vorbeizuprogrammieren [...]."

"Vererbung verleitet einen dazu implementations Details vorweg zu nehmen, welche man nicht in allen Klassen benötigt."

:)

Edit:

Ich muss in sofern sagen, dass für's Kladde-Denken und eben für die Dokumentation der Methoden, Interfaces sehr nützlich sind. Was die Hilfsfunktionen mancher Editoren angeht, wenn man Interfaces verwendet: Mein bevorzugter Editor liefert mir auch so schon die entsprechenden Methodennamen, Rückgabewerte sowie Anzahl und Defaultwerte der Parameter.

Dokumentation kann auch in Klassen vorgenommen werden. Ich sehe da keinen Gewinn, aber überzeugt mich gerne vom Gegenteil. (Nicht sarkastisch gemeint.)