Sie befinden sich hier im Forenarchiv von phpforum.de wenn Sie direkt ins Forum möchten, klicken Sie bitte hier. Zur Startseite kommen Sie hier.

Objektorientiertes PHP

Hallo!
Ich programmiere schon recht lange in PHP und habe in Verbindung mit MySQL bereits ziemlich umfangreiche Projekte hinter mich gebracht. Allerdings habe ich bislang nur prozedural programmiert und erst kürzlich erfahren, dass PHP 5 OO unterstützt. Ich habe mich also in den letzten Tagen in diese Materie eingelesen und einige Einsteiger-Tutorials durchgearbeitet. Leider sind mir dabei die Vorteile von OO nicht wirklich klar geworden... alle Beispiele (z.B. eine Klasse zum Auslesen einer Datenbank) hätte ich mit gleich viel Aufwand in eine ganz normale Funktion schreiben können und wäre dabei meines Erachtens auch gleich flexibel in der Weiterverwendung der Funktion geblieben.

Ich wäre sehr dankbar, wenn mir jemand (verständlich) die Vorteile von OO vs. Funktionen sagen könnte und ob bzw. ab welcher Größenordnung (z.B. www.hornline.at) der Einsatz von OO in Verbindung mit PHP sinnig ist. Vielen Dank für Eure Unterstützung im Voraus.

Lg Thomas

Hier gehts zum Orginal Eintrag "Objektorientiertes PHP" im Forum

Antworten

Dahinter kommt man meist erst, wenn man OOP weitestgehend verstanden und angewandt hat.


2.

Dafür gibt es genügend Fachliteratur auf dem Markt, so dass ich nicht glaube, dass es sinnvoll ist, hier nochmal alles aufzuwärmen.

Nur so viel: Alles dreht sich um die Wartbarkeit des Codes.


3.

Vorerst vielen Dank für die sehr raschen Antworten!

Zitat:
oimel postete
Dafür gibt es genügend Fachliteratur auf dem Markt...
Nachdem ich weiß, dass die Qualität der Fachliteratur oft sehr unterschiedlich sein kann... Gäbe es von eurer Seite vielleicht eine od. mehrere Literaturvorschläge zu diesem Thema?
Vielen Dank, Thomas.


4.

Hm, ich hatte damals begleitend zur Vorlesung die "Einführung in die Informatik" Teil I bis IV von Prof. Manfred Broy, aber das ist für den Laien wahrscheinlich zu schwierig. Sonst wüsste ich gar nich...


5.

Google ist dein Freund. Ich schätze mal du findest in etwa 12.000.000 Seiten, die sich (unter anderem) mit Vor- und Nachteilen von OOP beschäftigen.

Gruß


6.

Zitat:
Leider sind mir dabei die Vorteile von OO nicht wirklich klar geworden...
Was sicherlich auch daran liegt, dass OO keine Vorteile hat. Es ist lediglich eine "andere" Art, die Dinge zu programmieren.

Die Zeiten, wo OO als das Maß der Dinge galt, sind lange vorbei. Zu viele teure Projekte sind in den Sand gesetzt worden. Meiner Meinung nach soll jeder so programmieren, wie er es am besten kann. Objektorientierung kann Spass machen - aber zu glauben, man könne damit "mehr" oder irgendwie "besser" programmieren, ist schlicht nicht richtig.

Zudem ist PHP ja auch keine OO-Sprache, sondern bietet nur Elemente von OO an. Nahezu die komplette API und Laufzeitbibliothek ist nicht OO, sondern reine Funktionen.


7.

Dass OOP keine Vorteile hat gegenüber funktionaler Programmierung, wage ich ehrlich gesagt zu bezweifeln. Sicherlich ist es auch eine andere Art zu programmieren, aber die ganzen nützlichen Pattern bringen einen schon weiter. Ich denke, sowas lässt sich nur schwer mit funktionaler Programmierung umsetzen um das gleiche zu erreichen. Allerdings muss dazu gesagt sein, dass dies auch nur zutrifft, wenn OOP nicht wie eine "Funktionssammlung" aufgefasst wird. Denn da ist es gegenüber der funktionalen Programmierung meiner Meinung nach eindeutig minderwertig. Fakt ist aber, dass OOP im Normalfall langsamer ist als funktionale Programmierung. Es kommt immer darauf an, was man für eine Applikation schreibt.
Aber du hast Recht, wenn du sagst, dass jeder so programmieren soll, wie er es am besten kann. Dennoch sollte man andere Programmierparadigmen ausprobieren.


8.

@Rana: Ich weiß ja nicht, woher Du Deine Informationen ziehst. Nach meinem Wissensstand hat sich OOP auf breiter Linie durchgesetzt und alle anderen Paradigmen müssen erstmal beweisen, ob sie genauso stark sind.

Natürlich ist OOP erstmal schwierig zu verstehen, besonders dann, wenn man das Konzept wirklich durchdringen will, und darin nicht nur eine lustige technische Erweiterung sieht.

Und das ist auch der Fehler, der am meisten gemacht wird: OOP ist ein Konzept, das man eher philosophisch als technisch begreifen sollte. Dann erschließen sich das Konzept und die Umsetzung völlig logisch.


9.

Zitat:
Dass OOP keine Vorteile hat gegenüber funktionaler Programmierung,
Diese Verwendung von "funktionale Programmierung" ist nicht korrekt. Du meinst "prozedurale Programmierung". Das ist etwas anderes. ;)


10.

Wieder etwas dazugelernt. Werde es gleich korrigieren.

Edit: Kann es anscheinend nicht mehr editieren..


11.

Zitat:
@Rana: Ich weiß ja nicht, woher Du Deine Informationen ziehst. Nach meinem Wissensstand hat sich OOP auf breiter Linie durchgesetzt und alle anderen Paradigmen müssen erstmal beweisen, ob sie genauso stark sind.
Dein Wissensstand in Ehren - nach wie vor sind ca. 90% aller Programme in COBOL (nicht OOP) geschrieben.

OOP ist eine Nische - bestenfalls. Selbst unter den "ach so modernen" Serversprachen ist nur "JSP" objektorientiert. Weder PHP noch Perl sind objektorientiert.

Zitat:
Diese Verwendung von "funktionale Programmierung" ist nicht korrekt. Du meinst "prozedurale Programmierung".
Ja natürlich.


12.

? Echt rätselhaft ... Naja, Du musst es ja wissen...


13.

Zitat:
? Echt rätselhaft ... Naja, Du musst es ja wissen...
Was ist daran "rätselhaft"? Gehe doch mal in die Läden, die eine eigene EDV-Abteilung haben. Versicherungen, Banken, Airlines usw. - da ist alles mit Cobol programmiert. Natürlich gibt es bisweilen Frontends in Visual Basic, vielleicht auch ASP oder PHP. Aber die allerallermeisten Codezeilen sind Cobol. In den großen EDV-Abteilungen (beispielswiese Alte Leipziger - die kenne ich seit Jahren, weil wir die Entwicklungsumgebung und Infrastruktur betreuen) da sind mindestens 80% Cobolprogrammierer - ein paar C-Programmierer, ganz wenige Windows-Programmierer (Visual Irgendwas) und noch weniger Admins. So sieht die Welt der Grossrechner aus. IBM MVS/CICS (oder TSO) und Cobol.

Das ist für den 0815-PC-Benutzer nicht offensichtlich - aber wenn Du in der Industrie tätig bist (was ich dachte), sollte Dir das eigentlich nichts ungewöhnliches sein.


14.

Das sind aber alles Legacy-Systeme, die nur deswegen weiterentwickelt werden, weil ein Umstieg aus verschiedenen Gründen nicht möglich ist. Das kann man doch nicht als state-of-art zählen.


15.

Zitat:
Das kann man doch nicht als state-of-art zählen.
Von "state-of-the-art" ist bisher keine Rede gewesen - einzig davon, dass OO nicht besonders verbreitet ist. Ich empfinde OO auch nicht als state-of-the-art (wieso auch), es ist nur ein anderer Ansatz (und noch nicht einmal wahnsinnig neu).

Hersteller von Cobol Compilern sind sicherlich der Meinung, Cobol ist "state-of-the-art". Ich wüßte kein Kriterium, an welchem man das festmachen könnte. Fakt ist jedenfalls, dass es mehr Cobolzeilen weltweit gibt als alle anderen Programmiersprachen zusammen. Produktiv, wohlgemerkt.

Wenn Du an OO denkst - und der Meinung bist, es sei state-of-the-art und hoch verbreitet: an welche Sprache denkst Du dabei? Welcher Host unterstützt welche OO-Sprachen?


16.

Schon gut, Du hast Recht und ich meine Ruhe. Auf solche Goldwagen-Diskussionen hab ich im Moment echt keine Lust.


17.

Zitat:
Produktiv, wohlgemerkt.
Fortran sollte auch erwäht werden!
Ich kenn einige die noch darauf rumreiten und damit glücklich sind....


18.

Zitat:
Schon gut, Du hast Recht und ich meine Ruhe. Auf solche Goldwagen-Diskussionen hab ich im Moment echt keine Lust.
Billig und schlecht. Nicht vergessen: "Nach meinem Wissensstand hat sich OOP auf breiter Linie durchgesetzt und alle anderen Paradigmen müssen erstmal beweisen, ob sie genauso stark sind." - das war (ohne Not) Deine Behauptung.

@combie:
Zitat:
Fortran sollte auch erwäht werden!
Ich kenn einige die noch darauf rumreiten und damit glücklich sind....
Weil es auch eine Host-Sprache ist - und meine erste Programmiersprache (FORTRANT IV auf einer AEG-Maschine an der UNI Düsseldorf im Jahre 1979 - lang ist's her).


19.

Gott sei Dank befinde ich mich nicht in der Not, zu einer Diskussion gezwungen zu sein ;)


20.

Man darf das nicht so pingelig sehen....

Die nächste Merkur Mission:
Die Flugbahn wird von Fortran Freaks berechtet werden.
Die Finanzierung läuft über Cobolkessel...
Der Lander hat einen assemblerprogrammierten Z80 Prozessor on Board

Die Präsentation ist in naturnahem OOP gebaut!!!

(als überzeugter Forth Fan darf ich draussen bleiben)


21.

Zitat:
Gott sei Dank befinde ich mich nicht in der Not, zu einer Diskussion gezwungen zu sein
Das ist wirklich etwas schönes - man behauptet einfach irgendwas, egal ob falsch oder richtig, aber wenn eine andere Meinung unangenehm ist, ist man "einfach nicht gezwungen".

Für die allermeisten hier wird das wirklich zwanglos nichts ausmachen - für mindestens einen allerdings schon. Nicht alles steht Moderatoren gut.

Macht sicher auch nichts.


22.

Ich hab doch bereits geschrieben, dass Du Recht hast, was willst Du denn noch mehr? ;)


23.

Wie gesagt: Pingelig bringt es nicht!!
In Punkto Benutzeroberflächen ist das OOP Konzept weit vorn!!


24.

Zitat:
Das ist wirklich etwas schönes - man behauptet einfach irgendwas, egal ob falsch oder richtig,
Eine nicht messbare Behauptung aufstellen und sich auf den Standpunkt stellen "Beweist mir doch, dass ich Unrecht habe" wirkt ein bisschen ... merkwürdig.
Kann ich aber auch: Wie viele in Cobol programmierte Betriebssysteme kennst Du? Ich wage zu Behaupten alleine der Windows-Quellcode, Aufsummiert auf alle Installationen, Übertrifft deine ach so toll weit verbreiteten (nein, ich sage explizit nicht, dass es nicht verbreitet wäre) Cobol-Programme bei weitem. Der ist zwar wohl eher wenig OOP, aber das ist hier momentan egal, ich Behaupte nur 80% ist eine völlig an den haaren herbeigezogene Zahl. Beweise mir das Gegenteil!


25.

Zitat:
Wie viele in Cobol programmierte Betriebssysteme
0,0 ist auch nicht wichtig!!
Die Java OS Dinger sind auch alle gestorben...

Alle (relevanten)OS basieren auf Assembler, Forth oder C (macro assembler)

Mir ist kein wichtiges OOP OS bekannt...


26.

Bitte unterhaltet Euch doch wenigstens über die richtigen Dinge: Sprecht über die Paradigmen (höhere Sprachen der ersten Generation, strukturierte Programmierung, prozedurale P, OOP [und das alles nur innerhalb der imperativen Sprachen]) und nicht über Programmiersprachen, die es in fast allen Varianten dieser Paradigmen gibt.


27.

Zitat:
Sprecht über die Paradigmen
So gehts doch auch nicht!!

In allen üblichen Sprachen muß man das "Problem" so lange modifizieren, bis man es
in dieser Sprache optimal abhandeln kann! Forth ist die einzige Sprache, die man solange
modifiziert, bis sie die "Problemabhandung" optimal wiederspiegelt...


28.

? Was hat das jetzt mit der Diskussion zu tun? Das wäre dann wieder ein neues Paradigma, nämlich das der selbstmodifizierenden Programmiersprachen ;) ... das ist aber doch ne ganz andere Ebene...


29.

Ich wollte nicht unbedingt darauf hinaus, dass Cobol (als Programmiersprache) nicht weit verbreitet ist. Ich finde nur die 80%, die Rana ins Rennen gebracht hat sehr dubios und völlig unbeweisbar. Wenn dich das Beispiel Betriebssysteme abschreckt werden wir ein wenig abstrakter: Ich behaupte 99.42% aller Software ist objektorientiert programmiert.
Dass diese Zahl korrekt ist ist aber, zugegebenermaßen, recht unwahrscheinlich...


30.

Ich finde das auch völlig irrelevant.

Die Menge der Sprachkonstrukte in den imperativen Sprachen ist im Laufe der Zeit mit der Komplexität der Systeme eben angestiegen, wobei OOP erstmal die Spitze der Entwicklung ist, das zumindest bewiesen hat, dass es praktisch einsetzbar ist.

Ob es das in nur 0,5% der Fälle bewiesen hat oder in 99,5% ist dabei doch völlig egal ;)


31.

Oimel, du weist es genau: Ich habe nix gegen OOP!
Ich nutze es!

Aber:
Doofes Win basiert auf C...
Doofes Linux basiert auf C...
(in der Wurzel Assembler)

Alles andere ist nur Aufgestöpselt.. schön und wichtig, JA...


32.

Aber das ist doch ebenfalls irrelevant, oder wolltest Du Windows weiterentwickeln? Aber was würde denn dafür sprechen, ein neues Projekt anders als objektorientiert anzufangen?


33.

Zitat:
? Ich wage zu Behaupten alleine der Windows-Quellcode, Aufsummiert auf alle Installationen,
Ja klar - wenn man die Zeilen Quellcode mit Anzahl Installationen multipliziert, ist der Windows Sourcecode der mit den "meisten Zeilen". Ja.

Das ist so dermaßen doof, dass es mich erstaunt, dass ausgerechnet Du so einen Müll schreibst.

Sicherlich ist ein "Beweis" im mathematischen Sinn nicht möglich, aber ich werde gerne versuchen, die Quellen zu finden, die die Verbreitung von Cobol gegenüber OO-Sprachen halbwegs dokumentieren. Irgendwie scheint hier wirklich niemand mit großen EDV-Abteilungen und Rechnern Bekanntschaft gemacht zu haben - sonst würde diese Diskussion gar nicht entstehen.

OO spielt in der freien Wirtschaft keine Rolle - Null. Auch wenn mit Cobol in der Tat keine Betriebssystem entwickelt wurden (dafür ist Cobol auch nicht entwickelt worden). Allerdings ist die Anzahl Betriebssystem verschwindend klein im Vergleich zur Anzahl von "Organisationssoftware" (wie es früher vornehm hieß).


34.

@Rana: Je weiter man sich aus dem Fenster lehnte, desto höher ist die Gefahr, dass einem eine Taube auf den Kopf scheißt ;)


35.

Zitat:
oimel postete
Aber das ist doch ebenfalls irrelevant, oder wolltest Du Windows weiterentwickeln? Aber was würde denn dafür sprechen, ein neues Projekt anders als objektorientiert anzufangen?
Kein OOP OS hat z.Z. eine Chance!!


36.

Wieso hast Du Dich denn jetzt an dem OS festgefressen? :)


37.

Zitat:
ein neues Projekt
Gibt es OOP OS?
Nein!
Warum nicht?
Weil OOP überlegen ist?
Dann würde es nur noch OOP OS geben.. :D
Gibt es nur noch OOP OS?
Nein!
Dann ist es unterlegen!

Es ist in gewisser Linie ein überlegenes Konzept!!
Aber nicht in jeder Situation!!

In der Mensch <--> Maschine Komunikation ist es definitiv brauchbar!!!


38.

Zitat:
Es ist in gewisser Lienie ein überlegenes Konzept!!
Aber nicht in jeder Situation!!
In erster Linie wohl weil es langsamer ist als prozedurale Programmierung, das wurde hier aber auch schon gesagt.
Fakt ist das OO Code um Welten wartbarer ist als prozeduraler...


39.

Zitat:
Fakt ist das OO Code um Welten wartbarer ist als prozeduraler...
Ich glaube (wirkich)..!!
Aber der Beweis ist noch nicht erbracht....


40.

Doch mir persönlich wurde der Beweis in meiner täglichen Arbeit erbracht ;)
Nehmen wir doch mal Kollisionen von Variablennamen.
Wie leicht können Variablen doppelt verwendet werden in der prozeduralen Programmierung. Besonders wenn mehrere Entwickler an einem Projekt arbeiten. In Klassen ist alles schön sauber gekapselt. Wenn überhaupt können Klassennamen kollidieren wobei sich PHP mit einem cannot redeclare Error verabschiedet. Abgesehen davon kann ein Projekt via UML komplett visualisiert werden. Einzelne Teile einer Software sind leichter austauschbar und können zur Entwicklung auch leicht an Dritte weitergegeben werden. Nur um mal ein paar Vorteile zu nennen...

Schlussendlich muss ich Rana aber Recht geben, wenn er sagt jeder soll so Coden wie ers am besten kann.
Ich will Niemanden zu seinem Glück zwingen ;)


41.

Zitat:
Foggy postete
Doch mir persönlich wurde der Beweis in meiner täglichen Arbeit erbracht ;)
Mir auch..... zumindest ein Nachweis.... aber nur in interaktion mit Usern...

Aber einen Großteil meiner Arbeit ist "low level" also Interaktion mit
der realen "Physik der Welt" und der ist es wurscht, wie ich die Dinge sehe!!


42.

Wenn wir uns über Betriebssysteme unterhalten: Da ist es doch einfach so, dass man ein Betriebssystem und dessen Schnittstellen nicht einfach austauschen kann. Es dauert anscheinend um die 20 Jahre, bis ein neues OS sich einigermaßen etablieren kann (siehe Linux). Und damals war OO tatsächlich noch ein Ding, mit dem sich fast ausschließlich die Wissenschaft beschäftigt hat.

Sprich: Meiner Meinung nach liegt es nicht an der OO, dass sich Betriebssysteme mit solchen Ansätzen nicht durchsetzen konnten.

Die ersten OO-Ansätze wurden übrigens entwickelt, als man bei komplexen Simulationen festgestellt hat, dass man zwar immer mit den gleichen Arten von Information rechnet, aber die sich im Detail doch wieder unterscheiden ;)


43.

Zitat:
Fakt ist das OO Code um Welten wartbarer ist als prozeduraler...
Das bezweifle ich zutiefst und die Praxis spricht eine andere Sprache. Ich habe in den letzten 25 Jahren immer Projekte eingehen sehen - teure, sehr teure Projekt, darunter ein ehrgeiziges von BMW, alles sollte OO werden. Nachdem 40 Millionen DM verschleudert waren, wurde das Projekt eingestampft und es wurde wieder klassich programmiert. Das ist zwar inzwischen fast 20 Jahre her, aber man lernt daraus.

Ich vermute, dass die meisten hier noch nie in einem richtig großen Projekt mitgearbeitet haben. Wo Projektmanagement, Versionierung, Status etc. eine wesentliche Rolle spielen. Wenn in C++ eine Klassendefinition geändert wird, in einem solchen komplexen Umfeld, muss ein gewaltiger "make" (ich nenne es mal ein einfach so) gestartet werden, weil alles neu kompiliert und gelinkt werden muss. Da passieren so ekelhafte Dinge (weil irgendeine DLL irgendwo liegenblieben ist usw.), dass es bei komplexer werdender Anforderung exponentiell schwieriger wird, diese Dinge zu beherrschen.

Dazu kommt, dass ein Großteil der Programmierer schlicht kein OO können - und sie werden es auch nie können, weil sie nicht gut genug sind. Man kann nicht in einer EDV Abteilung einer Bank oder Versicherung mal eben 120 Cobolprogrammierer umschulen oder gar entlassen. Zudem braucht man sie ja auch noch, denn die großen Hosts arbeiten nun einmal mit Cobol - das ist ein Standard. Wer ein Flugticket bucht, wird irgendwo im Hintergrund von einem Cobolprogramm bedient. Ebenso wer eine Versicherungspolice abschließt. Die Kontoauszüge sind Outputs von Cobolprogrammen, ebenso die Stromrechnung.

Aus diesen Gründen (es gab mal in frühen neunzigern das Schlagwort "Peopleware" - man muss die Leute da abholen, wo sie stehen und nicht irgendetwas vermeintlich moderneres aufzwingen - das geht hundertprozentig in die Binsen) setzt sich OO nicht durch. Natürlich gibt es Visual C++, Visual Basic und auch viele Programmierer - aber die meisten Codezeilen werden immer noch in großen EDV-Abteilungen produziert. Das sind keine Programme, die man bei Amazon kaufen kann - aber es sind viele Programme, sehr teure Projekte und es ist die eigentliche EDV-Welt.

Die meisten Informatiker, die von der Uni in so einen Betrieb kommen, brauchen erst einmal ein Jahr oder mehr, um aus ihrem "Wachkoma" aufzuwachen: so fremd und weit entfernt ist der Lehrbetrieb von der Realität.

Zitat:
Je weiter man sich aus dem Fenster lehnte, desto höher ist die Gefahr, dass einem eine Taube auf den Kopf scheißt
Ich lehne mich keinen Millimeter aus dem Fenster - mein "Erwachen" hat schon 1986 angefangen. Wann wachst Du auf?


44.

@Rana: OO hat sich aber auch erst in den letzten 20 Jahren etabliert, vielleicht sind Deine Infos einfach zu alt? ;)


45.

Zitat:
OO hat sich aber auch erst in den letzten 20 Jahren etabliert, vielleicht sind Deine Infos einfach zu alt?
Nein. Die Menschen, die in den o.g. Betrieben die Entscheidungen treffen, von denen ich einige kenne, entscheiden auch heute noch so: kein OO.

Das hat sich etwas gelockert, weil GUIs auf dem Vormarsch sind. Visual Basic wird relativ häufig genutzt - unsere Komponente hat gerade das Ziel, die Architekturen zu verbinden. Aber die Anzahl Cobolprogrammierer ist immer noch der größere Teil.


46.

Vielleicht können wir uns darauf einigen, dass OO in manchen Bereichen auf dem Vormarsch ist? :) SAP z.B. baut immer mehr von ihrem System nach Java um...


47.

Ich habe zu diesem Thema hier (PDF) einen interessanten Artikel gefunden. Da bin ich auf OO-Cobol gestossen... ein Versuch wars Wert ;)


48.

@Rana: Dein letzter (langer) Beitrag zeigt doch, dass Cobol nur noch benutzt wird, weil
- Die Cobol-Programmierer nicht in der Lage sind/Zeit haben, sich Neues beizubringen
- Noch zu viel auf Cobol aufsetzt und man das aus Geld-/Zeit-Gründen nicht umstellen kann.

Das sind doch aber keine Gründe gegen OOP.

Nach dieser Einschätzung müsste man denken, es sei noch alles in Assembler geschrieben, weil man es aus Zeit-/Geld-Gründen nicht umstellen konnte...


49.

Zitat:
Das sind doch aber keine Gründe gegen OOP.
Ich habe das auch nirgends geschrieben. Ich habe nichts gegen OOP.

Zitat:
Nach dieser Einschätzung müsste man denken, es sei noch alles in Assembler geschrieben, weil man es aus Zeit-/Geld-Gründen nicht umstellen konnte...
Wieviel wurde denn in Assembler geschrieben? Nicht so viel - Cobol gibt es schon ziemlich lange.


50.

Aus dem Nähkästchen:

Ein großteil meiner Arbeit, betrifft die Programmierung von SpeicherProgrammierbarenSteuerungen (SPS oder engl. PLC).
Diese Steuerungen laufen in sicherheitskritischen Bereichen. Im Falle einer Fehlfunktion könnte im Extremfall ein ganzes
Dorf entvölkert werden. Natürlich ist dieses ganz und gar unerwünscht!

Als Entwickler muß ich an allen Ecken und Kanten das "Fail save" Konzept realisieren!
Auch in der Software!

Da alle Machinen eine TÜV Prüfung durchlaufen, muß ich eine mindest Reaktionszeit GARANTIEREN!!
In meinem Fall ist das 1 Sekunde von "run" bis "fail save"..
Meist bekomme ich das innerhalb von 20 mSec hin.. (Prüfer glücklich)

Witzigerweise gibt es auch in diesem Bereich keine einzige OOP Sprache....

Technisch:
Das SPS Programm wird immer von Anfang bis zum Ende durchlaufen.
Am Ende eines Durchlaufs wird jeweils der Watchdog getriggert.
An diesen Watchdog komme ich Programmtechnisch nicht ran!
Schleifen gehören also zu den, zu vermeidenen, Sprachmitteln...


1. Wäre es eine OOP Sprache, müssten bei jedem Durchlauf alle Klassen neu erzeugt werden.
Alternativ könnte man sich das auch als mit statischen Klassen gebaut vorstellen..
Aber viele der OOP Vorteile wären damit aus dem Rennen.

2. Ich muß dem Prüfer im Quellcode beweisen, das bei jedem Durchlauf IMMER alle Sicherheitsprüfungen erreicht
und abgearbeitet werden. Das wäre bei einer OOP Sprache nicht mehr so linear-einfach möglich.

Also werden auch in diesem Bereich (erstmal) keine OOP Sprachen Einzug halten!!
Und das aus rein praktischen Gesichtspunkten!!
Also nicht auf Grund von irgendeinem esoterischem Beharrungsverhalten...

--------

Das betrifft alle anderen sicherheitsrelevanten Bereiche!
Auch die Raumfahrt und den Flugzeugbau!

Gegen die Verwendung von OOP, in der Weiterverarbeitung der Daten, oder Visualisierung, ist nichts einzuwenden
und auch allgemein üblich.


51.

Wobei die theoretischen Grundlagen zur Benutzung von OOP in solchen Umgebungen sicherlich da wären. Die Korrektheit von Programmen lässt sich mit oder ohne OOP genauso gut (bzw. schlecht) beweisen.

Und dass die Objekte zur Laufzeit erstellt werden müssen, stimmt auch nicht ganz: Man kann sich viele Fälle vorstellen, in denen ein Compiler das System so weit optimiert, dass die meisten Objekte schon zum Systemstart initialisiert werden. Auf das Geschick des Programmierers kommt es natürlich trotzdem an ;)

Siehe:
http://www4.in.tum.de/~spichkov/verisoft/index.html
http://www4.in.tum.de/proj/theoremprov/research.html


52.

Die Geschmacksfrage stellet sich z.Z. nicht, dank fehlender Alternativen..

Zitat:
dass die meisten Objekte schon zum Systemstart initialisiert werden
Sowas, meinte ich mit "statisch"...

Zitat:
meisten Objekte
Wieso die meisten? Alle!!
Es bräuchten nie Objekte zu Laufzeit erzeugt werden! Wozu auch?
Die Konfigutation einer solchen Maschine ändert sich nie,
sonst wäre ja eine neue Prüfung notwendig.

Zitat:
Die Korrektheit von Programmen lässt sich mit oder ohne OOP genauso gut (bzw. schlecht) beweisen.
Das können Automaten sowieso nicht leisten, da muß der Mensch ran.
Die Prüfung ist bei einer flachen prozeduralen, assemblerartigen Struktur erheblich übersichtlicher, als wenn
man baumartige Vererbungsstrukturen durchlaufen muß.

Und überhaupt, das Konzept der Referenzen oder Pointer fehlt den SPSn vollständig...
Auch wenn intern Sprung oder Lable Tabellen existieren, nach der Compilierung sind sie konstant.

Der Einsatz von OOP Techniken, nur um ihrer selbstwillen, oder weil es gerade modern ist, bringt es nicht...
Das einzige was man damit wirksam erreichen könnte, wäre eine erhöhte innere Komplexität! Und damit wird
gleichzeitig die Ausfallwahrscheinlichkeit gesteigert.

Komplexität im Beispiel:
Eine von mir verwendetet SPS, hat 64KB Ram + 128 KB FlashProm und das ist in der SPS Welt schon
ein recht fetter Brummer. Der kompilierte Code belauft sich auf ca 10KB. Damit werden ca. 80 Sensoren
und 40 Aktoren abgefragt, bzw. angesteuert.

Und da soll man einen OOP Wasserkopf drauf setzen???
Nee......


53.

Natürlich soll man keine Objekte erzeugen, wo es keine Objekte gibt. Das wäre ja quatsch. Objekte sind nur dann sinnvoll, wenn man überhaupt abschließbare Einheiten im System benennen kann; wenn es so etwas gar nicht gibt, braucht man auch keine Objekte.

Außerdem sind 10KB Code ja so wenig, dass sich die Vorteile von OOP sowieso nicht ausspielen ließen.


Hier gehts zum Orginal Eintrag "Objektorientiertes PHP" im Forum
 
phpforum.de | Impressum