Namensschema für Methoden einer Klasse ("Best Practise")

dreamcatcher · 30.05.2011, 22:23

Es geht in erste Linie um Konsistenz und Einfachheit.

Ich persönlich merke dass ich im Quellcode manchmal inkonsistent meine Namen vergebe und möchte dies nun ändern.

Dafür muss man ein gemeinsames Beispiel haben um aktiv daran arbeiten zu können.

Nehmen wir an wir haben eine Klasse mit dem Namen "Wetter".

Nehmen wir an die Datenbank sieht wie folgt aus:

PHP-Code:

  ID | Stadt | Jetziges_Wetter

Für diese Klassen möchten wir nun Methoden schreiben die folgendes können sollen (Stichwörter am Ende sind zur Markierung extra so verfasst):

Zitat:

1.) Neunen Eintrag anlegen (Insert)
2.) a.) Einzelne Column ändern Jetziges_Wetter (update)
2.) b.) Einzelne Column ändern Stadt (update)
3.) a.) Gesamte Row auswählen an Hand ID (select)
3.) b.) Gesamte Row auswählen an Hand Stadt (select)
4.) a.) Einzelne Column Jetziges_Wetter auslesen an Hand ID (select)
4.) b.) Einzelne Columns Jetziges_Wetter auslesen an Hand der Stadt (select)
5.) Einzelne klasseninterne Variable setzen (z.B. $_var)
6.) Einzelne Klasseninterne Variable auslesen (z.B. $_var)

Nun frage ich euch:
1.) Ist es überhaupt sinnvoll solch ein Schema zu haben ?
Denn einzelne Columns(Punkt 4.)) könnten z.B. auch per Row (3.) auslesen.
Somit würde man sich Schreibarbeit sparen, ist dieses "sparen" jedoch gut oder spart man am falschen Ende ?

2.) Wie würdet Ihr diese Methoden nennen ?
Es ist gang und gebe mit getter/setter zu arbeiten.
Ich komme aber leicht durcheinander wenn ich interne Variablen setze und etwas in die Datenbank speicher, da ich schnell inkonsistent benenne.

Hier meine Lösung zur oben genannter Aufgabenstellung:

Zitat:

1.) setRow($Stadt = '', $Jetziges_Wetter = '')
2.) a.) setColumnJetziges_Wetter ($ID)
2.) b.) setColumnStadt ($ID)
3.) a.) getRowById ($ID)
3.) b.) getRowByStadt ($Stadt)
4.) a.) getColumnJetziges_Wetter($ID)
4.) b.) getColumnJetziges_Wetter($Stadt)
5.) setVar ($var)
6.) getVar ($var)

3.)
Da ich in der Datenbank die Werte mit einem Underscore trenne, kommt alleine schon eine inkonsistenz bei dem Namen 2.)a.) zu stande, oder nicht ?
Sollte daher auch die Datenbank dem Quellcode angepasst werden oder ist der Methodenname einfach nur dämlich?

4.)
3.)a.) und 3.)b.) sind auch irgendwie "komisch" benannt, oder würdet ihr diese getter ähnlich nennen ?

Ich glaube die einfachste Frage ist, wenn Ihr solch einen Quellcode vor euch hättet, wie hättet ihr diesen am liebsten benannt dass ihr euch sofort reinfindet ?

Meine Absicht ist es möglichst "perfekten" Code zu schreiben, im Sinne von Konsistenz und "Durchschaubarkeit".

Wenn nikosch, tr0y oder ein anderer erfahrener PHP´ler mein Script anschaut soll er binnen kürzester Zeit wissen was Sache ist.

Vielen Dank für jeglichen Input.

Vor allem von erfahrenen Usern, die bestimmt desöfteren schon Probleme damit hatten und hier hoffentlich ihr Wissen preis geben.

nikosch · 30.05.2011, 22:27

Ich habe den Eindruck, Du verwürfelst hier Businesslogik (Domäne, Model) und Datenbankabstraktion/-zugriff. Ein Model wird nichts über seine Existenz (Herkunft) wissen, von daher kennt es auch kein getRow o.ä.

dr.e. · 30.05.2011, 22:34

Um die Frage zu beantworten: es gibt kein allgemeingültiges Schema. Die Frage ist doch: "Was möchtest du mit der Klasse modellieren?"

Deinen Ausführungen zufolge soll die Klasse "Wetter" ein DTO oder Domönen-Objekt sein, wobei letzteres nicht ganz zutreffen wird, da die Methoden eher den Anschein eines TableDataGateway-DTOs machen.

From the scratch: wenn du das Wetter in verschiedenen Städten modellieren möchtest, musst du dich fragen, welche Elemente du für eine Aussage wie "Das Wetter in Berlin ist schön." benötigst. Das wird ein Wetter-Objekt, eine Stadt und eine Beziehung zwischen beiden sein. Interessierst du dich für einfache Neuigkeiten (News), so reicht sicher ein einzelnes Objekt. Sofern wir über ein TableDataGateway sprechen, würde ich mit "Wetter" ein DTO erwarten, das seinen Zustand (schön, regnerisch, ...) und seine Stadt auf Anfreuge preis gibt:

PHP-Code:

  class Weather {
   public function getCity(){ ... }
   public function getState(){ ... }
}

Um es in der Datenbank zu speichern oder in der GUI zu addressieren, kann es auch eine Id haben:

PHP-Code:

  class Weather {
   public function getId(){ ... }
   public function getCity(){ ... }
   public function getState(){ ... }
}

Sofern du ein solches erzeugen und speichern möchtest, sollten entsprechende Konstruktor-Argumente oder setter vorhanden sein.

Das alles ist jedoch nur dann sinnvoll, wenn du noch einen Mapper besitzt, der das DTO in die Datenbank schreiben oder von dort lesen kann. Sofern du ein Domänen-Objekt implementieren möchtst, kann dieses noch einige Methoden wie load() und save() besitzten.

Du siehst also: die Frage ist nicht so einfach mit 1a) oder 2b) zu beantworten, sondern ist abhängig vom Kontext und dem WAS du entwerfen/modellieren möchtest.

dreamcatcher · 31.05.2011, 00:40

Uiuiui, dann muss ich wohl eine Etage tiefer anfangen.

@nikosch
Dies kann durchaus sein.

Zitat:

Zitat von dr.e.

Deinen Ausführungen zufolge soll die Klasse "Wetter" ein DTO oder Domönen-Objekt sein, wobei letzteres nicht ganz zutreffen wird, da die Methoden eher den Anschein eines TableDataGateway-DTOs machen.
[...]
Das alles ist jedoch nur dann sinnvoll, wenn du noch einen Mapper besitzt, der das DTO in die Datenbank schreiben oder von dort lesen kann. [...]

Vorweg:
Das Thema ORM ist das einzige Tutorial, welches ich mir bei der Zend_Tutorialreihe aus Zeitgründen (Über 2 Std, was einer Bearbeitungszeit von ~ 1 Tag gleich kommt) bisher nicht angeschaut habe.

Ich hatte mir mal Doctrine beiläufig als ORM angeschaut, jedoch dachte ich, dass ich dies nicht benötige.

Was ich gefunden haben :
http://media.adventure-php-framework...em_diagram.png

sowie die eine einfache Beispielmapperdatei mit "load" als Prefix:

http://rabbitphp.org/pages/domain-ob...object-example

Demnach hat der Mapper keine normalen getter und setter.

Wo dr.e. richtig lag ist, dass es sich um ein TableData Gateway handelt (TableDB Class von Zend).
Ist es denn wirklich falsch bzw. jenseits von "sauber" programmier, wenn ich der Zend_DBTable Class Methoden gebe welche die Daten in der Datenbank manipulieren bzw. getten/setten und diese dann direkt im Controller weiterverarbeite ?

Aus dr.e. Beispiel entnehme ich, dass Getter und Setter im TableDataGateway durchaus möglich sind.

Desweiterem entnehme ich dem Post, dass es keinen Bedarf gibt die gesamte Row ausgeben zu lassen als Array sondern - sofern mehrere Daten benötigt werden - die einzelnen Columns durch die Getter/Setter Methoden zusammengeschustert werden.
Ist dies korrekt ?

Die einzige Außnahme bildet natürlich das Update, welches als "save" betitelt werden darf.

Also würde dies so aussehen:

PHP-Code:

  1.) save($Stadt = '', $Jetziges_Wetter = '')
2.) a.) saveJetziges_Wetter ($ID)
2.) b.) saveStadt ($ID)
4.) a.) loadJetziges_Wetter($ID)
4.) b.) loadJetziges_Wetter($Stadt)
5.) setVar ($var)
6.) getVar ($var)

Soweit korrekt oder lohnt es sich zeitnah tiefer in die ORM Geschichte einzusteigen zwecks starker Notwendigkeit ?

nikosch · 31.05.2011, 01:08

Für mich würde sich eine Wetteranwendung in etwa so darstellen (nagel mich jetzt nicht auf die Begriffe fest, da hat der Doc durchaus mehr Softwaredesign inhaliert):

Der Benutzer (Client) stellt eine Anfrage an einen Manager. Z.B. gib mir das Deutschlandwetter, gib mir 7-Tage-Wetter für Postleitzahl xyz usw. Das Nutzerinterface abstrahiert also der Manager.
Der Manager verwaltet verschiedene Wetterobjekte. Je nachdem was die App bietet können das allgemeine und spezialisierte Objekte sein (allgemein: Deutschlandwetter, interpolierte Wetterdaten, speziell: Wetter(meß)daten für ein spezifisches PLZGebiet). Jedenfalls „guckt“ der Manager, ob er ein bestimmtes angefordertes Wetterobjekt in seinem Portfolio hat. In PHP wird das eher selten der Fall sein, in länger laufenden Apps (wie vielleicht auch Javascript) sammelt er über die Ausführungszeit eben angeforderte Objekte. Wenn ja mappt er eine Anforderung auf das bestehende Objekt, liefert es also aus. Auf das Wetterobjekt können dann die Abfragen der einzelnen Daten erfolgen. Hier haben wir die zweite Schnittstelle - getAverageTemperature () oder ähnliches.
verfügt der Manager nicht über ein passendes Wetterobjekt lädt er es aus der Datenschicht. Genauer: Er lässt es laden bzw. erzeugen. Dabei könnten potentiell z.B. einen Datenabstraktionsschicht und eine Factory beteiligt sein. Warum ich das sinnvoll halte, lass mich an einem Beispiel erklären:
Nehmen wir mal an, Du hättest eine Datenbank mit Gebiets- und Geodaten, um die Anfragen verwalten zu können. Die Datenbank speichert auch Zugangsdaten zu lokalen Wettermeßstationen in den einzelnen Städten. Die eigentlichen Meßdaten liefert dann vielleicht eine XML-Schnittstelle zu einem Service, den ein städtisches Wetteramt betreibt. Schon hast Du keine reine Datenbankabfrage mehr, auf die sich Dein Model stützt, sondern Du musst nach bestimmten Verfahren Geodaten auslesen, um über die Postleitzahl die Wetterstationenn zu ermitteln und dann über eine XML-Schnittstelle konkrete lokale Daten abfragen. Vielleicht will man dann noch einen Cache für die Daten benutzen. Jedenfalls alles gute Gründe, das Datenhandling separat abzuhandeln. Die gesamte Kommunikation mit beteiligten Datenschichten wie Datenbank, XML-Files, ferne Ressourcen und APIs bildet dann die dritte Schnittstelle. Diejenige, die Deinen vorgeschlagenen Methodenbezeichnern im Ausgangsthread vermutlich am nächsten kommt.
Umgekehrt funktioniert das dann genauso. Wird im Backend ein Wetterobjekt erstellt (natürlich eher ein Datenobjekt, als ein view-spezifisches), weist Du den Manager zum Schluß an, alle verwalteten Objekte mit der Datenbank zu synchronisieren - neue erfahren ein Insert, existierende falls nötig ein Update. Mit etwas Gehirnschmalz kann man hier sogar Datenbankoperationen zusammenfassen und muss nicht jedes Objekt einzeln verarbeiten.

Das mal so als Idee, wie eine Trennung in beteiligte Akteure motiviert sein kann.

ORM ist irgendwo schon wieder ein sehr spezielles Prinzip, was nicht generell auf die Problemstellung passen muss und m.E. auch nur einen Teil der Frage beantwortet.

xm22 · 31.05.2011, 09:39

Zitat:

save($Stadt = '', $Jetziges_Wetter = '')

Das halte ich (persönlich) für ungünstig. In anderen Sprachen gibt es zwar überladene Funktionen, aber für diese Eigenschaften hier würde ich das nicht verwenden. Das wird später eh überflüssig, wenn Du 20 Eigenschaften hast und immer andere füllen bzw. leer lassen willst. Dann lieber über Setter und Getter.

Absolutes No Go ist die Vermischung von Deutsch und Englisch.

Ich würde insofern auf bereits existierende ORMs setzen, als dass diese bereits jede Menge Funktionalität implementiert haben und Du i. d. R. nur eine Konfiguration und/oder "Model-Klassen" schreiben musst, was Dir jede Menge Arbeit abnimmt.

Zitat:

4.) a.) loadJetziges_Wetter($ID)
4.) b.) loadJetziges_Wetter($Stadt)

Anhand von was willst Du unterscheiden, was da übergeben wurde?

Irgendwie sieht das alles recht krude aus...

lcrash · 31.05.2011, 19:13

Wenn du schon Bei Zend_* warst, warum hast du dir nicht die Beispiele aus dem Quickstart angesehen? Dort gibt es drei Klassen für eine Datenbanktabelle (oder etwas anderes):
- ein Model, welches stupide die Daten hält und diese ins richtige Format bringt
- ein Mapper, welcher Daten aus einem Gateway abholt und diese in Models speichert
- bei Zend_Db eine Zend_Db_Table_Abstract-Instanz, welches als Gateway zur Datenbank fungiert, oder ein Gateway zu einer Datei, Service (wobei man hier überlegen müsste, ob ein Service-Layer nicht gleich besser wäre) usw.

nikosch · 31.05.2011, 21:01

Zitat:

Anhand von was willst Du unterscheiden, was da übergeben wurde?

Anhand des Objekttyps natürlich

xm22 · 01.06.2011, 09:39

Zitat:

Anhand des Objekttyps natürlich

Das klingt ja sehr generisch..

dr.e. · 01.06.2011, 18:23

Ich muss gleich zum Zug, darum nur kurz eine Frage: warum versteifst du dich so auf das TDG-Pattern? Überlege doch zunächst auf Business-Architektur-Ebene, welche Objekte im Spiel sind und welche Bedeutung diesen zukommt.

Themen-Optionen
Druckbare Version zeigen Jemanden per E-Mail auf dieses Thema hinweisen
Thema bewerten
Thema bewerten:

Ähnliche Themen
Thema	Autor	Forum	Antworten	Letzter Beitrag
Klasse mit Pfadproblem	Dieselsepp	PHP Einsteiger	6	27.04.2011 13:51
Wohin mit methoden	BlackScorp	Software-Design	9	24.03.2011 16:37
Seite nur im Script aufrufbar	BlackScorp	PHP Tipps 2010	4	03.11.2010 15:57
[Erledigt] Methoden zu einer Klasse hinzufügen	ByStones	PHP Tipps 2010	3	30.08.2010 23:58
[Erledigt] Klasse aus einer anderen Klasse aufrufen	Tobby	PHP-Fortgeschrittene	7	14.07.2010 20:05
[Erledigt] Nur einer bestimmten Klasse Zugriff andere Klasse erlauben	Turamisi	Software-Design	2	20.02.2010 20:31
Statische Methoden oder Singleton Klasse ?	lopelz	PHP Tipps 2009	7	30.12.2009 14:46
Klasse für Objekteigenschaft erzeugen?	Asipak	PHP-Fortgeschrittene	25	30.05.2009 19:45
[Erledigt] Eine klasse einbinden	newWorldOrder	PHP Tipps 2009	2	23.02.2009 19:32
Methode einer anderen Klasse aufrufen	Luka	PHP-Fortgeschrittene	15	09.11.2008 14:19
UML - Abstrakte und vererbte Methoden zwingend anzugeben?	MaMo-Net	Off-Topic Diskussionen	3	17.03.2008 06:04
reflection - wie führe ich alle methoden einer klasse aus...	Crypi	PHP Tipps 2008	2	20.02.2008 22:51
String-Parser Klasse - was muss rein?	Matze	PHP Tipps 2007	2	08.04.2007 22:14
mehr als eine Klasse einbinden	Alpha Centauri	PHP-Fortgeschrittene	4	13.04.2006 20:56
klassen und methoden anderer klassen in methoden....		PHP Tipps 2005	17	25.05.2005 09:46


Mister Ad PHP Code Flüsterer Registriert seit: 21.08.2005 Beiträge: 4682 PHP-Kenntnisse: Fortgeschritten

30.05.2011, 22:27
nikosch moderatives Dielektrikum Registriert seit: 21.05.2008 Beiträge: 35.994 PHP-Kenntnisse: Fortgeschritten	Ich habe den Eindruck, Du verwürfelst hier Businesslogik (Domäne, Model) und Datenbankabstraktion/-zugriff. Ein Model wird nichts über seine Existenz (Herkunft) wissen, von daher kennt es auch kein getRow o.ä. __________________ -- One pixel is still too big. Please make it smaller. ASAP. Initiative Mittelstand. Die wichtigste Gestaltungsregel im Screendesign ist Pi mal Daumen des Arbeitgebers. --

30.05.2011, 22:34
dr.e. Moderator und Wett-König Registriert seit: 21.05.2008 Beiträge: 3.657 PHP-Kenntnisse: Fortgeschritten	Um die Frage zu beantworten: es gibt kein allgemeingültiges Schema. Die Frage ist doch: "Was möchtest du mit der Klasse modellieren?" Deinen Ausführungen zufolge soll die Klasse "Wetter" ein DTO oder Domönen-Objekt sein, wobei letzteres nicht ganz zutreffen wird, da die Methoden eher den Anschein eines TableDataGateway-DTOs machen. From the scratch: wenn du das Wetter in verschiedenen Städten modellieren möchtest, musst du dich fragen, welche Elemente du für eine Aussage wie "Das Wetter in Berlin ist schön." benötigst. Das wird ein Wetter-Objekt, eine Stadt und eine Beziehung zwischen beiden sein. Interessierst du dich für einfache Neuigkeiten (News), so reicht sicher ein einzelnes Objekt. Sofern wir über ein TableDataGateway sprechen, würde ich mit "Wetter" ein DTO erwarten, das seinen Zustand (schön, regnerisch, ...) und seine Stadt auf Anfreuge preis gibt: PHP-Code: `class Weather { public function getCity(){ ... } public function getState(){ ... } }` Um es in der Datenbank zu speichern oder in der GUI zu addressieren, kann es auch eine Id haben: PHP-Code: `class Weather { public function getId(){ ... } public function getCity(){ ... } public function getState(){ ... } }` Sofern du ein solches erzeugen und speichern möchtest, sollten entsprechende Konstruktor-Argumente oder setter vorhanden sein. Das alles ist jedoch nur dann sinnvoll, wenn du noch einen Mapper besitzt, der das DTO in die Datenbank schreiben oder von dort lesen kann. Sofern du ein Domänen-Objekt implementieren möchtst, kann dieses noch einige Methoden wie load() und save() besitzten. Du siehst also: die Frage ist nicht so einfach mit 1a) oder 2b) zu beantworten, sondern ist abhängig vom Kontext und dem WAS du entwerfen/modellieren möchtest. __________________ Viele Grüße, Dr.E. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 1. Think about software design before you start to write code! 2. Discuss and review it together with experts! 3. Choose good tools (-> Adventure PHP Framework (APF))! 4. Write clean and reusable software only! ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

31.05.2011, 01:08
nikosch moderatives Dielektrikum Registriert seit: 21.05.2008 Beiträge: 35.994 PHP-Kenntnisse: Fortgeschritten	Für mich würde sich eine Wetteranwendung in etwa so darstellen (nagel mich jetzt nicht auf die Begriffe fest, da hat der Doc durchaus mehr Softwaredesign inhaliert): Der Benutzer (Client) stellt eine Anfrage an einen Manager. Z.B. gib mir das Deutschlandwetter, gib mir 7-Tage-Wetter für Postleitzahl xyz usw. Das Nutzerinterface abstrahiert also der Manager. Der Manager verwaltet verschiedene Wetterobjekte. Je nachdem was die App bietet können das allgemeine und spezialisierte Objekte sein (allgemein: Deutschlandwetter, interpolierte Wetterdaten, speziell: Wetter(meß)daten für ein spezifisches PLZGebiet). Jedenfalls „guckt“ der Manager, ob er ein bestimmtes angefordertes Wetterobjekt in seinem Portfolio hat. In PHP wird das eher selten der Fall sein, in länger laufenden Apps (wie vielleicht auch Javascript) sammelt er über die Ausführungszeit eben angeforderte Objekte. Wenn ja mappt er eine Anforderung auf das bestehende Objekt, liefert es also aus. Auf das Wetterobjekt können dann die Abfragen der einzelnen Daten erfolgen. Hier haben wir die zweite Schnittstelle - getAverageTemperature () oder ähnliches. verfügt der Manager nicht über ein passendes Wetterobjekt lädt er es aus der Datenschicht. Genauer: Er lässt es laden bzw. erzeugen. Dabei könnten potentiell z.B. einen Datenabstraktionsschicht und eine Factory beteiligt sein. Warum ich das sinnvoll halte, lass mich an einem Beispiel erklären: Nehmen wir mal an, Du hättest eine Datenbank mit Gebiets- und Geodaten, um die Anfragen verwalten zu können. Die Datenbank speichert auch Zugangsdaten zu lokalen Wettermeßstationen in den einzelnen Städten. Die eigentlichen Meßdaten liefert dann vielleicht eine XML-Schnittstelle zu einem Service, den ein städtisches Wetteramt betreibt. Schon hast Du keine reine Datenbankabfrage mehr, auf die sich Dein Model stützt, sondern Du musst nach bestimmten Verfahren Geodaten auslesen, um über die Postleitzahl die Wetterstationenn zu ermitteln und dann über eine XML-Schnittstelle konkrete lokale Daten abfragen. Vielleicht will man dann noch einen Cache für die Daten benutzen. Jedenfalls alles gute Gründe, das Datenhandling separat abzuhandeln. Die gesamte Kommunikation mit beteiligten Datenschichten wie Datenbank, XML-Files, ferne Ressourcen und APIs bildet dann die dritte Schnittstelle. Diejenige, die Deinen vorgeschlagenen Methodenbezeichnern im Ausgangsthread vermutlich am nächsten kommt. Umgekehrt funktioniert das dann genauso. Wird im Backend ein Wetterobjekt erstellt (natürlich eher ein Datenobjekt, als ein view-spezifisches), weist Du den Manager zum Schluß an, alle verwalteten Objekte mit der Datenbank zu synchronisieren - neue erfahren ein Insert, existierende falls nötig ein Update. Mit etwas Gehirnschmalz kann man hier sogar Datenbankoperationen zusammenfassen und muss nicht jedes Objekt einzeln verarbeiten. Das mal so als Idee, wie eine Trennung in beteiligte Akteure motiviert sein kann. ORM ist irgendwo schon wieder ein sehr spezielles Prinzip, was nicht generell auf die Problemstellung passen muss und m.E. auch nur einen Teil der Frage beantwortet. __________________ -- One pixel is still too big. Please make it smaller. ASAP. Initiative Mittelstand. Die wichtigste Gestaltungsregel im Screendesign ist Pi mal Daumen des Arbeitgebers. --

31.05.2011, 19:13
lcrash Erfahrener Benutzer Registriert seit: 11.04.2011 Beiträge: 260 PHP-Kenntnisse: Fortgeschritten	Wenn du schon Bei Zend_* warst, warum hast du dir nicht die Beispiele aus dem Quickstart angesehen? Dort gibt es drei Klassen für eine Datenbanktabelle (oder etwas anderes): - ein Model, welches stupide die Daten hält und diese ins richtige Format bringt - ein Mapper, welcher Daten aus einem Gateway abholt und diese in Models speichert - bei Zend_Db eine Zend_Db_Table_Abstract-Instanz, welches als Gateway zur Datenbank fungiert, oder ein Gateway zu einer Datei, Service (wobei man hier überlegen müsste, ob ein Service-Layer nicht gleich besser wäre) usw.

01.06.2011, 18:23
dr.e. Moderator und Wett-König Registriert seit: 21.05.2008 Beiträge: 3.657 PHP-Kenntnisse: Fortgeschritten	Ich muss gleich zum Zug, darum nur kurz eine Frage: warum versteifst du dich so auf das TDG-Pattern? Überlege doch zunächst auf Business-Architektur-Ebene, welche Objekte im Spiel sind und welche Bedeutung diesen zukommt. __________________ Viele Grüße, Dr.E. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 1. Think about software design before you start to write code! 2. Discuss and review it together with experts! 3. Choose good tools (-> Adventure PHP Framework (APF))! 4. Write clean and reusable software only! ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~