Hallo alle,

ich schwöre ja inzwischen auf Oo-Programmierung und lege für alles
mögliche Klassen an.
Ich habe mir das ganze durch eigenes Versuchen angeeignet und stosse
leider immer wieder an meine Grenzen und wollte mal nach anderen
Ansätzen fragen.
Also mein Vorgehen ist so, dass meine Klassen an sich erstmal halbwegs
unabhängig voneinander sind. Jedes Objekt bekommt bei der
Instanzierung auf jeden Fall einen Pfad übergeben. Wenn ich also eine
Anwendung habe, die mit "index.php?a=3D1" aufgerufen wird, bekommt ein
dort erstelltes Objekt "A" diesen Pfad mitgegeben, damit, wenn das
Objekt "A" selbst irgendwelche Links in die Seite einbaut, auf jeden
Fall auch die übergeordnete Instanz wieder aufgerufen wird.
Wenn mein Objekt "A" nun ein weiteres Objekt "B" instaziert, macht es
das genauso und hängt an den Pfad seine eigenen Parameter ran. Der
übergebene Pfad sieht dann z.B. so aus: "index.php?
a=3D1&objA_Action=3Dirgendwas&objA_ID=3D42.
Wenn ich meine Anwendung also streng hierarchisch aufbauen kann,
funktioniert das perfekt.
Wenn ich aber mal (um meine Anwendung ergonomischer zu gestalten) in
meinem Objekt B die "Action" in meinem Objekt A verändern will, müßte
ich den übergebenen Pfad manipulieren, damit sind dann aber meine
Klassen nicht mehr so unabhängig voneinander, und das gefällt mir
nicht mehr so.
Meine Klassen haben übrigens i.d.R. fast keine öffentlichen Methoden/
Eigenschaften. Bei der Instazierung gebe ich i.d.R. den Pfad und eine
DB-Verbindung mit und rufe anschliessend die einzige offentliche
Methode "work" auf, die sich aus GET- und Session-Variablen selbst
zusammensucht, was zu tun ist.
Was hierbei noch problematisch ist, ist wenn ich mehrere Objekte einer
Klasse instaziere, dann kann ich diese nur sehr umständlich über
Parameter im Querystring steuern.

Wie gesagt, das ist meine eigene bisherige Vorstellung von oo-
Programmierung mit php. Würde mich freuen, wenn mal jemand schreibt,
wie man es besser machen kann, oder einen Tip für einen tieferen
Einstig in umfangreichere Projekte mit PHP gibt.

Ich bin gespannt
Gruß von
Thomas

Thomas Huth schrieb:

....
> Wenn mein Objekt "A" nun ein weiteres Objekt "B" instaziert, macht es
> das genauso und hängt an den Pfad seine eigenen Parameter ran. Der
> übergebene Pfad sieht dann z.B. so aus: "index.php?
> a=1&objA_Action=irgendwas&objA_ID=42.

Ich denke nicht das so ein Vorgehen viel bringt:
* Suchmaschinen mögen solche 'Dynamischen' links gar nicht.
* Objekte können in komplizierten Kompositionen[1] zusammengewürfelt
werden warum sollten die dann einen Pfad wissen?
* Objekte sollten wiederverwendbar sein. Dabei muss die Instanz
nicht mal in einer Web-Umgebung laufen.

....
> Wenn ich aber mal (um meine Anwendung ergonomischer zu gestalten) in
> meinem Objekt B die "Action" in meinem Objekt A verändern will, müßte
> ich den übergebenen Pfad manipulieren, damit sind dann aber meine
> Klassen nicht mehr so unabhängig voneinander, und das gefällt mir
> nicht mehr so.

'Actionen verändern' tun in der OOP eher die Verhaltensmuster[2].

Meines Erachtens hast du einfach eine Menge von Vermittlern[3] gebaut.
Das währe nur ein (ganz) kleiner Teil der Leistungsfähigkeit von OOP.
Und als Schnittstelle benutzt das Get-/Session-Array, was nicht gerade
für gute Wartbarkeit spricht!

<Zitat>
Da der Vermittler ein Verhalten kapselt, das andernfalls auf mehrere
Klassen verteilt wird, ist er selbst komplexer als die einzelnen
Komponenten es gewesen wären. Es besteht die Gefahr, dass ein
monolithischer Programmkomplex entsteht, der schwer wart- und
erweiterbar ist.
</Zitat>

> Meine Klassen haben übrigens i.d.R. fast keine öffentlichen Methoden/
> Eigenschaften.

Eine Schnittstelle ist nichts böses! Du solltest Bevor du das
Programmieren anfängst Gedanken zu der Schnittstelle machen. Dann wird
das OOP erst sauber.
Niemals mit der Implementierung beginnen, ohne vorher zu wissen wie die
öffentlichen getter/setter und Methoden aussehen!

Programmiere auf ein Interface nicht auf eine Implementierung!

Je Logischer die Schnittstelle, um so einfacher fällt dir später das
benutzen des Objektes!

> Bei der Instazierung gebe ich i.d.R. den Pfad und eine
> DB-Verbindung mit und rufe anschliessend die einzige offentliche
> Methode "work" auf, die sich aus GET- und Session-Variablen selbst
> zusammensucht, was zu tun ist.

Die DB-Verbindung Übergeben? Lass Dir doch von einem Erzeugungsmuster[2]
ein Datenbankobjekt (PDO) zurückgeben!

> Was hierbei noch problematisch ist, ist wenn ich mehrere Objekte einer
> Klasse instaziere, dann kann ich diese nur sehr umständlich über
> Parameter im Querystring steuern.

Eben.

> Wie gesagt, das ist meine eigene bisherige Vorstellung von oo-
> Programmierung mit php.

Ich denke du hast falsche Vorstellungen von OOP. Gutes Buch:
Entwurfsmuster von Kopf bis Fuß /978-3897214217
Objektorientierte Analyse & Design von Kopf bis Fuß /978-3897214958

Ist zwar eher Java-Orientiert. Aber PHP guckt sich vieles von Java ab.

> Würde mich freuen, wenn mal jemand schreibt,
> wie man es besser machen kann, oder einen Tip für einen tieferen
> Einstig in umfangreichere Projekte mit PHP gibt.

[X] IMHO Done.


[1]http://de.wikipedia.org/wiki/Kompositum_%28Entwurfsmuster %29
[2]http://de.wikipedia.org/wiki/Viererbande_%28Softwareentwi cklung%29
[3]http://de.wikipedia.org/wiki/Vermittler_%28Entwurfsmuster %29

Thomas Huth wrote:

> ich schwöre ja inzwischen auf Oo-Programmierung und lege für alles
> mögliche Klassen an.

Gut...

> Ich habe mir das ganze durch eigenes Versuchen angeeignet und stosse
> leider immer wieder an meine Grenzen und wollte mal nach anderen
> Ansätzen fragen.

Schon Bücher oder Tutorials zu OOP in PHP5 gelesen?
http://www.professionelle-softwareentwicklung-mit-php5.de/er ste_auflage/

> Also mein Vorgehen ist so, dass meine Klassen an sich erstmal halbwegs
> unabhängig voneinander sind.

Diese Notwendigkeit existiert nur im begrenzten Umfang. Warum sollte
eine Klasse nicht mit einer Anderen Arbeiten?


> Jedes Objekt bekommt bei der
> Instanzierung auf jeden Fall einen Pfad übergeben.

Du redest hier nicht über OOP allgemein sondern über *Dein* spezielles
Anwendungsdesign. Halte sowas besser auseinander.

> Anwendung habe, die mit "index.php?a=1" aufgerufen wird, bekommt ein
> dort erstelltes Objekt "A" diesen Pfad mitgegeben

Das ist sehr schlecht. Da müßtest Du ja bei jeden anderslautenden
Parameter eine Eigene Klasse anlegen. Zudem sind solche URLs absolut
nichtssagend, was aber wieder ne andere Sache ist.

Du suchst nach den Zend-Framework. Darin ist eine wesentlich bessere
Umsetzung Deines Vorhabens enthalten. (Adapter, Action usw.)

> damit sind dann aber meine
> Klassen nicht mehr so unabhängig voneinander, und das gefällt mir
> nicht mehr so.

Es steht nirgendwo geschrieben das Klassen keine Abhängikeit haben
dürfen. Im Gegenteil! Es ist eher ein Vorteil das sie das dürfen.

> Was hierbei noch problematisch ist, ist wenn ich mehrere Objekte einer
> Klasse instaziere, dann kann ich diese nur sehr umständlich über
> Parameter im Querystring steuern.

Was an Deinem Aufbau liegt.

> Wie gesagt, das ist meine eigene bisherige Vorstellung von oo-
> Programmierung mit php.

Also kennst Du nur einen Winzigen Teil dessen was Dir OOP bietet. Beles
Dich erst mal.

--
_,
_(_p> Ulf [Kado] Kadner
\<_)
^^

Thomas Huth meinte:
> Hallo alle,
>
> ich schwöre ja inzwischen auf Oo-Programmierung und lege für alles
> mögliche Klassen an.
> Ich habe mir das ganze durch eigenes Versuchen angeeignet und stosse
> leider immer wieder an meine Grenzen und wollte mal nach anderen
> Ansätzen fragen.
> Also mein Vorgehen ist so, dass meine Klassen an sich erstmal halbwegs
> unabhängig voneinander sind.

Was ist "halbwegs"?

> Jedes Objekt bekommt bei der
> Instanzierung auf jeden Fall einen Pfad übergeben. Wenn ich also eine
> Anwendung habe, die mit "index.php?a=1" aufgerufen wird, bekommt ein
> dort erstelltes Objekt "A" diesen Pfad mitgegeben, damit, wenn das
> Objekt "A" selbst irgendwelche Links in die Seite einbaut, auf jeden
> Fall auch die übergeordnete Instanz wieder aufgerufen wird.

Wozu das? Eine DB-Wrapper-Klasse wird wohl kaum Links generieren und
"Pfade" wissen müssen. Eine solche Klasse wird von anderen Klassen
aufgerufen und stellt über Methoden und Properties Ergebnisse bereit. Da
braucht man keine "Pfaderweiterungen".

> Wenn mein Objekt "A" nun ein weiteres Objekt "B" instaziert, macht es
> das genauso und hängt an den Pfad seine eigenen Parameter ran. Der
> übergebene Pfad sieht dann z.B. so aus: "index.php?
> a=1&objA_Action=irgendwas&objA_ID=42.
> Wenn ich meine Anwendung also streng hierarchisch aufbauen kann,
> funktioniert das perfekt.

Faszinierend...

> Wenn ich aber mal (um meine Anwendung ergonomischer zu gestalten) in
> meinem Objekt B die "Action" in meinem Objekt A verändern will, müßte
> ich den übergebenen Pfad manipulieren, damit sind dann aber meine
> Klassen nicht mehr so unabhängig voneinander, und das gefällt mir
> nicht mehr so.

Die Klassen sind also offensichtlich *nicht* unabhängig - und waren es
auch nie.

> Meine Klassen haben übrigens i.d.R. fast keine öffentlichen Methoden/
> Eigenschaften. Bei der Instazierung gebe ich i.d.R. den Pfad und eine
> DB-Verbindung mit und rufe anschliessend die einzige offentliche
> Methode "work" auf, die sich aus GET- und Session-Variablen selbst
> zusammensucht, was zu tun ist.

Warum muss sich das die Klasse bzw. Instanz zusammensuchen? Um beim
DB-Wrapper zu bleiben: Der weiss, dass er für Datenbankfunktionen
zuständig ist. Bei der Instanzierung baut er die Connection auf. Die
Instanz stellt dann (öffentliche) Query-Methoden, Datenpflege-Methoden,
Fehlerbehandlungsmethoden etc. zur Verfügung. Und diese werden dann auch
direkt aufgerufen.

> Was hierbei noch problematisch ist, ist wenn ich mehrere Objekte einer
> Klasse instaziere, dann kann ich diese nur sehr umständlich über
> Parameter im Querystring steuern.

Vergiss einfach auf den Querystring als zentrales "Steuerelement".

> Wie gesagt, das ist meine eigene bisherige Vorstellung von oo-
> Programmierung mit php. Würde mich freuen, wenn mal jemand schreibt,
> wie man es besser machen kann, oder einen Tip für einen tieferen
> Einstig in umfangreichere Projekte mit PHP gibt.

Für OOP gibt's Bücher und Online-Ressourcen, Bibliotheken und Tutorials
wie Sand am Meer. Es muss ja nichtmal unbedingt PHP sein. Hinsetzen und
Lesen.

Gruß, Gregor



--
http://www.gregorkofler.at ::: Landschafts- und Reisefotografie
http://www.licht-blick.at ::: Forum für Multivisionsvorträge
http://www.image2d.com ::: Bildagentur für den alpinen Raum

Hallo,

besten Dank schonmal auch für alle anderen bisherigen Antworten. Ich
wollte ja nur mal bestätigt bekommen, dass ich auf dem Holzweg bin.

Ulf Kadner <dr_lo... [at] gmx.net> wrote:
>=2E..
> Schon Bücher oder Tutorials zu OOP in PHP5 gelesen?http://www.professio=
nelle-softwareentwicklung-mit-php5.de/erste_auflage/
>
damit werde ich mich in nächster Zeit mal intensiver beschäftigen.
..=2E.
> > Jedes Objekt bekommt bei der
> > Instanzierung auf jeden Fall einen Pfad übergeben.
>
> Du redest hier nicht über OOP allgemein sondern über *Dein* spezielles
> Anwendungsdesign.
>
klar, das habe ich aber eigentlich deutlich gemacht.

> > Anwendung habe, die mit "index.php?a=3D1" aufgerufen wird, bekommt ein
> > dort erstelltes Objekt "A" diesen Pfad mitgegeben
>
> Das ist sehr schlecht. ...
das habe ich ja auch festgestellt.

> Du suchst nach den Zend-Framework. Darin ist eine wesentlich bessere
> Umsetzung Deines Vorhabens enthalten. (Adapter, Action usw.)
>
> > Wie gesagt, das ist meine eigene bisherige Vorstellung von oo-
> > Programmierung mit php.
>
> Also kennst Du nur einen Winzigen Teil dessen was Dir OOP bietet. Beles
> Dich erst mal.
>

Ich denke, ich werde demnächst, was dieses Thema angeht, etwas
schlauer werden ;-)

Bis demnächst also,
Gruß von
Thomas

> Wie gesagt, das ist meine eigene bisherige Vorstellung von oo-
> Programmierung mit php. Würde mich freuen, wenn mal jemand schreibt,
> wie man es besser machen kann, oder einen Tip für einen tieferen
> Einstig in umfangreichere Projekte mit PHP gibt.

OOP ist aus meiner Sicht primär Kapselung von Daten und "Objekte reden
mit Objekten".

Beispiel: angenommen ich habe eine Datenbanktabelle User mit den Feldern
login, name, surname, password und admin, wobei admin in typisch miesem
Design ein Enum('Y','N') ist. Die Daten halte ich in einem Array. In
einer Funktion, die z. B. einen Dateiupload steuert, sieht das dann z.
B. wie folgt aus:
function delete() {
global $user;
if($user["admin"]=="Y") {
// erlaube irgendetwas.
}
}

So. OOP ist jetzt, dass ich ein Objekt baue, dem ich z. B.
login/passwort übergebe und dass dann die Daten des Benutzers vorhält.
Es hat eine Methode isAdmin:
function isAdmin() {
return $this->userdata["admin"]=="Y";
}

Die Dateiupload-Klasse baue ich z. B. so, dass sie fest das Objekt User
erwartet und verwendet:
class Upload {
protected $dir;
protected $user;
function __construct($dir, User $user) {
$this->dir = $dir;
$this->user = $user;
}

function delete() {
if($this->user->isAdmin()) {
// erlaube etwas
}
}
}

Oholla! Denn wenn ich jetzt an der Datenbank ändere, dass enum('Y', 'N')
zu TINYINT(1) oder BOOLEAN wird, wie es sich gehört, dann muss ich nur
User::isAdmin anfassen. Und 'new Upload("bilder/hunde/katzen/");' wird
ganz gnadenlos abrauchen und mir sagen, wieso, wenn ich $user vergesse.

Das ist auch in grösseren Teams ganz nett, weil ich theoretisch einem
Mitarbeiter die Mail schreiben kann: bitte schreib doch mal eine Klasse
für den User mit der Methode isAdmin(), die zurück geben soll, ob der
User den Flag Admin hat oder nicht. Das finde ich etwas zuverlässiger
als "sorge dafür, dass in $GLOBALS["user"] ein Array mit den Daten des
Users steht, und das der Admin-Status in $GLOBALS["user"]["admin"]
definiert ist als "Y" (grossgeschrieben!)".

Soviel zum tieferen Sinn...und lass Dich nicht beirren.
--
Mein Zeugs:
http://www.hadanite-marasek.de/classes.php
http://www.objektivsuche.de/