nicht angemeldet
Halihallo Andreas
Ich habe aber vor allem Probleme mit den verschiedenen 'Ebenen'. Philipps Beispiel war wirklich hilfreich, aber ich verstehe nicht, warum man da so viele Klassen für braucht?!
ach, wirklich brauchen tut man wenig ;-)
Aber ich verfolge immer den Ansatz, möglichst gleiche Sachen auch in einer Klasse zu coden (das ist auch der Sinn von OOP). Wenn du nun z. B. getPrice aus der Warenkorbklasse aufrufen würdest (was ja unbestritten auch ginge), wäre das ein Verstoss gegen die "Vorschriften" von OOP ;)
getPrice ist _Artikel_ bezogen und nicht _Warenkorb_ bezogen. Deshalb sollte die Methode auch in einer entsprechenden Klasse zur Verfügung stehen (CartItem, oder Artikel, oder wie auch immer; auf jeden Fall nicht Cart oder Warenkorb)...
Aber am Schluss steht es jedem frei, wie komplex/einfach er die Klassen definieren will...
Wenn du wenige Klassen hast, wird eventuell die Performance besser, da du z. B. in der SQL Lösung den Price mit sum() berechnen kannst, und nicht über die OOP-Instanzen iterieren musst. Wenn du viele Klassen hast, wird die "Architektur" logischer und die Sourcelistings kürzer... Jedem das seine eben ;)
Ich denke im Augenblick, das man mit 2 Klassen auskommen sollte, eine Warenkorb-Klasse in der man allgemeine Angaben bekommt, Artikelzahl, Summe über die Preise x Anzahl - und eine Artikel-Klasse, in der für einen Artikel der Einzelpreis, die Anzahl, eine Bezeichnung und ID stehen.
Jup. Ich denke, dass dies sogar bereits genug "schön" und logisch aufgesplittet ist. User fällt ja eh weg, da dies implizit mit der Session gehandhabt wird...
Das Problem, ich brauche eine Instanz Warenkorb, aber mehrere, sagen wir mal 3 Instanzen für die Artikel Klasse, für 3 Artikel.
Entsprechend müßte ich sowas mit dem Warenkorb machen, eine Instanz... das sollte auch klappen, nur wie bekomme ich jetzt mehrere Instanzen für die verschiedenen Artikel? Halt dynamisch, wie ich mehrere Instanzen bekomme weiß ich wohl, aber halt genau die entsprechenden für die Artikel im Warenkorb! Kann ich das in der Warenkorbklasse machen? Wie - und wie greife ich im Script drauf zu?
Also ich mach das so:
Warenkorb
getArticles
getArticles
foreach (@articles) { # für jeden Artikel in der Session mach...
- $tmp = neue Instanz von Artikel...
- die Instanz in ein Array packen...
}
return InstanceArray; # das "InstanzenArray" zurückgeben
Hauptprogi
$cart = new Warenkorb;
@array_of_instances = $cart->getArticles
foreach $article (@array_of_instances) { # so, und nun möchten wir die Artikel im Warenkorb behandeln
print $article->getProductDescription;
}
Und noch ein Problem, wenn ich das jetzt mit der DB mache, und die Artikel in einer Schleife aufliste, immer mit verschieden Funktionen wie getPreis, getID, getAnzahl... und in jeder einzelnen Funktion eine SQL-Abfrage machen würde, und das für jede Instanz nochmal, dann wird das aber wohl eine Ecke unperformanter und umständlicher, als wenn ich wie 'früher' eine einzige Abfrage mache, und die in der Schleife auslese bzw. anzeige, oder?
Ja, das stimmt. Aber es ist "schöner" :-))))))
Naja, auch die schönste OOP-Architektur hat ihre Nachteile. Aber einige davon kann man vielleicht lösen...
Theoretisch wäre ja auch folgende Klasse denkbar:
CartProcessing (Warenkorb-Verarbeitungs-Klasse)
getAllArticleData (einmal aufrufen, liest alle Einträge mit einem SQL-Query aus)
getAllArticlePrices (gibt nur die Price-Information als Array zurück [dazu ist dann auch keine SQL-Abfrage nötig, da vorher getAllArticleData aufgerufen wurde])
getAllArticle...
oder
getArticles (erstellt für jeden Artikel eine neue Instanz und gibt die Instanzen als Array zurück, wobei die Artikeldaten bereits und zwar nur _einmal_ mit getAllArticleData eingelesen wurden und die Daten an die Instanz mit Parametern übergeben werden => damit sind dann keine SQL-Abfragen in der Article-Instanz mehr nötig)
so, vielleicht lässt sich ich hiermit die vielen SQL-Abfragen im Warenkorb und verwante Klassen verhindern...
Viele Grüsse
Philipp