Der Fall, wo Module B und C die selbe Klasse von A überschreiben führt natürlich zu einem Konflikt, so dass die Module nicht mehr miteinander kompatibel sind. Eine Lösung dafür wäre diesen Konflikt im local Scope (angenommen B und C sind Fremdmodule und liegen im community Scope) aufzulösen, indem man sie vereint.

Module, die diese rewrite Möglichkeit verwenden, greifen aber schon ziemlich tief in Magento ein. Übliche Erweiterungen wie Paymentmodule, Module für spezielle Datenexports und -imports, etc. kommen auch ohne rewrites aus.

Wobei natürlich auch bei Vererbung und überschreiben einer Funktion sowas auch passieren kann, wenn sich die überschriebene Funktion ändert, oder?

Ich sehe außerdem die Schwierigkeit bei Modulen, wenn von Grundklasse A die Module B und C mittels Vererbung jeweils die gleiche Funktion überschreiben wollen. B weiß ja nichts von C und umgekehrt. Ich gehe dabei von fertigen Modulen aus, die ja für den Shopbetreiber die Sache vereinfachen sollen. Hier wäre für mich aktuell wiederrum nur eine Lösung, das ein Programmierer ein Modul erstellt, das die Funktionen von B und C in einem vereint und dann A erweitert, oder gibt es da gute Ansätze (Stichwort reicht)?

Um Ihre Frage zu beantworten: die Änderungen durch ein Update von Varien würden nicht berücksichtigt werden, Sie müssten sie mit Ihrer modifizierten Klasse mergen. Deshalb rate ich von dieser „Praxis“ ab.

Zwang ist hier das richtige Stichwort.

OOP Vererbung ist für Fälle wie oben beschrieben die richtige Wahl und geht mit Magento. Wir sind damit bisher bei allen Projekten ausgekommen und mussten nie Klassen duplizieren, weder für die Hotelbuchungsseite, noch für die mandantenfähige Supplierplattform für mydeco.

Zu dieser Vorgehensweise wird man in Magento aber nicht gezwungen. Entwickler haben prinzipiell alle Freiheiten, so weit wie sie wollen in alle Bestandteile des Systems einzugreifen. Sogar ins Zend Framework, was Varien selbst auch getan hat, um die Apc, File und Memcached Backends von Zend_Cache zu customizen. Es existieren somit keine Grenzen für Anpassungen und Erweiterungen.

Diese Freiheit hat natürlich seinen Preis. Durch fehlende Grenzen in der Architektur kann die Softwarequalität stark in Mitleidenschaft gezogen werden. Das Aufrechterhalten der Qualität erfordert hier mehr Aufwand als bei „ausbruchssicheren“ Frameworks. Das Zend Framework zählt mit seinem Use-At-Will Konzept sicherlich nicht dazu (was einer der Gründe ist, warum Varien sich für dieses Framework entschieden hat).

Für mich persönlich ist es wichtig, nicht in einem Framework oder einer bestimmten Architektur eingesperrt zu sein. Ich will zum Tag X die Option zum Ausbrechen einfach haben. Über die Konsequenzen muss man sich als Verantwortlicher aber im Klaren sein und Kosten und Nutzen abwägen können.

Viele Grüße,

Dimitri

vielen Dank für deinen konstruktiven Beitrag. Die out-of-the-box Funktionalität zu vergleichen, hätte die Präsentation gesprengt. Diese ist als Whitepaper verfügbar und steht den Teilnehmern der E-Commerce Conference zum Download zur Verfügung.

Hierbei sehe ich einen leichten Vorsprung bei OXID, jedoch hat auch Magento ohne Zweifel eine Menge out-of-the-box Funktionalität zu bieten.

Was Code-Qualität betrifft: vergleicht man mal den Kommentar auf der Präsentation zu Slideshare

„Der letzte Verweis auf das Magento Forum auf Slide 18 ist Unsinn! Core Dateien müssen in Magento NIE direkt überschrieben, sondern dupliziert und im local-Scope angepasst werden, so dass die Anpassungen bei Updates erhalten bleiben.“

… so muss ich doch sagen, dass dieser Weg wirklich „it’s so nineties“ ist :-) OOP Vererbung wäre hier das richtige Mittel der Wahl (kann man sicherlich auch bei Magento, die Frage ist aber ob man hier gezwungen wird oder nicht). OXID zwingt den Entwickler eher dazu, über Vererbung zu arbeiten, was am 2 Jahre dauernden Refactoring liegt, das die Jungs mit V4 hinter sich haben und damit eine deutlich bessere Code-Qualität bieten als Magento und xt:commerce.

Alleine daran, wieviel Aufwand OXID in die Bereiche QA, automated testing, test reports, code coverage, ticket stats etc. steckt, sieht man den technologischen Vorsprung bei OXID schon sehr stark. Magento kann man das nicht so recht anlasten, schließlich sind sie erst seit einem Jahr (war ja auch deine Zustimmung) so richtig auf dem Markt.

Gleichwohl denke ich, dass Magento einen guten Vorsprung im Bereich der Community hat. Hier hat OXID noch Nachholbedarf und ich finde es etwas schade, dass xt:commerce in diesem Punkt so abstürzt. Ob das ausreicht, muss jeder für sich selbst entscheiden.

Viele Grüße, Björn.