Der-Dennis: OOP: Design Patterns (Factory Method, Dependency Injection, ...)

Beitrag lesen

Hey Tom,

erst einmal danke für Deine Antwort.

Komponenten von bereits existierenden Frameworks oder anderen Drittanbietern sollen laut Aufgabenstellung nicht verwendet werden.

Die BB-Klasse von Christian Seiler würde ich aber keinesfalls neu erfinden müssen ;-)

Möchte ich auch nicht. Ich kann zur Zeit nur leider nichts daran ändern, habe aber die Hoffnung, dass wir nach den ersten "eigenen" Ansätzen noch einmal die Möglichkeit bekommen, für eine Lösung aus eigenen und fremden Komponenten zu plädieren und dies dann auch angenommen wird.

Außerdem soll dem Framework die gerade aktuellste PHP-Version (derzeit 5.3.6) zugrundegelegt und der Funktionsumfang wie Namespaces, etc., auch genutzt werden.

Ist die auch ohne Fehler?

Das weiß ich leider nicht. Ich habe damit bisher noch nicht gearbeitet und werde daher auch "ins kalte Wasser" geworfen. Weißt Du etwas über eventuelle Fehler?

Da das Framework von der Implementierung her natürlich in sich konstistent sein und auch in Zukunft noch den Anforderungen gerecht werden soll, stellt sich jetzt die Frage, welche Design Patterns für viele Komponenten verwendet werden sollen. Eine zum jetzigen, frühen Zeitpunkt durchdachte Wahl erspart später sicherlich viel Arbeit.

"Design Patterns" sollten eigentlich nur eine Anregung darstellen. Im Spezialfall könnte man aus den verschiedenen Kompnenten auch eine eigene Lösung zusammenbauen, die es besser trifft.

Das auf jeden Fall. Aber es gibt innerhalb eines Frameworks ja doch viele Fälle, in denen verschiedene Pattern zum gleichen Ergebnis führen. Und um genau diese geht's. Wie im zuvor genannten Beispiel.
Grundsätzlich sollte also (natürlich nur, wenn dies sinnvoll ist) das gleiche Pattern für ähnliche Zwecke verwendet werden, damit es konsistenter und somit einfacher in der Verwendung ist.

Um das "Problem" zu verdeutlichen, möchte ich von einer Klasse ausgehen, die Konfigurationsdaten aus verschiedenen Quellen (z.B. INI, XML, ...) lädt und anschließend für späteren Zugriff speichert. Folgende Möglichkeiten zur Umsetzung haben wir uns bisher überlegt:

  1. Einzelne Klasse
    Die Klasse enthält lediglich je eine eigene Funktion für die möglichen Quellen.

Meinst Du wirklich "Funktion" oder meinst Du "extern zugängliche Methode"?

Du hast natürlich recht. Ich meinte "Methode". Wobei Du mich gerade darauf bringst: Es könnte ja eine interne oder eine externe Methode sein, wobei die interne Methode dann vom Konstruktor aufgerufen würde.
Ich müsste also Punkt 1) noch in
a) eine interne, durch den Konstruktor aufzurufende Methode und
b) eine öffentliche Methode
aufteilen.

Gruß, Dennis

0 70

OOP: Design Patterns (Factory Method, Dependency Injection, ...)

Der-Dennis
  • php
  1. 0
    Tom
    1. 0
      Der-Dennis
      1. 0
        Tom
    2. 0
      Tom
      1. 0
        Der-Dennis
    3. 0
      dedlfix
      1. 0
        Tom
        1. 0
          dedlfix
          1. 0
            Der-Dennis
            1. 0
              Der-Dennis
              1. 0
                jobo
                1. 0
                  Tom
                  1. 0
                    Der-Dennis
                    1. 0
                      Tom
                      1. 0
                        Der-Dennis
                        1. 0
                          Tom
                          1. 0
                            Der-Dennis
                            1. 0
                              Tom
                              1. 0
                                Der-Dennis
                2. 0
                  Der-Dennis
            2. 0
              Sven Rautenberg
              1. 0
                jobo
                1. 0
                  Der-Dennis
  2. 0

    Konfigurationsklassen für ein MVC-Framework

    Feldspar
    • programmiertechnik
    1. 0
      Der-Dennis
      1. 0
        Feldspar
        1. 0
          Der-Dennis
  3. 0
    dedlfix
    1. 0
      Der-Dennis
      1. 0
        dedlfix
        1. 0
          Der-Dennis
          1. 0
            dedlfix
            1. 0
              Der-Dennis
              1. 0
                dedlfix
                1. 0
                  Der-Dennis
  4. 0

    OOP: Design Patterns ... -> Zend Framework

    jobo
    1. 0
      Der-Dennis
      1. 0
        jobo
        1. 0
          Der-Dennis
          1. 0
            dedlfix
            1. 0
              jobo
  5. 0
    Sven Rautenberg
    1. 0
      jobo
      1. 1
        Sven Rautenberg
        1. 0
          jobo
          1. 0
            Der-Dennis
    2. 0
      Der-Dennis
      1. 0
        Sven Rautenberg
        1. 0
          Der-Dennis
      2. 0
        dedlfix
        1. 0
          Der-Dennis
          1. 0
            dedlfix
            1. 0
              Der-Dennis
              1. 0
                dedlfix
                1. 0
                  Der-Dennis
                  1. 0
                    dedlfix
                    1. 0
                      Der-Dennis
                      1. 0
                        dedlfix
                        1. 0
                          Der-Dennis
  6. 0

    Bin erst am Montag wieder da

    Der-Dennis
  7. 0
    hotti
    1. 0
      hotti
      1. 0
        Der-Dennis
        1. 0
          hotti
          1. 0
            Der-Dennis
            • perl
          2. 0
            dedlfix
            1. 0
              Der-Dennis
        2. 0
          hotti
          1. 0
            Der-Dennis
            • perl