PHP Möglichkeiten - wann nutzen?

[john]

Hallo.

Ich hätte von euch gerne mal ein paar Statements zu den Begriffen:
Interfaces, Namespaces, Polymorhie, Mehrfachverehrbung

und ihrer Rolle in PHP Skripten, Selfmade Frameworks, großen Webprojekten usw.

Meiner Ansicht nach raubt das fast alles nur Performance und bisher benutze ich sie nicht. Ich weiß einfach nicht wann diese Dinge wirklich SINN machen - ab wann macht es Sinn sie einzusetzen?

Gruß, John

[jobo]

Hallo,

Zend Framework zeigt, wie damit umzugehen ist. Da wird mit Interfaces und abstrakten Klassen gearbeitet.

Gruß

jobo

[dedlfix]

Hi!

Ich hätte von euch gerne mal ein paar Statements zu den Begriffen:
Interfaces, Namespaces, Polymorhie, Mehrfachverehrbung

Letzteres gibt es nur sehr selten in Programmiersprachen. PHP unterstützt dieses Konzept nicht.

und ihrer Rolle in PHP Skripten, Selfmade Frameworks, großen Webprojekten usw.

Je größer ein Projekt wird, desto wichtiger ist es nicht nur, dass es schnell läuft - das bekommt man durch mehr Rechenpower ausgeglichen - sondern dass es wartbar bleibt. Dazu gehört, dass man es in Einheiten gliedern kann, dass man es erweitern kann, ohne dabei großartig im vorhandenen Code Änderungen vornehmen zu müssen, die wieder andere Nebeneffekt nach sich ziehen können. All diese Bedürfnisse haben verschiedene Konzepte erzeugt, die du nun siehst und gerade in Frage stellst. Mit zunehmender Erfahrung wirst du sehen, wo sie sinnvoll sind und wo nicht. Du musst sie nur mit offenen Augen betrachten und nicht ablehnenderweise ignorieren.

Was willst du nun konkret zu den Begriffen hier lesen, was nicht in jedem Lexikon oder Programmierhandbuch auch steht?

Lo!

[john]

Ich sehe einfach nicht den Sinn bei Vererbung z.B.

Meine __autoload-Funktion erstellt und läd die Dateien falls nötig, bzw erstellt die Objekte.
Wichtige Klassen wie die Datenbankklasse sind statisch und ich kann soo drauf zugreifen.

Also ich baue gerade an einem großen Projekt - ihr empfehlt also Namespaces und Interfaces anzulegen?

[jobo]

Hallo,

Also ich baue gerade an einem großen Projekt - ihr empfehlt also Namespaces und Interfaces anzulegen?

Schau mal wie Zend Framework das macht. Das ist schon ziemlich rund und insgesamt von der Bauart übertragbar auf jedes Projekt ab einer gewissen Größe.

Gruß

jobo

[dedlfix]

Hi!

Also ich baue gerade an einem großen Projekt - ihr empfehlt also Namespaces und Interfaces anzulegen?

Jein, jedenfalls nicht so pauschal. Alles was du verwendest, solltest du gut begründen können. Wenn dir kein plausibler Grund einfällt, dann verwende es nicht. Allerdings soll das nicht bedeuten, dass du etwas generell ad acta legen sollst, wenn dir in einem konkreten Fall die Anwendung nicht sinnvoll erschien. Vielmehr solltest du jedes Mal erneut prüfen und den besten Kompromiss wählen.

Ein Grund könnte allerdings auch lauten: Das Projekt ist kein wahnsinnig kritisches und ich will nun mit den Techniken Erfahrung sammeln - positive oder negative.

Lo!

[john]

Ein Grund könnte allerdings auch lauten: Das Projekt ist kein wahnsinnig kritisches und ich will nun mit den Techniken Erfahrung sammeln - positive oder negative.

Doch es sit sehr wichtig. Es ist eine gute Idee und ein guter Investor steht dahinter.

[Pryos.org]

Hallo.

Hallo,

Ich hätte von euch gerne mal ein paar Statements zu den Begriffen:
Interfaces,

Standardisierung für Frameworks bzw Schnittstellen

Namespaces,

einfachere Modularisierung (auch für viele unterschiedliche Entwickler / Teams)

Polymorhie,

Ich wüsste nicht das PHP das kann.

Mehrfachverehrbung

Ich vermute mal, das dies auch nur in großen Frameworks zum Einsatz kommt, wenn es für jedes Objekt allgemeine Funktionen gibt.
Eventuell noch für OOP Freaks, die es am liebsten in Java schreiben würden und dann halt in PHP alles OOP machen ^^

und ihrer Rolle in PHP Skripten, Selfmade Frameworks, großen Webprojekten usw.

siehe oben.

Meiner Ansicht nach raubt das fast alles nur Performance und bisher benutze ich sie nicht. Ich weiß einfach nicht wann diese Dinge wirklich SINN machen - ab wann macht es Sinn sie einzusetzen?

Wenn man Module ohne Scripte für ein großes ganzes schreibst, wo du dich nicht über jede Kleinigkeit absprechen möchtest, sondern nur über die Schnittstellen.

Gruß, John

mfg Pryos

[Guy Gaz]

Hallo!

Mehrfachverehrbung
Ich vermute mal, das dies auch nur in großen Frameworks zum Einsatz kommt, wenn es für jedes Objekt allgemeine Funktionen gibt.
Eventuell noch für OOP Freaks, die es am liebsten in Java schreiben würden und dann halt in PHP alles OOP machen ^^

Das ist eher etwas für C-Freaks, die die die PHP-Sourcen 'tunen', denn PHP kennt so etwas nicht - gut so! Einer der Gründe für die Erschaffung der Sprache Java war es, die Nachteile welche Mehrfachvererbung (z.B. und gerade in C++) mit sich bringt zu umgehen.

BTW: was spricht dagegen in PHP objektorientiert zu arbeiten?

Ciao

GG

[Pryos.org]

Hallo!

Hallo,

Das ist eher etwas für C-Freaks, die die die PHP-Sourcen 'tunen', denn PHP kennt so etwas nicht - gut so! Einer der Gründe für die Erschaffung der Sprache Java war es, die Nachteile welche Mehrfachvererbung (z.B. und gerade in C++) mit sich bringt zu umgehen.

Ich hab mich ehrlich gesagt noch nicht mit den Vor und Nachteilen von Mehrfachvererbung beschäftigt. Jedoch fällt mir auch spontan kein Fall ein, wo ich es verwenden würde.

BTW: was spricht dagegen in PHP objektorientiert zu arbeiten?

Gegen objektorientierte Entwicklung spricht gar nichts.
Jedoch gibt es Leute, wie mein damaligen Berufsschuhlehrer für Java, die darauf schwören >ALLES< Objektorientiert zu machen.
Und das finde ich unsinnig.

Objektorientierte Entwicklung macht Sinn, wenn man auch Konzeptionell ein Objekt besitzt. Bei z.b. einer Datenbank, einem Datensatz oder einem User.
Jedoch gibt es genug Dinge z.b. kleine allgemeine Funktionen oder lineare Prozesse, wie der Aufbau einer Webseite selbst, welche zu keinem Objekt gehören.

Ciao
GG

mfg Pryos

[Guy Gaz]

Hallo!

Das ist eher etwas für C-Freaks, die die die PHP-Sourcen 'tunen', denn PHP kennt so etwas nicht - gut so! Einer der Gründe für die Erschaffung der Sprache Java war es, die Nachteile welche Mehrfachvererbung (z.B. und gerade in C++) mit sich bringt zu umgehen.
Ich hab mich ehrlich gesagt noch nicht mit den Vor und Nachteilen von Mehrfachvererbung beschäftigt.

Der Hauptnachteil ist, dass der Entwickler sich damit sehr schön selbst ver****en kann.

Jedoch fällt mir auch spontan kein Fall ein, wo ich es verwenden würde.

Eben.

BTW: was spricht dagegen in PHP objektorientiert zu arbeiten?
Gegen objektorientierte Entwicklung spricht gar nichts.
Jedoch gibt es Leute, wie mein damaligen Berufsschuhlehrer für Java, die darauf schwören >ALLES< Objektorientiert zu machen.

Dafür gibt es keine objektive Grundlage. Ich mag OOP gerne, aber ich tippe auch mal einen Vierzeiler in einer beliebigen Scriptsprache ohne über Objekte nachzudenken - es hängt vom Anwendungsfall ab.

Und das finde ich unsinnig.

Ja.

Objektorientierte Entwicklung macht Sinn, wenn man auch Konzeptionell ein Objekt besitzt. Bei z.b. einer Datenbank, einem Datensatz oder einem User.
Jedoch gibt es genug Dinge z.b. kleine allgemeine Funktionen oder lineare Prozesse, wie der Aufbau einer Webseite selbst, welche zu keinem Objekt gehören.

Uiii! Das sehe ich nun anders - wollen wir das ausdiskutieren?

Ciao

GG

[Pryos.org]

Hallo!

Hallo

Uiii! Das sehe ich nun anders - wollen wir das ausdiskutieren?

Wenn du mir verrätst was du anders siehst? :)
Und eventuell warum.
Ist ja nicht so als würde ich immer nur Stur bei meiner Meinung bleiben.

Ciao
GG

Mfg Pryos

[jobo]

Hallo,

Objektorientierte Entwicklung macht Sinn, wenn man auch Konzeptionell ein Objekt besitzt. Bei z.b. einer Datenbank, einem Datensatz oder einem User.
Jedoch gibt es genug Dinge z.b. kleine allgemeine Funktionen oder lineare Prozesse, wie der Aufbau einer Webseite selbst, welche zu keinem Objekt gehören.

Zend Framework arbeitet mit Request-Objekt, Response-Objekt, View-Objekt, Dispatcher, ActionController, Config-Klasse. Macht alles Sinn. Die Module können nach Bedarf eingebunden werden. Der Content wird eingesammelt und an die View übergeben. Die wiederum im Layoutscript dann untergebracht wird.

Gruß

jobo

[Pryos.org]

Hallo,

Hallo,

Zend Framework arbeitet mit Request-Objekt, Response-Objekt, View-Objekt, Dispatcher, ActionController, Config-Klasse. Macht alles Sinn. Die Module können nach Bedarf eingebunden werden. Der Content wird eingesammelt und an die View übergeben. Die wiederum im Layoutscript dann untergebracht wird.

Ich kenne mich mit Zend nicht wirklich aus. Da ich selten Frameworks benötige.
Jedoch klingen die Klassen und das was ich bisher von Zend gelesen habe sehr sinnvoll. Aber ich bezweifle Stark, das Zend alles mit Klassen macht, um beim Beispiel zu bleiben. Und nur darum ging es mir an der Stelle.

Natürlich gibt es viele Beispiele für den sinnvollen Gebrauch von Klassen, jedoch hab ich nie behauptet das Klassen selber Unsinn währen. Schon allein weil ich Sie selbst verwende.

Gruß
jobo

mfg Pryos

[jobo]

Hallo,

Zend Framework arbeitet mit Request-Objekt, Response-Objekt, View-Objekt, Dispatcher, ActionController, Config-Klasse. Macht alles Sinn. Die Module können nach Bedarf eingebunden werden. Der Content wird eingesammelt und an die View übergeben. Die wiederum im Layoutscript dann untergebracht wird.

Ich kenne mich mit Zend nicht wirklich aus. Da ich selten Frameworks benötige.
Jedoch klingen die Klassen und das was ich bisher von Zend gelesen habe sehr sinnvoll. Aber ich bezweifle Stark, das Zend alles mit Klassen macht, um beim Beispiel zu bleiben. Und nur darum ging es mir an der Stelle.

ZF arbeitet _nur_ mit Klassen. Der Autoloader sucht Zend_Klassenname_Unterklasse in Zend/Klassenname/Unterklasse. Z.b. den Zend_Controller_Front.

Die Url wird abgebildet auf Klasse/Funktion/Parameter1/Wert1. Mit der Routingklasse kannst du das konfigurieren, wenn nötig. In früheren Versionen gab es in er index.php und Bootstrap.php noch ein paar Zeilen Initilaisierungscode, aber da gibt es mittlerweile auch schon die Zend_Application-Klasse, wenn ich das recht sehe. Es gibt ja im Grunde auch nix in einer Webapplication, was nicht als Objekt fungieren könnte. Der Frontcontroller bringt noch eine statische Methode "getInstance" mit (Singleton-Pattern). Blick ich grad nicht ob er der einzige ist. Aber modulares Bauen, so wie ZF es macht, "geht" doch auch nur komplett stringent mit Klassen bzw. OOP, würde ich meinen.

Gruß

jobo

[Pryos.org]

Hallo,

Hallo,

... Aber modulares Bauen, so wie ZF es macht, "geht" doch auch nur komplett stringent mit Klassen bzw. OOP, würde ich meinen.

Jain. Natürlich, die Module etc müssen Klassen sein, da eine direkte Abarbeitung nur selten Sinn macht.

Jedoch muss ein modularer Aufbau selbst (der Aufruf der Module) kein Objekt sein. Die Konstrukte die ich bisher gesehen habe waren ein linearer Ablauf, welcher die Module nachgeladen hat und verarbeitet.

Ein Application-Objekt macht für mich nur Sinn, wenn man damit mehr macht als nur einen simplen Aufruf. Ein Objekt macht nur Sinn, wenn man es von Außen ansteuern möchte, und das hast du bei einer Applikation nicht, da sie selbst für Steuerung und Verarbeitung zuständig ist.

Bei Javascript macht so etwas mehr Sinn, weil du dort zur Laufzeit des Applikation-Objektes Einflüsse von Außen hast.

Gruß
jobo

mfg Pryos

[jobo]

Hallo,

Ein Application-Objekt macht für mich nur Sinn, wenn man damit mehr macht als nur einen simplen Aufruf. Ein Objekt macht nur Sinn, wenn man es von Außen ansteuern möchte, und das hast du bei einer Applikation nicht, da sie selbst für Steuerung und Verarbeitung zuständig ist.

Naja, das macht bei denen eben einen recht runden Eindruck:

"The above components make use of the industry standard web application design pattern MVC (which originated with one of the first scripting languages ever built, Smalltalk), and allows developers and web designers to separate their concerns and skills, making code implementation and design easily and clearly separated. No more confusion or needing both skill sets in one person."

http://framework.zend.com/about/overview

http://framework.zend.com/about/components

Gruß

jobo

[FRANKLIN J]

Hi.

ZF arbeitet _nur_ mit Klassen. Der Autoloader sucht Zend_Klassenname_Unterklasse in Zend/Klassenname/Unterklasse. Z.b. den Zend_Controller_Front.

Die Url wird abgebildet auf Klasse/Funktion/Parameter1/Wert1.

OUH.. ist zwar gerade Offtopic aber ich hab mir ein eigenes FW gebastelt das genauso arbeitet. Allerdings habe ich eine Sache noch nicht geklärt - wie verwalte ich JS und CSS?

Ich dachte daran das sich bei jeder Objekterstellung eine Methode aufruft und den Namen der Objekt-Klasse in ein Array speichert. Jeder Klasse ist eine Stylesheet und eine skriptdatei zugeordnet. Und die die vorhanden sind, die werden dann geladen.

Ist das irgendwie umsetzbar?

[jobo]

Hallo,

Ich dachte daran das sich bei jeder Objekterstellung eine Methode aufruft und den Namen der Objekt-Klasse in ein Array speichert. Jeder Klasse ist eine Stylesheet und eine skriptdatei zugeordnet. Und die die vorhanden sind, die werden dann geladen.

Naja die MVC-Variante bei Zend heißt erstmal ganz simpel, dass Kopf und Fuss im Layout-File abgelegt sind und einen Rahmen bilden, der dann mit $view->content gefüllt wird. Wieso denn verschieden CSS und JS-Files?

Gruß

jobo

[FRANKLIN J]

Wieso denn verschieden CSS und JS-Files?

Weil die CSS Datei 400 Zeilen und die JS Datei 1000 Zeilen lang ist und garnicht soviel auf jeder Seite benötigt wird.
Und ein schlechtes Argument noch: Es machen doch irgendwie alle großen Seiten.

[jobo]

Hallo,

Wieso denn verschieden CSS und JS-Files?
Weil die CSS Datei 400 Zeilen und die JS Datei 1000 Zeilen lang ist und garnicht soviel auf jeder Seite benötigt wird.
Und ein schlechtes Argument noch: Es machen doch irgendwie alle großen Seiten.

Kapier ich nicht. Jede Seite hat ihr spezifisches JS und CSS?

Gruß

jobo

[FRANKLIN J]

Kapier ich nicht. Jede Seite hat ihr spezifisches JS und CSS?

Ich noch nicht, aber so möchte ich es haben.

[dedlfix]

Hi!

Ich hab mich ehrlich gesagt noch nicht mit den Vor und Nachteilen von Mehrfachvererbung beschäftigt. Jedoch fällt mir auch spontan kein Fall ein, wo ich es verwenden würde.

Manches lernt man erst schätzen, wenn man einen konkreten Fall vorliegen hat und es dann da ist.

Man nehme eine Klasse, vielleicht aus einem Framework. Diese beerbe man. Außerdem möchte man neue Funktionalität haben, die dann aber nicht nur in dieser Klasse sondern auch in anderen Klassen. Das Framework erweitern und die Funktionalität einer Basisklasse hinzufügen ist nicht immer möglich und sinnvoll. Und auch wenn man den Code ändern kann, kann es passieren, keine gemeinsame Basisklasse zu finden. Mit Mehrfachvererbung kein Problem, da kann ich diese Funktionalität mehreren Klassen hinzufügen. Steht mir dieses Werkzeug nicht zur Verfügung kann ich nur ein Interface implementieren und muss dafür aber die Implementation in alle Klassen hineinkopieren, hab also bei einer Änderung x Codeteile, die zu ändern sind.

Zugegeben, diese Anwendungsfälle bilden (in meiner Erfahrung) eine recht kleine Randgruppe. Und ins Knie schießen kann man sich mit jeder Technik, dazu braucht es keine Mehrfachvererbung.

Lo!

[dedlfix]

Hi!

Polymorhie,
Ich wüsste nicht das PHP das kann.

Polymorphie ist ein vielgestaltiges Thema. Einige Aspekte davon sind auch in PHP vorhanden. Das Bekannteste dürfte das Überschreiben von Funktionen in erbenden Klassen sein.

class a {  
  function foo() {}  
  
  function bar() {  
    return $this->foo();  
  }  
}  
  
class b extends a {  
  function foo() {}  
}  
  
$a = new a();  
$b = new b();

$a->foo() ruft die Implementation der Klasse a auf und $b->foo() die von b.
$a->bar() ruft die Implementation der Methode foo() der Klasse a auf aber $b->bar() die von b.

Lo!

[Pryos.org]

Hi!

Hallo,

Polymorphie ist ein vielgestaltiges Thema. Einige Aspekte davon sind auch in PHP vorhanden. Das Bekannteste dürfte das Überschreiben von Funktionen in erbenden Klassen sein.

Ich glaube der richtige Begriff ist hier Überladen/Overload.

Polymorphie ist in meinen Augen das verändern der Signatür einer Klasse.

[code lang=php]class a {
  function foo() {}
  function foo($bar) {}
  function foo($bar, $foo) {}
}[code]

bzw.:

[code lang=php]class a {
  function foo($bar) {}
}

class a {
  function foo($bar, $foo) {}
}[code]

Lo!

mfg Pryos

[Pryos.org]

Polymorphie ist in meinen Augen das verändern der Signatür einer Klasse.

*hust* Signatur

[dedlfix]

Hi!

Ich glaube der richtige Begriff ist hier Überladen/Overload.
Polymorphie ist in meinen Augen das verändern der Signatür einer Klasse.
[code lang=php]class a {
  function foo() {}
  function foo($bar) {}
  function foo($bar, $foo) {}
}[code]

Eine nicht-statische Signatur ist unter PHP möglich, wenn auch nicht so wie man es von anderen Sprachen kennt und du es als Beispiel angegeben hast.

Eine Funktion / Methode kann es unter PHP nur einmal geben. Aber man kann Parameter optional machen oder ganz auf die Vorgabe von Parametern verzichten und die tatsächlichen mit func_get_args() und Konsorten abholen. Gut - das ist am Ende vielleicht keine Polymorphie, aber das Resultat ist das gleiche.

Lo!

[Pryos.org]

Hi!

Hallo,

Eine nicht-statische Signatur ist unter PHP möglich, wenn auch nicht so wie man es von anderen Sprachen kennt und du es als Beispiel angegeben hast.

Eine Funktion / Methode kann es unter PHP nur einmal geben. Aber man kann Parameter optional machen oder ganz auf die Vorgabe von Parametern verzichten und die tatsächlichen mit func_get_args() und Konsorten abholen. Gut - das ist am Ende vielleicht keine Polymorphie, aber das Resultat ist das gleiche.

Es ist keine Polymorphie :) nur darum ging es mir. Die Signatur bleibt immer identisch.
Aber ich kenn die Möglichkeiten die PHP in dieser Richtung bieten. Und es ist auch alles anders Lösbar. Auch wenn in den meisten Fällen vermutlich Eigenständige Methoden sinnvoller sind.

Lo!

mfg Pryos

[dedlfix]

Hi!

Es ist keine Polymorphie :) nur darum ging es mir. Die Signatur bleibt immer identisch.

Ja, schon klar, aber weißt du, Theorie versus Praxis. Manche Fachbegriffe sind wichtig, aber "Polymorphie" ist ein Begriff, denn ich in der Praxis noch nie gebraucht habe (also als Begriff. Gleichnamige Funktionen mit unterschiedlichen Signaturen setzt ich selbstverständlich ein - da wo das geht. Und weil ich den Begriff nicht verwende, war da auch meine Unsicherheit, was dessen Definition anbelangt). Ich denke, dass es unwichtig ist, ob es echte Polymorphie ist oder nur etwas, das so ähnlich aussieht und ein vergleichbares Ergebnis produziert.

Auch wenn in den meisten Fällen vermutlich Eigenständige Methoden sinnvoller sind.

Pauschal gesehen stimme ich dem nicht zu, denn dann bräuchtest du in der anderen Sprache auch keine Polymorphie. Es geht ja darum, dass etwas so aussieht wie ein und das selbe, nur mit unterschiedlicher Parameteranzahl. Wenn du den Methoden jeweils eigenständige Namen gibst, dann ist das in meinen Augen weder Polymorphie auf der einen Seite, noch sieht es dem auf der anderen Seite ähnlich.

Lo!

[Pryos.org]

Hi!

Hallo,

Ja, schon klar, aber weißt du, Theorie versus Praxis. Manche Fachbegriffe sind wichtig, aber "Polymorphie" ist ein Begriff, denn ich in der Praxis noch nie gebraucht habe (also als Begriff. Gleichnamige Funktionen mit unterschiedlichen Signaturen setzt ich selbstverständlich ein - da wo das geht. Und weil ich den Begriff nicht verwende, war da auch meine Unsicherheit, was dessen Definition anbelangt). Ich denke, dass es unwichtig ist, ob es echte Polymorphie ist oder nur etwas, das so ähnlich aussieht und ein vergleichbares Ergebnis produziert.

Ich musste auch erstmal nachschauen, was genau mit dem Begriff gemeint ist, als ich den Eingangspost gelesen habe. Mit "Signatur" konnte ich schon mehr anfangen.

Natürlich ist es letzten Endes egal. Ich sagte ja auch lediglich das PHP keine Polymorphie kann und nicht das es unmöglich ist das Problem zu lösen.
Jedoch ist es in jedem Fall aufwändiger als echte Polymorphie, da du die "Signaturerkennung" selbst schreiben musst. Dafür ist es aber auch Flexibler.

Pauschal gesehen stimme ich dem nicht zu, denn dann bräuchtest du in der anderen Sprache auch keine Polymorphie. Es geht ja darum, dass etwas so aussieht wie ein und das selbe, nur mit unterschiedlicher Parameteranzahl. Wenn du den Methoden jeweils eigenständige Namen gibst, dann ist das in meinen Augen weder Polymorphie auf der einen Seite, noch sieht es dem auf der anderen Seite ähnlich.

Natürlich pauschal gesehen ;). Und ich habe nie behauptet das das dann noch Polymorphie ist.
Sondern das Polymorphie nur selten zum Einsatz kommen sollte. Aber im Gegensatz zu anderen Techniken wüsste ich ein Einsatz wo es meistens Sinn macht: der Konstruktor.

Lo!

mfg Pryos

[Der Martin]

Hallo,

Polymorphie ist ein vielgestaltiges Thema.

man sollte es nicht für möglich halten. ;-)

*scnr*
 Martin

[Guy Gaz]

Hallo!

Polymorphie ist ein vielgestaltiges Thema.

man sollte es nicht für möglich halten. ;-)

*Das* sehe ich ja jetzt erst - sehr schön!

GG

[Guy Gaz]

Hallo!

Ich hätte von euch gerne mal ein paar Statements zu den Begriffen:
Interfaces, Namespaces, Polymorhie, Mehrfachverehrbung

und ihrer Rolle in PHP Skripten, Selfmade Frameworks, großen Webprojekten usw.

Die beiden zuletzt genannten Features kennt PHP nicht. Was genau magst Du wissen? Das ist ein sehr weites Feld...

Ich weiß einfach nicht wann diese Dinge wirklich SINN machen - ab wann macht es Sinn sie einzusetzen?

Nie - SCNR! Es kann aber einen Sinn haben, diese OOP-Features zu benutzen. Wenn Du nur alleine für Dich programmieren willst, kannst Du gerne weiterhin darauf verzichten. Entwickelst Du aber im Team, kann der Einsatz von Interfaces (als Vorgabe für ein zu entwickelndes API) durchaus sinnvoll sein, Namespaces habe ich in PHP noch nie gebraucht - in anderen Sprachen hat man da keine Wahl.

Ciao

GG

[Beat]

Namespaces habe ich in PHP noch nie gebraucht - in anderen Sprachen hat man da keine Wahl.

So? Das schöne an Perl ist ja, dass es flexiblen Möglichkeiten zum Namespace gibt.

mfg Beat

[Guy Gaz]

Hallo!

Namespaces habe ich in PHP noch nie gebraucht - in anderen Sprachen hat man da keine Wahl.

So?

Ja - ich dachte allerdings nicht an Perl.

Das schöne an Perl ist ja, dass es flexiblen Möglichkeiten zum Namespace gibt.

Schön und Perl? Ich habe lange nichts mehr damit gemacht (machen müssen) und ich erinnere mich durchaus daran, dass es Freude bereiten konnte damit zu arbeiten, aber Dank vieler Alternativen (für alles webaffine z.B. gerne PHP) setze ich Perl schon länger nicht mehr ein.

Ciao

GG

[Encoder]

Meiner Ansicht nach raubt das fast alles nur Performance

Jedes Stückchen Software raubt CPU-Zeit, Speicher und so weiter :-)

Aber ich nutze OO gerne, allerdings nicht in php (weil das nur freizeitmäßig mache). Dafür aber in größeren Projekten, wo man ohne fast keine Chance mehr hat, seinen Code zu kapieren und zu strukturieren.
Da ist dann gern auf ein paar Millisekunden gepfiffen, wenn das ganze dafür irgendwann mal halbwegs stabil läuft.
Außerdem glaub ich gar nicht dass das so viel Performance raubt. So manches bezieht sich nur auf den Compiliervorgang, wobei ich zugeben muss dass es damit bei php ja wieder anders aussieht als bei einer Sprache, die wirklich compiliert wird.

[Beat]

Mehrfachverehrbung

Ja, die fand statt, einmalig, und war dann abgeschlossen.
Aber wehe du erbst ein Software-Rad, und dem Maintainer kommt es in den Sinn ihm die prototypische _ist-vierreckig_ Erbschaft aufzustocken.

Oder anders gesagt: Raubkopiere das Rad, solange es noch rund ist.

mfg Beat

[Sven Rautenberg]

Moin!

Ich hätte von euch gerne mal ein paar Statements zu den Begriffen:
Interfaces,

Eine sehr schöne Methode, die Implementierung von definierten Methoden in unterschiedlichen Klassen zu garantieren, und dennoch Type-Hinting in der Parameterliste der diese Objekte nutzenden Methode sicherzustellen.

Interfaces will man haben. Insbesondere will man die Interfaces der SPL implementieren, wenn man sie braucht. Typischer Interfaces wären Countable, Iterator und ArrayAccess.

Vorteil von Interfaces ist, dass man in einer Klasse auch mehrere von ihnen implementieren kann - aber nur eine einzige Klasse unter "extends" angebbar ist. Dafür liefern Interfaces keinerlei Code der Methoden, die sie definieren.

Interfaces sind eine sehr schöne Sache, wenn man den Bedarf für sie erkannt hat.

Namespaces,

Irrelevant, solange PHP 5.3 noch keine ausreichende Verbreitung gefunden hat, und man es selbst nicht nutzen kann.

Polymorhie, Mehrfachverehrbung

Irrelevant für PHP, da nicht verfügbar.

und ihrer Rolle in PHP Skripten, Selfmade Frameworks, großen Webprojekten usw.

OOP ist ab einer gewissen Projektgröße aus einem einzigen Grund notwendig: Um die Übersicht zu behalten, komplexe Programmstrukturen zu vermeiden bzw. das insgesamt komplexe System in einfache Untereinheiten zu zerteilen, und das Duplizieren von Code zu vermeiden.

Frameworks sollte man nicht selbst schreiben. Bzw. sollte jeder Entwickler irgendwann mal ein Framework selbst schreiben - aber nur, um die Erfahrung zu machen, was zum Schreiben eines Frameworks alles dazugehört, nicht um es danach auch noch produktiv einzusetzen.

Meiner Ansicht nach raubt das fast alles nur Performance und bisher benutze ich sie nicht. Ich weiß einfach nicht wann diese Dinge wirklich SINN machen - ab wann macht es Sinn sie einzusetzen?

Du kannst alle deine Aufgaben grundsätzlich prozedural erledigen, keine Frage. Schließlich wird jegliche Objektorientierung irgendwann immer von einer sehr dummen CPU ausgeführt, die nur die ganz elementarsten Byteschiebeoperationen kennt - auf diesem Level betrachtet ist Objektorientierung also nicht existent, mit Ausnahme der zusätzlichen, sinnlos erscheinenden Operationen, die zusätzlich durchgeführt werden.

Objektorientierung hat nur einen einzigen Sinn: Dem Programmierer erleichtern, nicht nur einfache Aufgaben zu programmieren, sondern auch komplexe Aufgaben zu lösen. Denn die Objektorientierung erlaubt es, eine komplexe Aufgabe in viele einfache Teilaufgaben zu zerteilen, die Lösungen dieser Teilaufgaben in Objekten zu verpacken und die verpackten Lösungen dann, ohne Betrachtung ihrer Details, zur Lösung größerer Probleme zu verwenden.

Die Verpackung von Lösungen in Objekten ist dabei der zentrale Aspekt, denn er erlaubt es, sich jeweils nur auf das konkrete Problem konzentrieren zu können, indem man sich z.B. ein Objekt erschafft, welches gewisse Dinge komplett erledigt, und auf einer höheren Ebene dann nur noch in einer Programmzeile diese Methode aufruft, ohne den gesamten Quelltext an dieser Stelle sehen zu müssen.

Objektorientierung ist allerdings dann doch noch mehr, als nur das Schreiben von Funktionen. Die Erzeugung der richtigen Objekte, ihre Ausstattung mit den richtigen Daten sowie die Zusammenstellung der passenden Objekte innerhalb eines übergeordneten Objekts sind die Dinge, die man erst mit einer gewissen Erfahrung lernt.

Es hilft dabei übrigens, sich auch über das Testen der eigenen Software mal Gedanken zu machen bzw. sich Ausführungen zum Thema "Testbarer Code" zu Gemüte zu führen. Testbaren Code zu schreiben erlaubt nicht nur, ihn zu testen, sondern stellt gewisse grundsätzliche Forderungen auf, die dazu führen, dass der Code leichter lesbar und wartbar bleibt.

- Sven Rautenberg