Das System ist leider nichts im Vergleich zu ähnlichen Produkten wie z.B. Magento auf dem Markt. Quellcodes sind zu großen Teilen verschlüsselt, Adonns werden verschlüsselt ausgeliefert, sodass keine oder nur geringfügige unzureichende Modifikationen möglich sind.

Lizenzen lassen sich nicht übertragen, man darf keine nicht mehr benötigten Lizenzen weiterverkaufen und der Support lässt auch zu wünschen übrig.

Letztendlich muss es jeder selbst wissen, jedoch kann ich nur von der Benutzung abraten.

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