header Location in while Schleife?

[Rolf B]

Hallo Bastian,

Allerdings weiß ich nicht genau, wie fpdf das macht, denn ich habe in der Klasse keinen Konstruktor gefunden.

PDF_MC_Table_WA muss auch keinen haben, wenn diese Klasse ihrerseits eine Subklasse von FPDF ist. FPDF hat auf jeden Fall einen, guckst Du hier - ugh, ein Frameset? Hier ist die Haupt-Dokuseite

Da steht auch, was die Parameter P und mm bedeuten 😀: Orientierung (P=Portrait) und Einheit (mm=Millimeter).

Und der Unterscheid zu Getter und Setter?

Die gibt's in PHP als Sprachelement nicht. Rein konzeptionell natürlich schon, analog zur Sprache Java kannst Du Methoden namens get_id und set_id schreiben, die diesen Job erfüllen.

<Exkurs> In Sprachen wie JavaScript oder C# ist das anders, die haben eine spezielle Syntax für Getter und Setter und unterscheiden dann auch auf Sprachebene zwischen Property (das Pärchen aus Getter und Setter) und Field (das, was wir hier bislang als Eigenschaft bezeichnet haben). Damit sind wir aber nun schon ziemlich tief in den OO Konzepten.</Exkurs>

Ob es sinnvoll ist, getter und setter zu verwenden, kann unterschiedliche Gründe haben. Einer ist dogmatisch: Objekte kapseln ihre Daten und erlauben den Zugriff darauf NUR über Methoden. Diese Dogma wurzelt in einer noch älteren Sicht auf Objekte - ein Objekt empfängt und sendet Botschaften. Wenn Du den Wert der Eigenschaft "id" wissen willst, musst Du die Botschaft "sag mir Deine ID" schicken und bekommst als Antwort die Botschaft "Meine ID ist 47". Rein formal kann man das bauen, rein praktisch ist das strikt inkompatibel zum gewohnten prozeduralen Konzept von Funktionsaufruf und Rückgabewert. Deswegen implementieren die meisten OOP Sprachen das Botschaftenkonzept als Methoden, die analog zu Funktionen aufgerufen werden. Eine strikte Implementierung durch Botschaften findet man bspw. in der Sprache Erlang, wodurch sich Erlang-Programme superleicht auf viele Prozessorkerne verteilen lassen. but I digress...

Der direkte Zugriff auf Eigenschaften widerspricht der OO-Idee nach wie vor, deswegen ist es in Java einfach üblich, Getter und Setter zu schreiben. Zwingend nötig ist es nicht, auch Java kennt public fields. Wie gesagt: Dogma.

Es gibt aber auch praktische Gründe für getter und setter.

• Ein Setter erlaubt es, Plausibilitätsprüfungen durchzuführen. Eine direkte Zuweisung an eine Eigenschaft erlaubt das nicht. Hat also Vorteile. Wenn Du Plausis brauchst, die mehrere Eigenschaften im Zusammenhang validieren, dann habe ich auch schon man an Stelle eines Setters eine Initialize-Methode programmiert, die mehrere Parameter bekommt und die übergreifende Validierung übernommen hat.

• Ein Getter kann eine virtuelle Eigenschaft abbilden, also eine Eigenschaft, die das Objekt eigentlich gar nicht hat. Beispielsweise ein Objekt "Kreis" mit den Eigenschaften Radius und Fläche. Der Radius ist eine echte Eigenschaft, und die Fläche kann man bei Bedarf per $$A=\pi r^2$$ berechnen. Wenn Du einen Zoo von Form-Objekten hast, und jedes hat einen Getter "get_Area", dann kann ein Kreis oder ein Rechteck die Fläche beim Zugriff bestimmen, und ein durch Bezierkurven eingeschlossenes Dings muss die Fläche zusammenintegrieren - das tut es nur einmal und speichert das Ergebnis dann ab.

Auf diese Weise können Getter und Setter die Details abschirmen, wie bestimmte Dinge im Objekt implementiert sind. Und Du kannst die Implementierung ändern, ohne dass es jemand merkt. Ein weiterer Vorteil ist, dass Getter und Setter Methoden sind, d.h. man kann sie als Teil eines Interface deklarieren. Mit Eigenschaften geht das nicht. Wenn Du ein Objekt abstrakt über ein Interface verwenden willst, brauchst Du getter und setter. Aber das ist jetzt wieder sehr tief gehend. Für deinen Fall reichen die einfachen Eigenschaften vermutlich aus.

Darf ich auch in der Klasse Eigenschaften setzen, denen ich dann später keinen Wert zuweise?

Darfst Du - aber dann darfst Du Dich auch nicht über den RRRUMMS wundern, der ertönt, wenn Du diese Eigenschaft versehentlich verwendest 😉. Ohne Zuweisung enthält eine Eigenschaft den Wert NULL.

Rolf