Klassisches php vs. Objektorientiertes php

In diesem Forum gibt es Starthilfe zum neuen Extension-System von phpBB 3.1/3.2. Fragen zur Entwicklung von Extensions und zur Konvertierung von phpBB 3.0.x MODs sind ebenfalls willkommen.
Benutzeravatar
BNa
Valued Contributor
Beiträge: 2272
Registriert: 12.04.2010 23:51
Kontaktdaten:

Klassisches php vs. Objektorientiertes php

Beitragvon BNa » 09.01.2017 18:45

Hallo,

is nu ne Weile her, daher mal ne primitive Frage:

Muss ich für 3.2.* Extensions zwingend das/%$=/R§Unsägl.-ausdrücke"§%&/(- objektorientierte php benutzen oder darf es auch klassisches php sein????

Gruß in die Runde,
Bernd

Benutzeravatar
gn#36
Administrator
Administrator
Beiträge: 9175
Registriert: 01.10.2006 16:20
Wohnort: Ganz in der Nähe...
Kontaktdaten:

Re: Klassisches php vs. Objektorientiertes php

Beitragvon gn#36 » 09.01.2017 23:32

Du nimmst dein "Klassisches php" und verpackst es in eine Klasse => fertig ist das Objektorientierte PHP das du brauchst :D

So ungefähr jedenfalls - ganz ohne Klassen wird es nicht gehen, wenn du wirklich eine Erweiterung erstellen willst, die phpBB manipuliert ohne die core Dateien zu modifizieren.

Siehe Eigene phpBB Erweiterungen erstellen sowie Eigene phpBB Erweiterungen erstellen (Fortgeschrittene Themen) (letzteres habe ich noch nicht ganz fertig)

Aber für Zusatzseiten muss du im Grunde nur eine eine Funktion in die Klasse packen, wenn du möchtest, und natürlich kannst du theoretisch den klassischen Weg gehen und selber eine Datei wie die viewtopic.php basteln - phpBB ist noch weit davon weg komplett objektorientiert zu sein. Die Vorlage für in phpBB eingebundene Seiten funktioniert vermutlich immer noch ziemlich ähnlich.
Begegnungen mit dem Chaos sind fast unvermeidlich, Aber nicht katastrophal, solange man den Durchblick behält.
Übertreiben sollte man's im Forum aber nicht mit dem Chaos, denn da sollen ja andere durchblicken und nicht nur man selbst.

Benutzeravatar
BNa
Valued Contributor
Beiträge: 2272
Registriert: 12.04.2010 23:51
Kontaktdaten:

Re: Klassisches php vs. Objektorientiertes php

Beitragvon BNa » 10.01.2017 01:07

Vielen Dank schonmal,

ich glaub das reicht mir, sofern das building einer normalen klassischen php-class mir nicht unbedingt fremd ist.
Also reicht das erstellen einer klassischen nicht-objektorientierten class{} völlig?

Grüßle....

Benutzeravatar
oxpus
Ehemaliger
Beiträge: 5065
Registriert: 03.02.2003 12:33
Wohnort: Bad Wildungen
Kontaktdaten:

Re: Klassisches php vs. Objektorientiertes php

Beitragvon oxpus » 10.01.2017 08:12

Öhm, streng genommen ist eine Klasse ja schon ein Objekt ;-)
Grüße
OXPUS
Kein Support bei unaufgeforderten PNs, E-Mails oder auf anderem Weg!!

Benutzeravatar
BNa
Valued Contributor
Beiträge: 2272
Registriert: 12.04.2010 23:51
Kontaktdaten:

Re: Klassisches php vs. Objektorientiertes php

Beitragvon BNa » 10.01.2017 14:12

Ja ne, klar. Muss es in Extensions denn überhaupt class()es geben, also ist es via phpbb.com vorgeschrieben?
Kann ich nicht einfach nur Funktionen schreiben, also mehrere function()s und diese dann in die "Steuerdatei" packen?

Benutzeravatar
oxpus
Ehemaliger
Beiträge: 5065
Registriert: 03.02.2003 12:33
Wohnort: Bad Wildungen
Kontaktdaten:

Re: Klassisches php vs. Objektorientiertes php

Beitragvon oxpus » 10.01.2017 16:08

BNa hat geschrieben:Ja ne, klar. Muss es in Extensions denn überhaupt class()es geben, also ist es via phpbb.com vorgeschrieben?
Kann ich nicht einfach nur Funktionen schreiben, also mehrere function()s und diese dann in die "Steuerdatei" packen?

Selbstverständlich. Das mache ich ja bei Bedarf auch so.
Grüße
OXPUS
Kein Support bei unaufgeforderten PNs, E-Mails oder auf anderem Weg!!

Benutzeravatar
BNa
Valued Contributor
Beiträge: 2272
Registriert: 12.04.2010 23:51
Kontaktdaten:

Re: Klassisches php vs. Objektorientiertes php

Beitragvon BNa » 10.01.2017 16:41

Sehr schön. Vielen Dank an euch Beide für Klärung und Anstoß...

Benutzeravatar
gn#36
Administrator
Administrator
Beiträge: 9175
Registriert: 01.10.2006 16:20
Wohnort: Ganz in der Nähe...
Kontaktdaten:

Re: Klassisches php vs. Objektorientiertes php

Beitragvon gn#36 » 10.01.2017 20:26

Das kannst du machen, aber wenn du es über die "normalen" Mechanismen einbinden willst musst du dich glaube ich etwas verrenken um Klassen komplett zu vermeiden. Eine Funktionsbibliothek die du irgendwo einbindest geht sicherlich, aber wenn du nicht an core Dateien ändern willst, dann wirst du wohl mindestens die Klasse bauen müssen, die dann von phpBB eingebunden wird.

Wenn du die Erweiterung in der DB auf .com einreichen willst wirst du um OOP nicht herumkommen. Funktionsbibliothek geht vermutlich auch da, aber der klassische Weg für eingebundene Seiten mit Sicherheit nicht. Es gibt auch Erweiterungen die komplett ohne Klassen auskommen, das liegt dann aber daran, dass sie einfach keinen PHP Code enthalten, sondern nur Style Events nutzen.
Begegnungen mit dem Chaos sind fast unvermeidlich, Aber nicht katastrophal, solange man den Durchblick behält.
Übertreiben sollte man's im Forum aber nicht mit dem Chaos, denn da sollen ja andere durchblicken und nicht nur man selbst.

Benutzeravatar
BNa
Valued Contributor
Beiträge: 2272
Registriert: 12.04.2010 23:51
Kontaktdaten:

Re: Klassisches php vs. Objektorientiertes php

Beitragvon BNa » 10.01.2017 22:15

Hm, also doch nicht?
Reicht es denn, wenn ich eine "Tarn-class()" einrichte, um dem zu entsprechen?
Also sowas wie eine Pseudo-class(), nur um den Regeln zu entsprechen?
Ohne das ganz private, public, construct, $this->, Doppel-Doppelpunkt :: etc.-Gedöns?
Quasie eine klassische class() im alten(!) php-stil?

Code: Alles auswählen

class blub{

function blab($laber){
if (!empty($laber))
{
return $laber; 
}
else
{
return false;
}


Benutzeravatar
gn#36
Administrator
Administrator
Beiträge: 9175
Registriert: 01.10.2006 16:20
Wohnort: Ganz in der Nähe...
Kontaktdaten:

Re: Klassisches php vs. Objektorientiertes php

Beitragvon gn#36 » 10.01.2017 23:10

Wenn es um die Regeln für eine Einreichung auf .com geht - die stehen sicher in irgend einer Ordnung drin. Ich habe sie mir nicht so genau angesehen, was da an alten Methoden nun erlaubt ist und was nicht. Schau lieber selber, bevor ich dir noch was falsches erzähle.

Ich habe glaube ich in noch keiner Klasse einen Grund für private gesehen - wenn ich sowas nutze, dann eigentlich immer protected ;) Wenn du den Kram nicht brauchst, brauchst du ihn auch nicht benutzen. Warum du den Konstruktor nun unbedingt wie den Klassennamen nennen willst ist mir nicht klar, das ist doch das gleiche. Wenn man es nicht nutzen will, dann muss man es nicht übertreiben und kann die Klassen letztlich nur als Wrapper verwenden, wenn auch nicht wirklich in dieser von dir vorgeschlagenen Form.

Es gibt schon Minimalregeln, die deine Klasse erfüllen muss:
  • Sie muss im korrekten Namespace liegen
  • Sie muss den korrekten Namen haben
  • Sie muss mindestens eine Methode bereitstellen, die die Ausgabe ansteuert

In der Methode kannst du dann letztlich genau das machen, was du vorher in der separaten Datei gemacht hast, nur dass du die nötigen Objekte (wie $db oder $template) entweder über den Konstruktor holen musst oder per global. Ich weiß nicht ob letzteres für Einreichungen erlaubt ist. Der Inhalt der Datei ist letztlich also klassisch, nur hast du statt der Initialisierung am Anfang der Datei nun halt eine Klasse als Wrapper.

Wenn du dich in eine core Datei einklinken willst muss deine Klasse mindestens:
  • Im korrekten Namespace liegen
  • Die Methode static function getSubscribedEvents() enthalten, die das Event der anderen Methode zuordnet
  • Die andere Methode in der du die inhaltliche Manipulation durchführst enthalten, die ggf. ihren Parameter $event manipuliert
Innen drin ist dann natürlich nicht mehr alles gleich.

Für Template Dateien hat sich nicht wirklich was geändert, es ist nur zusätzliche Syntax erlaubt. Um Templates an definierten Positionen zu manipulieren musst du nur den korrekten Namen für deine Templatedatei verwenden. Eigene Templates wie bisher.

Das ist dann natürlich nicht mehr ganz das gleiche wie ein include in der core Datei.
Begegnungen mit dem Chaos sind fast unvermeidlich, Aber nicht katastrophal, solange man den Durchblick behält.
Übertreiben sollte man's im Forum aber nicht mit dem Chaos, denn da sollen ja andere durchblicken und nicht nur man selbst.


Zurück zu „Extension Bastelstube“