Tom: Sinnvoll oder nicht - Onlineshop reparieren

Beitrag lesen

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

--
 ☻_
/▌
/ \ Nur selber lernen macht schlau
http://bergpost.annerschbarrich.de