Hi Tom!
Hm, aber das ist doch nur vernünftig. Man kann doch bei Eigenschaften des eigenen Objektes nicht von "globalen Variablen" sprechen, oder? Man braucht doch innerhalb eines Objektes keine solchen Schnittstellen wie von außen - IMHO.
Das ist eben die Frage, ob man einige Methoden einer Klasse nicht auch so bauen kann / bauen sollte, dass sie auch ohne die Abarbeitung der gesamte Klasse benutzbar sind.
Nein, das würde in meinen Augen dem OO-Konzept widersprechen. Ich betrachte ein Objekt als Einheit, mit bestimmten Eigenschaften und Methoden. Die öffentlichen Methoden stellen die Schnittstelle zur Außenwelt dar, private Methoden und Eigenschaften werden nur intern genutzt, und intern wird auch direkt auf selbige zugegriffen. Wichtig ist dass man nach außen hin eine gute API hat, so dass man die Arbeitsweise der Klasse intern komplett verändern kann, ohne Module, die diese Klasse benutzen angepasst werden müssen. Allerdings bekomme ich das in der Realität auch nicht immer so 100%ig hin, das liegt bei mir vor allem daran, dass ich teilweise sehr komplexe Objekte habe, dessen Arbeitsweise je nach Eigenschaften sich erheblich unterscheidet. Und hier komme ich auch mit Vererbung nicht wirklich auf einen grünen Zweig. Es ist in meinen Augen jedenfalls sinnvoll, mehr kleinere, spezialisierte Objekte zu verwenden, nur geht das leider nicht immer.
Bzw. wäre es ja der Sinn der Mthoden, dass ise ihre "Zuarbeiter" automatisch aufrufen, ich also einfach eine speziellee Methode der Klasse von außen aufrufe, und die sofort weiß, was zu tun ist...
In meinen Augen braucht eine Methode immer das komplette Objekte, daher wie bevorzuge ich wie gesagt möglichst kleine Klassen.
Jedenfalls sind hier zwei Konzepte durcheinander gekommen und ich muss nun sehen, was ich daraus mache. Da leigt aber an PHP 4, das noch keine echten Private Methods kannte.
Es liegt wohl eher an den Programmierern, die OOP nicht richtig verstanden haben ;-)
Wird Zeit, dass auch Private Funktions für die PP eingeführt werden!
was ist "die PP"?
Man sollte dich da am Unit-Konzept von Turbo pascal orientieren und alles wird gut.
Kenn ich nicht, aber was ist daran besser als an OOP?
Warum speicherst Du nicht das Bild an sich?
Weil das temporär erzeugte Bild immer noch Fehler enthält, die auf Konfigurationsmängeln beruhen, die in der DB gespeichert sind.
Und warum erzeugst Du das Bild dann nicht erst, wenn alles korrekt ist?
Und was steht da so in der Session? Wie kommen die Daten in die Session?
Genau DAS ist die Frage aller Fragen. Aber ich habe es jetzt wohl gleich (nur noch zwei Stunden schuften?). Ich muss eine neue Methode in die Klasse einbauen, die aus meinen gespeicherten Daten und sieben Tabellen das Objekt wiederherstellt, und dann die vorhandenen Methoden nutzen kann.
Ich würde die Methode(n) "refacroren", das heißt meist aufsplitten in mehrere Methoden/Objekte, die dann flexibler genutzt werden können, so dass Du nicht alles doppelt schreiben musst.
Aber der Dialog mit Dir hat mir doch noch ein paar "Rotstift-Stellen" aufgezeigt Danke!
gerne ;-)
Grüße
Andreas
SELFHTML Feature Artikel: http://aktuell.de.selfhtml.org/artikel/