Einteilung von Klassen bei OOP

[Christian Rieke]

Hi,

ich möchte eine "Mitglieder"-Verwaltung in php programmieren. Eine erste Version (mein Einstiegsprojekt in php) ist funktionsfähig, schreit aber nach Optimierung. Wenn ich den Code hier hereinsetze, würde ich wohl gesteinigt.
Mit der 2. Version möchte ich die Sache objektorientiert angehen, um Erweiterungen zu vereinfachen und um OOP kennenzulernen. Bin also absoluter Newbie.

Folgendes soll implementiert werden:
- Mitglieder, Dienste (mit Teilnehmern), Sitzungen (mit Teilnehmern) eingeben und ändern

Ausgaben:
- konkretes Mitglied mit allen besuchten Diensten und Sitzungen
- alle Mitglieder mit jeweils letztem besuchten Dienst und Sitzung (in verschiedenen Sortierungen
- Dienste und Sitzungen als Bericht mit Tätigkeit und Teilnehmern

weitere Fkt:
- Markierung von Daten je nach Alter: gültig, noch 3 Monate gültig, abgelaufen
- Emailbenachrichtigungen in Abhängigkeit von der Markierung

Nun die Frage: Wie ordne ich am sinnvollsten die Funktionalitäten bestimmten Klassen zu? Wieviele Klassen benötige ich?
Mein erster Tipp wären jetzt 4 Klassen:
class_Mitglieder mit Name, Vorname, Geb.Datum, Mitgliedsnr. als Attribute
class_dienst/class_sitzung mit Datum, Teilnehmer (?), Tätigkeit als Attribute
class_pruef mit den Markierungsfkt. und der Benachrichtigung

Würde mich über Hilfe freuen. Danke.

Gruß,
Christian Rieke

 

[StefanR]

Soviele Klassen brauchst du gar nicht gehe ich mal von aus.

Du kannst ja mehrere Methoden benutzen um die Daten zu sammeln, die du gerade auslesen möchtest und das denn am Ende mit ner eigenen Methode zusammenführen und zur Ausgabe bringen:

class mitglieder {
var $lalala //hier halt deine ganzen Eigenschaften

function mitglieder() {
//Instanzieren von den Eigenschaften und evtl. ausen liegenden Objekten
}

function _holSitzungen() {
//hier holst du denn die Sitzungen
}

function _hollalala() {
//....
}

function buildContent() {
//hier setzt du denn alles zusammen gibst es nur noch aus evtl. nen paar If Abfragen um das ganze einzugrenzen
}
}

Hoffe du hast es einiger Maßen verstanden.

 

[steff aka sId]

Na ich denke ganz so einfach ist es nicht stimmt schon das man einiges zusammen fassen kann. Aber ich denke auch das es sinnvoll ist sich für die Veranstaltungen/Sitzungen eine eigene Klasse zu machen. Also ich denke ganz grob kann man von dem Ansatz ausgehen jedes "real" Welt objekt bekommt seine eigene Klasse dann hast du eine saubere Trennung was du dann noch an eventuellen Verwaltungsklassen brauchst ist immer noch eine andere Frage.
Mein Vorschlag:
class_teilnehmer
class_veranstaltung

und dann je eine Klasse zur Verwaltung wobei das ein bisschen davon abhängig ist wie die Daten gespeichert sind:
class_verwaltung_teilnehmer
class_verwaltung_veranstaltung
Diese übernehmen die Darstellungsfunktionen/ Speicherung etc.

Die weiteren Funktionen hab ich nur zum Teil verstanden deshalb lasse ich die mal aussen vor.
Gruß Steff

 

[StefanR]

Naja gut denn würde ich aber eine Hauptklasse nehmen, die alles innitialisert, was für die Ausgabe bzw Bearbeitung notwendig ist und den Rest denn davon Abhängig machen, also ich würde es so machen, weil mir das ansonsten zu viele Objekte am Ende werden die ich Auslesen müsste im Script.

 

[steff aka sId]

Das stimmt wahrscheinlich das eine Hauptklasse vollkommen dabei Ausreicht die Teilnehmer und Veranstaltungen verwaltet. Wobei ich sagen muss in der Uni hatten wir letztens ein Projekt wo es vom Grunddesign schon so vorgegeben war das wir für jedes eine Verwaltungsklasse hatten und darüber dann nochmal eine Hauptverwaltungsklasse die alle einzel Verwaltungen verwaltet. Das ganze war allerdings in Java geschrieben was aber ja für den OO Ansatz net so den Unterschied macht.

Gruß Steff

 

[Christian Rieke]

Hi,

Naja gut denn würde ich aber eine Hauptklasse nehmen, die alles innitialisert, was für die Ausgabe bzw Bearbeitung notwendig ist und den Rest denn davon Abhängig machen, also ich würde es so machen, weil mir das ansonsten zu viele Objekte am Ende werden die ich Auslesen müsste im Script.

Wie sähe die Lösung mit einer Hauptklasse prinzipiell aus? Was ist eine Hauptklasse?

Gruß,
Christian

 

[Christian Rieke]

Hi,

Die weiteren Funktionen hab ich nur zum Teil verstanden deshalb lasse ich die mal aussen vor.
Gruß Steff

Ich denke mal, dabei ging es um die Markierung? Soll heißen: Hat ein Teilnehmer das letzte Mal vor zum Beispiel über einem Jahr an einer Sitzung teilgenommen, so ist diese abgelaufen und das Datum der Sitzung soll rot markiert werden. Ist die letzte Sitzung in 3 Monaten abgelaufen, soll sie gelb markiert werden. Diese Schwellen sollen auch für die Emailbenachrichtigung gelten: "Deine Sitzung läuft in 3 Monaten ab, bitte nimm an der nächsten teil"!

Gruß,
Christian

 

[KristophS]

Also ich verstehe den Sinn einer Klasse für die Verwaltung der Daten und einer zur Ausgabe, nicht. Prinzipiell solltest du ganz einfach für das Objekt, entweder die Mitglieder oder eben die Termine, eine Klasse bauen. Eine Hauptklasse halte ich für zuviel unnötige Daten, es sei denn die beiden Klassen brauche eine immens große innere Verzahnung, was ich aber nicht glaube -- zumindest falls ich das richtig verstanden hab und ihr nicht von einer Art "Vaterklasse" sprecht.

Die müsste so aussehen:

class Mensch //Vaterklasse
{
     private $Alter;
     private $Name;
     //usw. die Attribute/Methoden, die eben zu Mensch gehören
     function stirb()
     {
          geheInsJenseits();
     }
}
class Kind extends Mensch 
/* hier wird die gesamte Funktionalität der Klasse Mensch
der Klasse Kind vererbt,da ein Kind eigene, nicht für alle menschen zutreffende
Attribute hat, aber trotzdem ein Mensch ist*/
{
   //Hier dann eben die Attribute und Methoden die dem Kind eigen sind
  //allerdings können hier auch die Methoden, de KLasse Mensch genutzt 
  //werden wie eigene Methoden

  function spiele()
  {
       if($einMonsterFrisstDichAuf == true)
      {       
            $this->stirb(); //und ab gehts ins Jenseits!
       }
   }

}

 

[NRFi]

wie wärs mit Modell-View-Konzept?

Hauptklasse könnte doch schön die Sitzung sein, oder gibt es eine höhere Zuordnung?

zb. gibt es eine Sitzung mit mehreren Teilnehmern.

Teilnehmer ist als Array oder Collection in Sitzung.

will Jetzt Teilnehmer1 ne Nachricht an Teilnehmer2 schicken, sagt er.

$this->Parent(Sitzung quasi)->SendMessage("Für Hildegard","Hi, ich bin deine süße Message");

und Parent, also das Sitzungs-Objekt schickt das dann an die entsprechende Person.

Das lohnt sich, wenn es öfters passiert, dass bei einer Person etwas verändert wird, es sich auch gleich bei den anderen auswirkt. Kommt auf die Komplexität des Objektmodells an.

 

[steff aka sId]

Mit Hauptklasse meinte ich nur eine Klasse zur Verwaltung. Da es ja wahrscheinlich so aussieht das es viele Sitztungen mit vielen Teilnehmern gibt. Ich dachte es halt so das man dann eine Klasse Teilnehmer hat und dazu gehörig eine Klasse TeilnehmerVerwaltung die alle Teilnehmer in einem Array (oder sonst einer Datenstruktur) verwalted (neue Teilnehmer anlegen, Daten ausgeben etc.) Dann gibt es eine Klasse Veranstaltung und einer dazu gehörigen Veranstaltungsverwaltungs Klasse (Veranstaltungen anlegen, löschen, ausgeben, etc. Jeder Teilnehmer könnte funktionen haben die zum Beispiel die Veranstaltungen zurück geben können in denen er angemeldet ist. Zum Schluss noch eine Hauptverwaltungsklasse die im Prinzip die Teilnehmer mit den Veranstaltungen zusammen bringt d.h. zum Beispiel guckt ob ein Teilnehmer in einer Veranstaltung eingetragen ist die schon vorbei ist oder die in 3 Monaten ist und entsprechende Makierungsfunktionen hat.
Gruß Steff