Sinnvoll oder nicht - Onlineshop reparieren
basti_p
Sinnvoll oder nicht - Onlineshop reparieren
basti_p
Hallo,
ich brauche mal eure Meinung: ich habe eine Anfrage zur Optimierung eines Onlineshops (soviel ich gesehen habe eine Eigenentwicklung). Das Backend ist quälend langsam, der Aufruf der Seite mit den 50 letzten Bestellungen dauert ca. 8 Sekunden.
Nach ein paar Testausgaben während des Ladens dieser Seite (50 letzte Bestellungen) stellte ich fest, dass ca. 30000 !!! SQL-Anfragen abgesetzt werden (immer die gleichen, User, Adresse, Land, Status, pro Datensatz ca. 500-600mal).
Das Ganze ist objektorientiert aufgebaut, in vielen Klassen gibt es Methoden, welche die Datenbank ansprechen und die o.g. Statements absetzen.
Hat es Sinn, sich der Sache anzunehmen oder sollte ich dem Auftraggeber meine Erkenntnisse mitteilen und ihn an den Ersteller des Shops verweisen (ich tendiere zu Letzterem)?
Danke und Grüße Basti
-
Hi,
Hat es Sinn, sich der Sache anzunehmen oder sollte ich dem Auftraggeber meine Erkenntnisse mitteilen und ihn an den Ersteller des Shops verweisen (ich tendiere zu Letzterem)?
Vielleicht lieber evaluieren, in wie fern sich die Daten mit vertretbarem Aufwand extrahieren und anschließend durch dich in ein bewährtes Shop-System einpflegen lassen?
MfG ChrisB
--
RGB is totally confusing - I mean, at least #C0FFEE should be brown, right? -
Moin!
Reparieren bringt da wenig, weil ein Neuschrieb hier oftmals billiger ist.
Das Ganze ist objektorientiert aufgebaut,
Ein schönes Beispiel dafür, dass OOP auch immer die Methode getVerstand() braucht.
MFFG (Mit freundlich- friedfertigem Grinsen)
fastix
-
Hello,
Das Ganze ist objektorientiert aufgebaut, in vielen Klassen gibt es Methoden, welche die Datenbank ansprechen und die o.g. Statements absetzen.
Aha, Objektorientierung um der Objektorierung Willen? *grins*
Kein Stammbaum (Klassenhierarchie) vorhanden?
Dokumentation Glückssache?Hast Du schon einen Beratungsauftrag abgeschlossen?
Hat es Sinn, sich der Sache anzunehmen oder sollte ich dem Auftraggeber meine Erkenntnisse mitteilen und ihn an den Ersteller des Shops verweisen (ich tendiere zu Letzterem)?
Das kommt immer auf die Ernsthaftigkeit an, mit der der Shop zum Broterwerb beiträgt und wieviel es dem Auftraggeber daher wert sein kann/muss.
Für umsonst ist das vielleicht ein nettes Studienobjekt.
Und nun die wesentliche Frage: Darfst Du die Software überhaupt verändern? Wer hat die Rechte daran? Wenn Du das für kleines Geld tun sollst, solltest Du dir auf jeden Fall eigene Nutzungs-. vervielfältigungs- und Verbreitungsrechte an der neuen Version sichern/vorbehalten.
Liebe Grüße aus dem schönen Oberharz
Tom vom Berg
-
Hallo Tom,
Das Ganze ist objektorientiert aufgebaut [..]
Aha, Objektorientierung um der Objektorierung Willen? *grins*Im Falle eines Shopsystems darf es keinen Willen _gegen_ Objektorientierung geben - denn der waere toericht.
Gruesze
Christopher-
Hello,
Hallo Tom,
Das Ganze ist objektorientiert aufgebaut [..]
Aha, Objektorientierung um der Objektorierung Willen? *grins*
Im Falle eines Shopsystems darf es keinen Willen _gegen_ Objektorientierung geben - denn der waere toericht.Es hat einen Hintergrund, dass ich auf OOP allergisch reagiere. Oft bilden die Klassen nur Wrapper für vorhandene Funktionen und dann kann ich ise mir schenken. Ohne vernünftige Vorplanung einer Klassenhierarchie lohnt sich OOP nicht wirklich.
PHP ist eine leistungsfähige Scriptsprache. Scriptsprachen haben von vornherin schon andere Möglichkeiten, als es Compilersprachen haben. Sie verfügen i.d.R. über ein stabiles Runtimesystem, dass auf Fehler in Scripten intgelligent reagieren kann.
Daher vertrete ich immer noch die Auffassung, dass Objektorientierung in einem nicht kompilierenden Script-Engine-System redundant und damit an vielen Stellen sogar kontraprpduktiv ist.
Ein vernünftiges Namensraumkonzept, wie dies z.B. das Unit-Konzept von Turbo-Pascal war, würde vollkommen ausreichen. Wenn es möglich wäre, PHP-Funktionen durch eigene zu überdecken, auf die originalen aber dennoch mit einem qualifizierten Bezeichner zuzugreifen, dann wäre es noch besser.
In PHP ist OOP nur deshalb sinnvoll, weil dadurch bessere Namensraumabgrenzung/Mdulabgrenzung möglich ist. Notwendig ist sie, auch bei einem Shopsystem, aber nicht.
Liebe Grüße aus dem schönen Oberharz
Tom vom Berg
-
Hi!
Das Ganze ist objektorientiert aufgebaut [..]
Aha, Objektorientierung um der Objektorierung Willen? *grins*Du kennst nicht eine einzige Zeile des Codes, vermutest aber gleich das Schlimmste.
Es hat einen Hintergrund, dass ich auf OOP allergisch reagiere. Oft bilden die Klassen nur Wrapper für vorhandene Funktionen und dann kann ich ise mir schenken. Ohne vernünftige Vorplanung einer Klassenhierarchie lohnt sich OOP nicht wirklich.
Vielleicht habe ich auch ein falsches Vorurteil über dich, aber ich denke aufgrund deiner früheren Aussagen zum Thema, dass du deine Kenntnisse in Objektorientierung nicht auf unvoreingenommene Weise angeeignet hast. Somit messe ich deiner Meinung dazu keinen allzugroßen Stellenwert zu.
PHP ist eine leistungsfähige Scriptsprache. Scriptsprachen haben von vornherin schon andere Möglichkeiten, als es Compilersprachen haben. Sie verfügen i.d.R. über ein stabiles Runtimesystem, dass auf Fehler in Scripten intgelligent reagieren kann.
Daher vertrete ich immer noch die Auffassung, dass Objektorientierung in einem nicht kompilierenden Script-Engine-System redundant und damit an vielen Stellen sogar kontraprpduktiv ist.Erklärst du mir bitte deinen Gedankengang hinter diesen Aussagen? Mir erschließt sich nicht, was du eigentlich aussagen möchtest. Oder warum genau soll OOP einem intelligenten Reagieren auf Fehler im Weg stehen?
Ein vernünftiges Namensraumkonzept, wie dies z.B. das Unit-Konzept von Turbo-Pascal war, würde vollkommen ausreichen. Wenn es möglich wäre, PHP-Funktionen durch eigene zu überdecken, auf die originalen aber dennoch mit einem qualifizierten Bezeichner zuzugreifen, dann wäre es noch besser.
Geht seit 5.3 mit Namespaces.
In PHP ist OOP nur deshalb sinnvoll, weil dadurch bessere Namensraumabgrenzung/Mdulabgrenzung möglich ist. Notwendig ist sie, auch bei einem Shopsystem, aber nicht.
Nichts ist wirklich notwendig. Das ist aber kein Grund, pauschal etwas abzulehnen. Wenn du aufgrund von Vorurteilen immer nur das Negative in einem System suchst, wirst du es immer finden. Doch dabei übersieht man leicht den Rest.
Lo!
-
Hello,
Vielleicht habe ich auch ein falsches Vorurteil über dich, aber ich denke aufgrund deiner früheren Aussagen zum Thema, dass du deine Kenntnisse in Objektorientierung nicht auf unvoreingenommene Weise angeeignet hast. Somit messe ich deiner Meinung dazu keinen allzugroßen Stellenwert zu.
Ja nee, is schon klar...
Lass man stecken. Ich halte den Kopf gerne hin :-)Ich habe im allgemeinen nichts gegen OOP, aber bitte dort wo sie hinpasst.
PHP ist eine Script-Interpreter-Sprache, speziell für den Einsatz im Webserver. Es ist daher wohl nachzuvollziehen, wenn jeglicher unnötige Ballast unterbleibt. Konstrukte, wie "autoload" helfen zwar ein wenig darüber hinweg, aber dennoch sind die meisten Seiten, die OOP in PHP verwenden, mit Megabyteklötzen von Programmen (Scripten) vollkommen überfrachtet. Ich habe jedenfalls bei jeder Seite, die ich auf den Tisch bekommen habe wegen "bleibt gleich stehen", unnötige und unsinnige Klassen vorgefunden, bei denen noch nicht einmal mehr sicher war, welche von welcher abhängiog sein sollte.Wenn die Klassen bei PHP kompiliert werden würden und so dem Runtimesystem zugeschlagen werden würden, würde ich mein Gemecker dagegen (was bei PHP auch nur als exemplarisch zu gelten hat) auch gerne einstellen.
OOP in nichtkompilierenden Scriptsprachen findet aber (meistens) in der falschen Generation (Schicht) statt.
Liebe Grüße aus dem schönen Oberharz
Tom vom Berg
-
Hi!
PHP ist eine Script-Interpreter-Sprache, speziell für den Einsatz im Webserver. Es ist daher wohl nachzuvollziehen, wenn jeglicher unnötige Ballast unterbleibt.
Ja.
Konstrukte, wie "autoload" helfen zwar ein wenig darüber hinweg, aber dennoch sind die meisten Seiten, die OOP in PHP verwenden, mit Megabyteklötzen von Programmen (Scripten) vollkommen überfrachtet.
Das ist ja aber nicht der Fehler der OOP, sondern dass der Programmierer zu viel Code für die Erledigung der Aufgabe verwendet. Das passiert vielleicht, weil er von anderen Systemen bestimmte Muster gewöhnt ist, und die auch auf PHP stülpen will. Das mag ein gravierender Fehler des Programmierers sein, die OOP in der PHPschen Ausprägung ist daran unschuldig.
Wenn die Klassen bei PHP kompiliert werden würden und so dem Runtimesystem zugeschlagen werden würden, würde ich mein Gemecker dagegen (was bei PHP auch nur als exemplarisch zu gelten hat) auch gerne einstellen.
Es gibt Cache-Systeme. Viel Code, der sich nachteilig auf die Laufzeit auswirkt, kann ich auch herkömmlich schreiben.
OOP in nichtkompilierenden Scriptsprachen findet aber (meistens) in der falschen Generation (Schicht) statt.
Du bist ja schon grad eben nicht darauf eingegangen, mir eine Rückfrage zu beantworten, also schenke ich mir diesmal den Wunsch nach einer Erläutung dieses Gedankens.
Lo!
-
-
-
Hallo Tom,
Es hat einen Hintergrund, dass ich auf OOP allergisch reagiere. Oft bilden die Klassen nur Wrapper für vorhandene Funktionen
Dass du irgendwann mal auf unqualitativen Code gestoszen bist soll ein Hintergrund darstellen?
Ohne vernünftige Vorplanung einer Klassenhierarchie lohnt sich OOP nicht wirklich.
Ohne (technische) Spezifikationen "lohnt" sich Entwickeln allgemein nicht. Das hat nichts mit OOP zu tun.
PHP ist eine leistungsfähige Scriptsprache. Scriptsprachen haben von vornherin schon andere Möglichkeiten, als es Compilersprachen haben.
Interessant. Dann nenne mir mal drei "Moeglichkeiten", welche entgegen OO wirken.
Sie verfügen i.d.R. über ein stabiles Runtimesystem, dass auf Fehler in Scripten intgelligent reagieren kann.
Noch interessanter. Erklaere mir mal bitte was an der JRE - im Vergleich zu PHP's Runtime - nicht stabil sein soll.
Desweiteren von welchen "intelligenten Reaktionen" zu redest, welche andere Runtimes nicht auch unterstuetzen.
Ein paar schoen Beispiele waeren angebracht!Daher vertrete ich immer noch die Auffassung, dass Objektorientierung in einem nicht kompilierenden Script-Engine-System redundant und damit an vielen Stellen sogar kontraprpduktiv ist.
Oha. deine Auffassung basiert auf den von dir weiter oben aufgefuehrten "Argumenten" ?
- Wo genau liegt deiner Meinung nach dieses mystische Redundanz?
- Und wo existiert diese Kontraproduktivitaet?
[unendliches Bullshit-Bingo]
Deinem Charakter nach wirst du jetzt entweder
a) die Fragen wie ueblich nicht beantworten und deine Aussagen einfach ohne Bezug zur jeglicher Logik stehen lassen weil du eingesehen hast, dass du dich mal wieder verrannt hast, es aber nicht zugeben moechtest.
b) Oder deine "Argumentationen" wieder verschieben um letztendlich bei Extremprogrammierung oder noch kruseren Sachen zu landen.
c) Oder gar beides zusammen.
MfG
Christopher-
Hello,
Es hat einen Hintergrund, dass ich auf OOP allergisch reagiere. Oft bilden die Klassen nur Wrapper für vorhandene Funktionen
Dass du irgendwann mal auf unqualitativen Code gestoszen bist soll ein Hintergrund darstellen?Darum geht es doch, dass ich immer wieder "OOP" auf den Tisch bekommen habe, wo ich gedacht habe: wenn sie es gelassen hätten, wäe es besser. Schade, ich konnte nichts dazulernen, sondern hatte nur Arbeit mit der kaputten Seite (Und meistens leider schlecht bezahlt).
Die Anwendung von OOP erfordert ein großes Maß an Hintergrundwissen, einerseits über die Techniken von OOP (die kenne ich immer noch nicht alle auswendig) und andererseits über das System, in dem man sie anwenden will. Und da sind nichtkompilierende Scriptsprachen eben nicht gerade der dankbarste Baugrund. Sie haben schon ein großes Maß en eigenen "Klassen und Methoden" eingebaut, die man beachten und benutzen muss, auch wenn diese nicht immer gleich als solche erkennbar sind. Alleine die Fehlererkennung und -verfolgung eines Scriptinterpreters ist schon mächtig genug.
Ohne vernünftige Vorplanung einer Klassenhierarchie lohnt sich OOP nicht wirklich.
Ohne (technische) Spezifikationen "lohnt" sich Entwickeln allgemein nicht. Das hat nichts mit OOP zu tun. Doch, das hat bei PHP mit OOP zu tun. Man kann sich ein System aus Scripten nach und nach aufbauen, diese austauschen, ergänzen und verbessern. Da muss man mit PHP nicht viel planen."Es funzt doch". Das können wir doch fast jeden Tag hier im Forum verfolgen. Außerdem erinnere ich mich da auch noch gut an meine eigenen Anfänge. Und ich konnte bereits programmieren. Über 10 Jahre Assembler, Pascal, C und einfache Datenbanken (z.B. BTrieve) hatte ich schon auf der Uhr, als mir PHP über den Weg lief. Aber der Einstieg in die "Internetprogrammierung", also HTTP und das Client-Server-Schema haben doch noch ein paar Extrastunden benötigt, obwohl ja Btrieve auch eine Client-Server-Lösung war...Spätestens mit PHP-OOP geht das "Hineinfinden" nicht mehr so einfach. Man muss vorher _genau_ wissen, was man will und wie man es erreicht, sonst kommen eben solche Probleme dabei heraus, wie sie der OP beschreibt. Da sollte man dann OOP lieber weglassen. Ein Shop kann mit PHP und MySQL ohne OOP extrem schlank ausfallen und trotzdem sehr gut funktionieren. Wenn ich einen wiederverwendbaren Shop in C schreiben müsste, würde ich auch lieber C++ benutzen, oder heutzutage vielleicht sogar C# und .NET oder Mono. Aber da müsste ich auch erst wieder viel üben...
Alleine für die Darstellung am Userfrontend gibt es da schon viele fertige Sachen. Die sind aber für eine Browser-Lösung gar nicht relevant.PHP ist eine leistungsfähige Scriptsprache. Scriptsprachen haben von vornherin schon andere Möglichkeiten, als es Compilersprachen haben.
Interessant. Dann nenne mir mal drei "Moeglichkeiten", welche entgegen OO wirken.Ich spreche nicht von "entgegenwirken", sondern von "kann das System auch ohne OOP". Da ist in erster Linie die Fehlererkennung und -behandlung. Bei PHP kommen die mächtigen "Arrays" dazu und ihre durchaus brauchbare Anzahl von mächtigen Funktionen.
Sie verfügen i.d.R. über ein stabiles Runtimesystem, dass auf Fehler in Scripten intgelligent reagieren kann.
Noch interessanter. Erklaere mir mal bitte was an der JRE - im Vergleich zu PHP's Runtime - nicht stabil sein soll.Wieso soll _ich_ das erklären? Du hast doch "JRE" ins Gespräch gebracht. Also müsstest Du erstmal erklären, warum. Ich sprach von PHP.
Desweiteren von welchen "intelligenten Reaktionen" zu redest, welche andere Runtimes nicht auch unterstuetzen.
Hab ich auch nicht gesagt. Ein Script-Interpreter bietet andere Möglichkeiten, als es eine Compilersprache tut. Das war meine Aussage.
Meiner Meinung nach kann man auf die Basis einer 3rd Generation-Language entweder intelligente Scriptsprachen oder aber aber OOP-Systeme aufsetzen, nicht aber beides. Das sind zwei getrennte Wege, die sich nur schwer sauber vereinen lassen.
Generell halte ich OOP für einen legitimen Lösungsweg, ohne den viele der heutigen Programme nicht existieren würden. Aber viele kämen vermutlich auch mit sehr viel weniger Speicher aus, wären viermal so schnell, usw.
Liebe Grüße aus dem schönen Oberharz
Tom vom Berg
-
Hi!
Es hat einen Hintergrund, dass ich auf OOP allergisch reagiere. Oft bilden die Klassen nur Wrapper für vorhandene Funktionen
Dass du irgendwann mal auf unqualitativen Code gestoszen bist soll ein Hintergrund darstellen?
Darum geht es doch, dass ich immer wieder "OOP" auf den Tisch bekommen habe, wo ich gedacht habe: wenn sie es gelassen hätten, wäe es besser.Nur weil du immer wieder auf kaputtes Zeug stößt, heißt das noch lange nicht, dass das ganze System kaputt ist. Hier im Forum bekommen wir auch immer wieder Dinge vorgesetzt, die Mist sind. Wer ist Schuld? Der Autor, nicht PHP/HTML/wasauchimmer. Und jetzt kommt mir nicht mit PHP macht es leicht, Mist zu produzieren. Ja, und? Welche Sprache ist denn ungeeignet, Mist zu produzieren?
Schade, ich konnte nichts dazulernen, sondern hatte nur Arbeit mit der kaputten Seite [...]
Schade, auch aus kaputten Systemen kann man mehr entnehmen als nur ein negatives Vorurteil aufs Gesamte.
Die Anwendung von OOP erfordert ein großes Maß an Hintergrundwissen, einerseits über die Techniken von OOP (die kenne ich immer noch nicht alle auswendig) und andererseits über das System, in dem man sie anwenden will. Und da sind nichtkompilierende Scriptsprachen eben nicht gerade der dankbarste Baugrund. Sie haben schon ein großes Maß en eigenen "Klassen und Methoden" eingebaut, die man beachten und benutzen muss, auch wenn diese nicht immer gleich als solche erkennbar sind. Alleine die Fehlererkennung und -verfolgung eines Scriptinterpreters ist schon mächtig genug.
Das hast du schonmal so ähnlich gesagt, aber nicht begründet. Weder warum OOP für Scripts ungeeignet sein soll, noch was der Unterschied in den Fehlerbehandlungen sein soll.
Ohne vernünftige Vorplanung einer Klassenhierarchie lohnt sich OOP nicht wirklich.
Ohne (technische) Spezifikationen "lohnt" sich Entwickeln allgemein nicht. Das hat nichts mit OOP zu tun.
Doch, das hat bei PHP mit OOP zu tun. Man kann sich ein System aus Scripten nach und nach aufbauen, diese austauschen, ergänzen und verbessern. Da muss man mit PHP nicht viel planen."Es funzt doch". Das können wir doch fast jeden Tag hier im Forum verfolgen.Da kannst du jedes System nehmen. Das "funzt doch"-Prinzip ist nicht PHP-spezifisch.
Außerdem erinnere ich mich da auch noch gut an meine eigenen Anfänge. Und ich konnte bereits programmieren. Über 10 Jahre Assembler, Pascal, C und einfache Datenbanken (z.B. BTrieve) hatte ich schon auf der Uhr, als mir PHP über den Weg lief. Aber der Einstieg in die "Internetprogrammierung", also HTTP und das Client-Server-Schema haben doch noch ein paar Extrastunden benötigt, obwohl ja Btrieve auch eine Client-Server-Lösung war...
Spätestens mit PHP-OOP geht das "Hineinfinden" nicht mehr so einfach. Man muss vorher _genau_ wissen, was man will und wie man es erreicht, sonst kommen eben solche Probleme dabei heraus, wie sie der OP beschreibt.Auch das ist wieder nichts, was man PHP allein anlasten kann. Das sind Merkmale vieler Anfänger, nicht der Systeme.
Da sollte man dann OOP lieber weglassen. Ein Shop kann mit PHP und MySQL ohne OOP extrem schlank ausfallen und trotzdem sehr gut funktionieren.
Und wo ist der Punkt, dass das mit OOP generell nicht gehen soll? Der Sinn der Verwendung einer bestimmten Strategie ist nicht nur, dass das Ergebnis schlank wird, sondern dass auch die Wartung einfach ist. Schon der Einsatz einer herkömmlichen Funktion baut Umwege in einen Programmablauf ein, macht ihn weniger einfach als Geradeaus-Code. Wenn man sie falsch einsetzt, ist sie bestenfalls nur ein Umweg. Richtig angewendet hilft sie Weiterentwicklungszeit zu sparen, weil nur noch eine Stelle statt vieler Copy'n'Paste-Stellen zu ändern ist.
Wenn ich einen wiederverwendbaren Shop in C schreiben müsste, würde ich auch lieber C++ benutzen, oder heutzutage vielleicht sogar C# und .NET oder Mono. Aber da müsste ich auch erst wieder viel üben...
Alleine für die Darstellung am Userfrontend gibt es da schon viele fertige Sachen. Die sind aber für eine Browser-Lösung gar nicht relevant.Wenn du genug geübt hast, wirst du hoffentlich feststellen, dass es ASP.NET gibt, das unter anderem ein Userfrontend für Browser-Lösungen ist. Allerdings verwende ich diesen komponentenbasierenden Ansatz ungern, weil er gelinde gesagt nicht besonders erbaulichen HTML-Code erzeugt. Da ist mir der ASP.NET-MVC-Ansatz lieber. Bei dem bin ich vielleicht nicht so schnell, wie beim Drag&Drop von Komponenten, hab dafür aber die volle Kontrolle über das entstehende HTML, was mir beim Verwenden von CSS wieder deutlich mehr entgegenkommt.
PHP ist eine leistungsfähige Scriptsprache. Scriptsprachen haben von vornherin schon andere Möglichkeiten, als es Compilersprachen haben.
Interessant. Dann nenne mir mal drei "Moeglichkeiten", welche entgegen OO wirken.
Ich spreche nicht von "entgegenwirken", sondern von "kann das System auch ohne OOP".Niemand bestreitet, dass man ohne OOP auskommen kann. Aber ist das ein ernsthafter Grund, dass man stets ohne auskommen sollte oder es abzulehnen?
Da ist in erster Linie die Fehlererkennung und -behandlung.
Werd doch mal bitte konkret, was du an der Fehlererkennung und -behandlung auszusetzen hast, beziehungsweise was die großen Vorteile der Scriptsprachen gegenüber der kompilierenden Sprachen sein sollen. Kleine Erinnerung: Python ist auch eine Scriptsprache. Deren Fehlermeldungskonzept baut auf die bei OOP zu findenden Exceptions auf. (Falls es Exceptions sind, auf die du anspielen willst.) Und wie bei PHP ist die OOP unter Python optional (allerdings besser in das Gesamtkonzept eingebunden).
Bei PHP kommen die mächtigen "Arrays" dazu und ihre durchaus brauchbare Anzahl von mächtigen Funktionen.
Und? Konstrukte, die ähnliche Aufgaben erfüllen, gibt es anderswo auch. Wer allerdings versucht, sich Collections etc. mit PHP nachzubauen, und an PHPs Array-Konzept vorbeiprogrammiert, ist selbst schuld. Der Programmierer! Nicht PHP, $anderesSystem oder die OOP im Allgemeinen.
Sie verfügen i.d.R. über ein stabiles Runtimesystem, dass auf Fehler in Scripten intgelligent reagieren kann.
Noch interessanter. Erklaere mir mal bitte was an der JRE - im Vergleich zu PHP's Runtime - nicht stabil sein soll.
Wieso soll _ich_ das erklären? Du hast doch "JRE" ins Gespräch gebracht. Also müsstest Du erstmal erklären, warum. Ich sprach von PHP.Du hast es verglichen, aber mit nichts konkret anderem. Insofern war deine Aussage unverwendbar, wenn du nicht erläuterst, worauf du damit hinauswolltest. Dass dann jemand aufgrund deiner unkonkreten Aussage, sich irgendwas dazu reimt, ist nicht allein seine Schuld.
Meiner Meinung nach kann man auf die Basis einer 3rd Generation-Language entweder intelligente Scriptsprachen oder aber aber OOP-Systeme aufsetzen, nicht aber beides. Das sind zwei getrennte Wege, die sich nur schwer sauber vereinen lassen.
Ich denke, es kommt auf den Anwender an, dass er zwischen beiden Paradigmen unterscheiden kann. Und ich sehe nicht, was es generell für Nachteile bringen soll, beides zu mischen, wenn dabei die Übersichtlichkeit gewahrt bleibt. (Fundamental-Evangelisten mögen das anders sehen - ihr Problem.)
Wenn man sich für ein Projekt zur OOP entschlossen hat, muss man nicht zwangsläufig eine Klasse schreiben, wenn eine alleinstehende Funktion eine ganz spezifische Aufgabe auch so erledigen kann. Vorausgesetzt, das System bietet sowas an. Unter PHP braucht man sowieso auch noch den herkömmlichen Aufruf von Funktionen, kann also gar nicht reines OOP programmieren. Unter C# beispielsweise geht es nicht ohne eine Klasse.
Generell halte ich OOP für einen legitimen Lösungsweg, ohne den viele der heutigen Programme nicht existieren würden. Aber viele kämen vermutlich auch mit sehr viel weniger Speicher aus, wären viermal so schnell, usw.
Ja. Das beste Ergebnis erziehlt man meiner Meinung nach, wenn man projektbezogen eine vernünftige Entscheidung trifft und nicht nur das Bauchgefühl oder nur schlechte Erfahrungen zurate zieht.
Lo!
-
Thumbs up! :-)
Nur leider war dein Vortrag war viel substantiiert, als das von Tom hierzu noch eine fundierte Antwort zu erwarten wäre - im Gegenteil freuen wir uns wohl auf ein gediegenes:
-
-
-
-
Hi there,
Im Falle eines Shopsystems darf es keinen Willen _gegen_ Objektorientierung geben - denn der waere toericht.
Ich denke, Objektorientierung bei PHP ist töricht (nachdem Du ja das Thema PHP gewählt hast). Auch wenn ich da nicht von allen Zustimmung ernte, weiß ich mich mit dieser Ansicht trotzdem in guter Gesellschaft.
Wäre noch interessant zu erfahren, warum die Objektorientierung aus Deiner Sicht gerade bei einem Shop so wichtig und richtig wäre - daß sie kein Garant für effizienten Code und gutes Gelingen ist, hast Du uns ja selbst geschildert. Ich hoffe, der Grund Deiner Überzeugung ist kein so trivialer, daß Du glaubst, Artikeln nur über Objektorientierung bestimmte Eigenschaften zuweisen zu können.
In der Sache selbst würd' ich Deiner Stelle einfach einmal die Struktur der Datenbank betrachten; wenn die halbwegs in Ordnung ist (kann ich mir bei 3000 SQL-Abfragen für letzte 50 Geschäftsfälle zwar nicht vorstellen, aber bitte...) könntest Du ja einen Shop darum herumbauen. Ich würde aber ab einem Zeitaufwand, der zwei, drei Wochen übersteigt, in jedem Fall die Finger davon lassen. Sonst bist Du nachher nicht mehr der grosse Retter sondern der, der dafür verantwortlich ist, daß es wieder nicht richtig funktioniert...
-
Hallo Klawischnigg,
Ich denke, Objektorientierung bei PHP ist töricht (nachdem Du ja das Thema PHP gewählt hast). Auch wenn ich da nicht von allen Zustimmung ernte, weiß ich mich mit dieser Ansicht trotzdem in guter Gesellschaft.
Nein, das mit der Kategorie war keine Absicht. Ich habe sie einfach vom OP uebernommen. Was das angeht gehoere ich wohl auch eher zu der besagten Gesellschaft, denn PHP ist bei mir kein KO-Kriterium - ganz im Gegenteil. Oft ist sie sogar in Bezug auf Kosten/Aufwand/Nutzen die bessere Wahl.
Wäre noch interessant zu erfahren, warum die Objektorientierung aus Deiner Sicht gerade bei einem Shop so wichtig und richtig wäre
daß Du glaubst, Artikeln nur über Objektorientierung bestimmte Eigenschaften zuweisen zu können.Es geht doch nicht darum "ob etwas geht", sondern auf welche Weise man es am Besten umsetzt. Und ja, ein Shop schreit gerade zu nach OOP. Schau dir doch einfach mal den Aufbau eines Shops an. Die Abbildung des Datenmodelles hin zu Objekten ist einfach eine logische Schlussfolgerung. Ob wir ueber Artikel/Produkte (egal ob ein Waschlappen oder eine Glastisch - allen sind gewisse Attribute gemein) oder ueber den Warenkorb sprechen; der objektorientierte Weg liefert hierbei einfach seine Vorteile.
MfG
Christopher-
Hello,
[...] Und ja, ein Shop schreit gerade zu nach OOP. Schau dir doch einfach mal den Aufbau eines Shops an. Die Abbildung des Datenmodelles hin zu Objekten ist einfach eine logische Schlussfolgerung. Ob wir ueber Artikel/Produkte (egal ob ein Waschlappen oder eine Glastisch - allen sind gewisse Attribute gemein) oder ueber den Warenkorb sprechen; der objektorientierte Weg liefert hierbei einfach seine Vorteile.
Meinst Du jetzt eine vollständig objektorientierte Datenhaltung?
Dafür benötgst Du aber ein passendes DBMS.Oder meinst Du, dass die Geschäftsregeln und der Steuerfluss (inclusive Zugriffsschutz) objektorientiert abgebildet werden sollen? Ich erinnere mal daran, dass wir uns im Client-Server-Umfeld befinden und nicht im Desktopprogramming.
Die "Internettechnologie", so wie wir sie üblicherweise nutzen, hat in Verbindung mit nichtkompilierenden Compilersprachen schon eine implizite Objektorientierung. Jedes Script ist nämlich (innerhalb des Runtime-Systems) ein eigenständiges Objekt. Scripte kennen Polymorphie... Man muss die Möglichkeiten nur benutzen.
Wenn man da jetzt noch eine weitere Objektorientierung aufpfropft, muss man genau aufpassen, welche Schicht (welche "Klasse") für was verantwortlich ist.
Liebe Grüße aus dem schönen Oberharz
Tom vom Berg
-
Hello,
Hello,
[...] Und ja, ein Shop schreit gerade zu nach OOP. Schau dir doch einfach mal den Aufbau eines Shops an. Die Abbildung des Datenmodelles hin zu Objekten ist einfach eine logische Schlussfolgerung. Ob wir ueber Artikel/Produkte (egal ob ein Waschlappen oder eine Glastisch - allen sind gewisse Attribute gemein) oder ueber den Warenkorb sprechen; der objektorientierte Weg liefert hierbei einfach seine Vorteile.
Meinst Du jetzt eine vollständig objektorientierte Datenhaltung?
Dafür benötgst Du aber ein passendes DBMS.Oder meinst Du, dass die Geschäftsregeln und der Steuerfluss (inclusive Zugriffsschutz) objektorientiert abgebildet werden sollen? Ich erinnere mal daran, dass wir uns im Client-Server-Umfeld befinden und nicht im Desktopprogramming.
Die "Internettechnologie", so wie wir sie üblicherweise nutzen, hat in Verbindung mit nichtkompilierenden Compilersprachen schon eine implizite Objektorientierung. Jedes Script ist nämlich (innerhalb des Runtime-Systems) ein eigenständiges Objekt. Scripte kennen Polymorphie... Man muss die Möglichkeiten nur benutzen.
Wenn man da jetzt noch eine weitere Objektorientierung aufpfropft, muss man genau aufpassen, welche Schicht (welche "Klasse") für was verantwortlich ist.
Liebe Grüße aus dem schönen Oberharz
Tom vom Berg
Liebe Grüße aus dem schönen Oberharz
Tom vom Berg
-
Hallo Tom,
Hut ab, Du hast dich also fuer Variante c entschieden:
Deine Thesen nicht begruenden und mehr als zuvor Bullshit-Bingo spielen.MfG
ChristopherAch, und bevor du jetzt behauptest, ich ginge nicht auf deine Fragen ein: Es ist _unmoeglich_ auf so ein konsensloses Geschwafel antzuworten, geschweige denn ueberhaupt darauf einzugehen. Wenn ich ehrlich bin habe ich sogar schon seit laengerem nicht mehr solch ein verbales Diarrhoe zu Gesicht bekommen.
-
Hello Christopher,
Hut ab, Du hast dich also fuer Variante c entschieden:
Deine Thesen nicht begruenden und mehr als zuvor Bullshit-Bingo spielen.Meine Thesen habe ich begründet, wenn auch nicht mit einem Buch. Vielleicht habe ich nicht die Dir antrainierten Begriffe dafür verwendet. Dann wäre es freundlich von Dir, wenn Du gezielter nachfragen würdest. Das wäre jedenfalls für mich ein Indiz dafür, dass Du wirklich diskutieren willst.
Meinungsaustausch einfach mit dem lautstarken Ausruf von "Bullshit-Bingo" und Verweis auf unqualifizierte ältere Äußerungen zu unterbinden, empfinde ich jedenfalls als unreif und als Angriff auf meine Person. Habe ich Dich etwa auch persönlich angegriffen, ohne es zu merken? Dann bitte ich um Entschuldigung.
Ich nehme übrigens den Angriff auf meine Person nicht übel, denn ich weiß ja, was ich meine und versuche, zu diskutieren. Aber ich finde es äußerst schade für die Diskussionskultur, wenn Menschen wie Du einfach mit vorformulierten Aussagen und Meinungen in arroganter Weise die Diskussion unmöglich machen.Meine Meinung kannst Du gerne angreifen. Die ist ja noch im Diskussionsstadium und daher gar nicht endgülig. Aber dann bitte so, dass ich und andere Mitlesende deine fachlichen Einwände auch nachvollziehen können, ohne sich "furchtbar blöd" fühlen zu müssen odr aber dem Gedanken Raum zu geben, dass Du ein Arschloch wärst. Letzteres habe ich bisher nbichzt in Betracht gezogen.
Zur Not müssen wir da wieder bei Adam & Eve anfangen. Am Anfang war das Bit. Und gutes Bemehmen fördert die Kultur.
Liebe Grüße aus dem schönen Oberharz
Tom vom Berg
-
Hello Christopher,
noch eine Bitte:
versuch doch einfach mal Deutsch zu reden, wo die anderssprachlichen Fachbegriffe noch nicht Allgemeingut gewoeden sind, bzw. solange Deutsch zu reden, bis es augenscheinlich kontraproduktiv wird. Und nicht in obskuren Semi-Fachbegriffen...
Ich könnte mir vorstellen, das wir (alle) uns dann besser verstehen.
Ich weiß, dass hier ganz viele Leute mitlesen, denen dieser Dünkel auch auf den Geist geht. Die trauen sich nur nicht, das offen auszusprechen, weil sie nur 'normale' Gäste des Forums sind und keine Stammposter oder sonstwie 'Berechtigte'.
Liebe Grüße aus dem schönen Oberharz
Tom vom Berg
-
Hallo Tom,
Meine Thesen habe ich begründet, wenn auch nicht mit einem Buch.
Nein, hast Du nicht. Genau darum geht es ja.
Dann wäre es freundlich von Dir, wenn Du gezielter nachfragen würdest. Das wäre jedenfalls für mich ein Indiz dafür, dass Du wirklich diskutieren willst.
Sag mal? Was an den Fragen in diesem Posting hast du nicht verstanden? Neben ganzen 3 (drei!) Fragen habe ich auch noch 2 (zwei!) Bitten gestellt, deine Thesen naeher zu erlaeutern. Genug Stoff fuer eine Diskussion.
und Verweis auf unqualifizierte _ältere_ Äußerungen
Die Qualitaet ist immernoch die selbe.
Aber ich finde es äußerst schade für die Diskussionskultur, wenn Menschen wie Du einfach mit vorformulierten Aussagen und Meinungen in arroganter Weise die Diskussion unmöglich machen.
Vorformulierte Aussagen? Wo und wie?
Diskussion unmoeglich machen? Wo und wie?
Was gibtst du eigentlich die ganze Zeit fuer einen Nonsens von dir?Beantworte doch einfach die Fragen auf dein urspruengliches Posting statt hier die beleidigte und unverstandene Leberwurst zu spielen und dich _mal wieder_ davor zu druecken deine Aussagen zu begruenden.
Ist doch echt immer die selbe bloede Leier: Absoluten Nonsens labern und KEINE EINZIGE THESE dafuer liefern.. und dann noch erwarten, dass andere auf _noch mehr Nonsens_ eingehen.
MfG
Christopher
-
-
-
-
-
Hello,
[...] Ich würde aber ab einem Zeitaufwand, der zwei, drei Wochen übersteigt, in jedem Fall die Finger davon lassen. Sonst bist Du nachher nicht mehr der grosse Retter sondern der, der dafür verantwortlich ist, daß es wieder nicht richtig funktioniert...
Sehe ich genauso, wenn nicht der Lerneffekt (also der Weg) das Ziel sein soll.
Liebe Grüße aus dem schönen Oberharz
Tom vom Berg
-
-
-
-
Hi,
ich weiss ja nicht, wie deine Auftragslage ist.... ich würde mir die Daten angucken, und darüber nachdenken, in welche geeignete Shop-Software ich diese importieren könnte (z.b. zenCart, XT-Commerce). Die Eigenentwicklung selber umbauen lohnt nur, wenn der Shop Features hat, die sonst kein Shop bietet bzw. auch nicht so einfach zu implementieren wären.
Brillo
-
Hallo,
Hat es Sinn, sich der Sache anzunehmen oder sollte ich dem Auftraggeber meine Erkenntnisse mitteilen und ihn an den Ersteller des Shops verweisen (ich tendiere zu Letzterem)?
Vorsicht, wenn das eine Eigenentwicklung ist, hat die möglicherweise Dein Cheffe selbst geschrieben!!11?
Pack das Ding an oder gib gleich auf. Ich tendiere zu Ersterem. Die Analyse erster Ordnung hast Du ja schon gemacht, der Shop ist sanierungsbedürftig. OOP ist ok, nicht nur der Sache Willen, hier gibt es immer was dazuzulernen. Schau Dir die Klassen an, die es schon gibt und stelle fest, welche Klassenhierarchien möglich sind. Ein Shop muss pflegeleicht sein, hierin liegt viel Dynamik, nicht der Warenkorb ist das Objekt, sondern der Artikel. Der Warenkorb ist eine Sammlung von Objekten, genauso wie wie das "Lager" eine Sammlung von Objekten ist. Schwupps haben wir schon eine der Eigenschaften eines Objekts, nämlich wo es sich befindet oder welchen Status es hat. Weitere Eigenschaften sind der Preis, eine Beschreibung, evntl. ein Foto oder mehrere Fotos... damit kannst Du die Artikel als Angebote präsentieren.
Die erste Klasse, die jetzt gebraucht wird, ist diejenige zur Erstellung eines Artikels als Objekt, hier sind die Methoden beschrieben, wie ein neues Objekt in das "Lager" eingefügt wird. Das "Lager" ist eine DB, hier sind die Eigenschaften abgebildet und gespeichert. Das RDBMS muss selbst nicht objektorientiert sein, das würde jedoch die weitere Hierarchie unterstützen.
Class Store; # Artikel ins Lager einpflegen
Class Store::Presentation; # Artikel veröffentlichen, Methoden zum Warenkorb
Store::Verkauf; # selbsterklärend.... nurmalso als VorschlägeEine sinnvolle Hierarchie verbessert die Übersicht, so müssen nicht alle Methoden in einer einzigen Klasse beschrieben sein.
Viel Erfolg,
Hotti-
Hi!
Schwupps haben wir schon eine der Eigenschaften eines Objekts, nämlich wo es sich befindet [...]
Wo sich ein Objekt befindet ist keine Eigenschaft desselben. Wenn ich den Inhalt eines Warenkorbs ermitteln will, weil der Kunde selbigen bezahlen soll, will ich nicht erst über all meine Waren iterieren, um zu sehen, ob sie sich in diesem Korb befinden oder nicht. Stattdessen will ich durch einen Blick in den Korb ermitteln, was alles in ihm liegt.
Außerdem geht es grad nicht darum, in die OOP einzuführen, sondern ob sich die Reparatur des Systems lohnt. Das kann man (zumindest ich) im Prinzip nicht als Außenstehender beurteilen. Selbst wenn ich das Ding vor mir hätte, wäre ich mir nicht so sicher, ob ich mich nicht verschätze, weil sich die wahre Katastrophe vielleicht erst nach und nach offenbart.
Lo!
-
-
Moin!
Hat es Sinn, sich der Sache anzunehmen oder sollte ich dem Auftraggeber meine Erkenntnisse mitteilen und ihn an den Ersteller des Shops verweisen (ich tendiere zu Letzterem)?
Tja, es KÖNNTE sein, dass du mit einer relativ simplen Caching-Methode, die bereits gelesene Querys direkt aus dem Speicher bedient, mit Glück angewandt auf die einzige zentrale DB-Zugriffs-Klasse, die es hoffentlich gibt, auf einen Schlag die mangelhafte OOP-Umsetzung in eine RAM-fressende, aber zunächst mal deutlich performantere Form bringst.
Wenn an dieser Stelle dein Auftrag durch Auszahlung des vereinbarten Salärs beendet ist, könntest du drüber nachdenken. Vereinbare aber unbedingt, dass man dich danach nicht mehr kontaktieren darf, bzw. du zumindest Folgeaufträge nicht annehmen musst. Denn so wie es aussieht, ist der Code schon übel verknotet, und das wird durch den Cache-Einbau natürlich nicht besser, sondern schlimmer. Denn im Prinzip ist das genau der falsche Ansatz an dieser Stelle.
So wie's aussieht, hat der Shop-Hersteller halt sämtliche Abfragen von Objekteigenschaften, die in der Datenbank gespeichert vorliegen, 1:1 als DB-Query realisiert. Du willst den Namen eines Artikels wissen? 'SELECT name FROM articles WHERE articleId = "Die ID vom Objekt"'. Du willst dann noch den Preis des Artikels wissen? 'SELECT price FROM articles WHERE articleId = "Die ID vom Objekt"'. Warum mit einem Query direkt ALLE Eigenschaften des Artikels abfragen und zwischenspeichern, wenn man doch gar nicht weiß, ob diese Eigenschaften immer alle gebraucht werden - da spart man richtig viel Speicherplatz, wenn man das alles On-Demand macht!
Und vor allem: Mit OOP kann man diese Tatsache, dass die grundlegenden Objekte, die Einträge der DB repräsentieren, bei jeder Eigenschaftsabfrage ein Query lostreten, wunderbar verstecken und wegabstrahieren. Und man wundert sich dann, warum eine Doppelschleife "
foreach ($warenkorb as $articles) { foreach ($articles as $eigenschaft)...}" plötzlich exponentiell viele Querys erzeugt...OOP ist eine gute Antwort auf viele Herausforderungen der Programmiererei - AUCH UND GERADE BEI PHP - aber es bedeutet nicht, dass man nur "irgendwie" OOP machen muss, und schon wird automatisch alles prima. Natürlich nicht. Man muss schon genau planen, wo man die teuren DB-Zugriffe platziert, und man muss solche Aufrufe auch sehr bewußt in anderen Codeteilen starten - und nicht wegabstrahiert in einem $article->getPrice() oder $article->getName() verstecken (noch schlimmer, wenn sowas in den magischen Methoden __get/__set oder __call versteckt sein sollte - aber da wäre wenigstens ein, wenn auch sehr gefährlich zu ändernder, zentraler Anlaufpunkt, um global besseres Verhalten beizubringen).
- Sven Rautenberg