Strukturiertes vs. objektorientiertes Coden

[Wolfgang Wiese]

Hiho,

<frust>
kann mir mal jemand logisch erklaeren, warum viele
Leute bei der Frage 'strukturiertes' contra 'objektorientiertes'
Programmieren so schwarz-weiss sind, bzw. warum diese
Frage ueberhaupt aufkommt?

Hintergrund: Alle Nase wieder muss ich mich mit jemand
darueber streiten, wieso ich doch bitte nicht alles
objektorientiert mache... oder andersrum: warum ich es wage,
eben das zu machen, es sei doch nur Zeitverschwendung...

Bevor jetzt die Flames kommen:
Meiner Meinung nach sollte man ein gesundes Mix verwenden,
d.h. wenn es sich anbietet nimmt man das eine, wenn nicht,
dann das andere.
Ich halte es fuer Bloedsinn, nur weil man auf der 'oo'-Schiene
ist, jede Kleinigkeit auch damit machen zu muessen.

Beispiel:
Redirection von Webseiten mit CGI.pm
Dort brauch ich wunder was an 4 Zeilen und muss
das Modul einladen (ja, ich kenne den Autoloader),
nur um eine redirection machen zu muessen, die
ich ohne CGI.pm auch so in einer Zeile
machen kann....

Tja....aber wie man es macht, so ist es falsch....
Aber warum wird man so schief angesehen, wenn man es so macht, wie
man es am besten kann und wie man am ehesten fertig wird.
Im ernst; Wenn es um eine mittelkleine Aufgabe geht, dann
ist derjenige der strukturiert programmiert doch schon laengst fertig, wo
der OO-Programmierer noch immer seine Klassen sucht...

Natuerlich soll der OO-Programmierer spaeter dann voll
die Vorteile haben, wenn es an groessere Projekte geht...
aber stimmt das wirklich? Wieviele OO-Programmierer mussten spaeter dann doch wieder alles
anedern, schlichtweg, weil sie in der Planungsphase was vergessen
hatten und vorallem, weil sie nach einiger Zeit ihre eigenen
Klassen nicht mehr kennen :))

Tja, nur so gedanken....
</frust>

Ciao,
  Wolfgang

[Calocybe]

Hallo Wolfgang!

<frust>
kann mir mal jemand logisch erklaeren, warum viele
Leute bei der Frage 'strukturiertes' contra 'objektorientiertes'
Programmieren so schwarz-weiss sind, bzw. warum diese
Frage ueberhaupt aufkommt?

Nee. ;-)

Bevor jetzt die Flames kommen:
Meiner Meinung nach sollte man ein gesundes Mix verwenden,
d.h. wenn es sich anbietet nimmt man das eine, wenn nicht,
dann das andere.

Yepp.

Ich halte es fuer Bloedsinn, nur weil man auf der 'oo'-Schiene
ist, jede Kleinigkeit auch damit machen zu muessen.

Jetzt kommt ja auch XML, da sehen dann alle Webseiten in allen Browsern gleich aus... ;-)

Beispiel:
Redirection von Webseiten mit CGI.pm
Dort brauch ich wunder was an 4 Zeilen und muss
das Modul einladen (ja, ich kenne den Autoloader),
nur um eine redirection machen zu muessen, die
ich ohne CGI.pm auch so in einer Zeile
machen kann....

Naja, CGI.pm hat nichts mit OO zu tun. Das Object style interface vermeidet lediglich das schreiben von z.B. CGI::header(), wenn man die Funktionen nicht in den eigenen Namespace importieren will (Namespace polluting). Stattdessen schreibst Du eben $q->header(); naja, wem's besser gefaellt. Da koennte man ja auch sagen, VBScript waere objektorientiert, weil z.B. in ASP-Seiten Server.Redirect() schreiben muss, um so eine Umleitung zu erreichen. Und durch den Punkt im Namen ist es natuerlich volle Kanne OO, boah ey! ;-)

Anders herum brauche ich nicht unbedingt C++ oder Java, um objektorientiert zu programmieren. Das geht mit C ebenfalls. Nur die Vererbung ist dort nicht so einfach. (Habe gehoert, mit ein paar fiesen Preprocessor-Tricks kriegt man das auch irgendwie hin.)

Tja....aber wie man es macht, so ist es falsch....
Aber warum wird man so schief angesehen, wenn man es so macht, wie
man es am besten kann und wie man am ehesten fertig wird.

Vielleicht weil diejenigen selber keine Ahnung haben?

Im ernst; Wenn es um eine mittelkleine Aufgabe geht, dann
ist derjenige der strukturiert programmiert doch schon laengst fertig, wo
der OO-Programmierer noch immer seine Klassen sucht...

Na, das ist jetzt aber auch polemisch.

Natuerlich soll der OO-Programmierer spaeter dann voll
die Vorteile haben, wenn es an groessere Projekte geht...
aber stimmt das wirklich? Wieviele OO-Programmierer mussten spaeter dann doch wieder alles
anedern, schlichtweg, weil sie in der Planungsphase was vergessen
hatten und vorallem, weil sie nach einiger Zeit ihre eigenen
Klassen nicht mehr kennen :))

Naja, OO ist kein Allheilmittel und gegen Designfehler hilft es bestimmt nicht.

So long

[Rolf]

Hiho,

<frust>
kann mir mal jemand logisch erklaeren, warum viele
Leute bei der Frage 'strukturiertes' contra 'objektorientiertes'
Programmieren so schwarz-weiss sind, bzw. warum diese
Frage ueberhaupt aufkommt?

Try...
Naja, das ist halt das Schubladendenken, ich glaube: ein Jeder neigt ein bisserl dazu alles und auch allé irgentwie irgendwo irgendwann einzuordnen - das wirkliche Leben auf Objekte abzubilden, nicht nur die EDVler, schlimm dran sind außer wir alle auch Ornithologen, Entomologen, Botaniker usw. (Uns überfüllts, wir ordnen. Es zerfällt... wir ordnen wieder und - zerfallen selbst /R.M. Rilke)

Hintergrund: Alle Nase wieder muss ich mich mit jemand
darueber streiten, wieso ich doch bitte nicht alles
objektorientiert mache... oder andersrum: warum ich es wage,
eben das zu machen, es sei doch nur Zeitverschwendung...

Jeder Streit führt zu einem Ergebnis! (der Klügere trifft seine Entscheidung...)

Bevor jetzt die Flames kommen:
Meiner Meinung nach sollte man ein gesundes Mix verwenden,
d.h. wenn es sich anbietet nimmt man das eine, wenn nicht,
dann das andere.

Ist Ok!

Ich halte es fuer Bloedsinn, nur weil man auf der 'oo'-Schiene
ist, jede Kleinigkeit auch damit machen zu muessen.

Beispiel:
Redirection von Webseiten mit CGI.pm

Ooops, das wehet in meine Richtung ;-)

Dort brauch ich wunder was an 4 Zeilen und muss
das Modul einladen (ja, ich kenne den Autoloader),
nur um eine redirection machen zu muessen, die
ich ohne CGI.pm auch so in einer Zeile
machen kann....

Moment, ohne CGI.PM brauchst Du mehr als eine Zeile, damits sauber läuft...

Tja....aber wie man es macht, so ist es falsch....
Aber warum wird man so schief angesehen, wenn man es so macht, wie
man es am besten kann und wie man am ehesten fertig wird.
Im ernst; Wenn es um eine mittelkleine Aufgabe geht, dann
ist derjenige der strukturiert programmiert doch schon laengst fertig, wo
der OO-Programmierer noch immer seine Klassen sucht...

Natuerlich soll der OO-Programmierer spaeter dann voll
die Vorteile haben, wenn es an groessere Projekte geht...
aber stimmt das wirklich? Wieviele OO-Programmierer mussten spaeter dann doch wieder alles
anedern, schlichtweg, weil sie in der Planungsphase was vergessen
hatten und vorallem, weil sie nach einiger Zeit ihre eigenen
Klassen nicht mehr kennen :))

Ich habe mal in einem Praktikum bei einer EingabeMaske für eine Adressdatenbank das Input-Feld für die Telefonnummern vergessen und -obwohl die Telefonnummern in den Listen standen - keiner hats gemerkt ;-)

Tja, nur so gedanken....
</frust>

Denke ich auch manchmal; Passer-Domesticus(Domspatz) Rolf, viele Grüße!

[Martin Speiser]

Hi Wolfgang,

kann mir mal jemand logisch erklaeren, warum viele
Leute bei der Frage 'strukturiertes' contra 'objektorientiertes'
Programmieren so schwarz-weiss sind, bzw. warum diese
Frage ueberhaupt aufkommt?

Hm. Vielleicht haben diese Leute noch kein Real-World-Projekt durchgezogen? Sicher, OOP hat Vorteile, sogar ziemlich viele. Aber wie du bemerkt hast, es ist kein Allheilmittel. Natürlich kann man alles in Klassen abbilden, wenn man es darauf anlegt, aber manche Sachen gehen mit prozeduraler Programmierung einfach schneller, pragmatischer, einfacher, und wartbarer.

Kleine Begriffsklärung nebenbei. "Strukturiert" bezieht sich auf den Codierstil, "prozedural" ist das Gegenstück zu Objektorientierung. Strukturieren muss man auch bei OOP, sonst gibt es (hoffentlich) Ärger mit dem Projektleiter.

Hintergrund: Alle Nase wieder muss ich mich mit jemand
darueber streiten, wieso ich doch bitte nicht alles
objektorientiert mache... oder andersrum: warum ich es wage,
eben das zu machen, es sei doch nur Zeitverschwendung...

Kleines Beispiel aus dem aktuellen Projekt, an dem ich arbeite. Hier haben wir Images als BLOB in einer Datenbank abgelegt. Die Images werden über eine kleinen C++-Struktur (also eigentlich Klasse) beschrieben, in der z.B. die Content ID steht. Die Datenbank selbst wird über DCOM/OLE-DB angesprochen, liegt also auf einem anderen Rechner. Das Objektmodell, in dem die Image-Struktur modelliert ist, ist ein Zwitter. Einerseits wird sie vom Administrationstool (Composer) benutzt, also vom Client, andererseits von einer Extension-DLL vom IIS. Um den Code klein zu halten ist also keine Methode definiert, die das Image am Bildschirm zeichnet. Das erledigt eine kleine prozedurale Funktion im Composer, der hauptsächlich die Struktur übergeben wird, und das Rechteck, in dem gezeichnet werden soll. Das extra in einer Klasse zu kapseln würde Overhead produzieren und Performance kosten.

Ich hoffe die Erklärung war einigermassen verständlich ;-)

Tja....aber wie man es macht, so ist es falsch....

Nö. Richtig programmieren heisst schnellen und wartbaren Code zu schreiben. In der Praxis muss man pragmatisch vorgehen.

Natuerlich soll der OO-Programmierer spaeter dann voll
die Vorteile haben, wenn es an groessere Projekte geht...
aber stimmt das wirklich? Wieviele OO-Programmierer mussten spaeter dann doch wieder alles
anedern, schlichtweg, weil sie in der Planungsphase was vergessen
hatten

Das ist kein Merkmal von OOP, das passiert bei prozeduraler Programmierung genauso. Ich spreche aus leidvoller Erfahrung. Und bloss nicht dem Chef verraten, dass man gerade den Code von mehreren Wochen in die Tonne tritt, und in ein paar Tagen neu aufsetzt <g>

und vorallem, weil sie nach einiger Zeit ihre eigenen
Klassen nicht mehr kennen :))

Dafür gibt's UML-Tools, z.B. Rational Rose.

Gruß,
Martin

[Marko]

Hallo Wolfgang,

also aus eigener Erfahrung muss ich sagen, dass es sich wohl schon bei relativ kleinen Projekten lohnt  OO zu programmieren, vor allem wenn absehbar ist, das man auch in Zukunft noch einiges dran flicken wird. Bei kleinen Programmen, und solchen die wenn sie einmal laufen wahrscheinlich nicht gross umgebaut werden müssen, denke ich das es durchaus sinnvoll ist prozedural zu schreiben, da ist OO eine Menge Overhead. Persönlich finde ich richtig gutes Objektorientiertes Design aber eine tolle Sache, allerdings muss man das wirklich lernen, prozedurale Ansätze sind bedeutend einfacher zu kapieren. Für einen richtig guten Objetorientierter Stil braucht man wohl Monate oder Jahre zum lernen, aber irgendwann schaff ich das auch mal ;-)

Gruss Marko

[ThomasP]

Hi Wolfgang!

Schoenes thema hast Du da angeschnitten :-)

<frust>
kann mir mal jemand logisch erklaeren, warum viele
Leute bei der Frage 'strukturiertes' contra 'objektorientiertes'
Programmieren so schwarz-weiss sind, bzw. warum diese
Frage ueberhaupt aufkommt?

Es gibt eben OO-Fanatiker und Strukturfanatiker und andere auch *g*. Genauso, wie es IE-Fanatiker und NC-Fanatiker gibt. Da kannst Du nichts dran drehen.

Hintergrund: Alle Nase wieder muss ich mich mit jemand
darueber streiten, wieso ich doch bitte nicht alles
objektorientiert mache... oder andersrum: warum ich es wage,
eben das zu machen, es sei doch nur Zeitverschwendung...

Das sind dann meist die Leute, die es nicht besser koennen oder nur eine Methode beherrschen. Wer beide kann, wird wissen, welche wann am besten eingesetzt wird.

Bevor jetzt die Flames kommen:
Meiner Meinung nach sollte man ein gesundes Mix verwenden,
d.h. wenn es sich anbietet nimmt man das eine, wenn nicht,
dann das andere.
Ich halte es fuer Bloedsinn, nur weil man auf der 'oo'-Schiene
ist, jede Kleinigkeit auch damit machen zu muessen.

Ganz genau, wie man auch manche Sachen per Makro regelt und andere per Programm.

Im ernst; Wenn es um eine mittelkleine Aufgabe geht, dann
ist derjenige der strukturiert programmiert doch schon laengst fertig, wo
der OO-Programmierer noch immer seine Klassen sucht...

Wobei es immer auch um die Erweiterbarkeit geht. Und in eine Klasse ist halt mal schneller ne member implementiert.

Natuerlich soll der OO-Programmierer spaeter dann voll
die Vorteile haben, wenn es an groessere Projekte geht...
aber stimmt das wirklich? Wieviele OO-Programmierer mussten spaeter dann doch wieder alles
anedern, schlichtweg, weil sie in der Planungsphase was vergessen
hatten und vorallem, weil sie nach einiger Zeit ihre eigenen
Klassen nicht mehr kennen :))

Das ist zwiespaeltig. Gute Planung ist bei allen Sachen wichtig. Genauso die Dokumentation. Ich hab schon quasi-spaghetticode zerlegt, der saumaessig dokumentiert war - *schreienddavonrenn*. Und da muss ich sagen, ist eine sauber programmierte Klasse auch ohne Doku zu durchschauen. Ausserdem wie gesagt, schneller mal ne member dazugeschrieben, ohne die sonstige Struktur zu zerstoeren.

Tja, nur so gedanken....
</frust>

Jaja, ein weites Thema das *g*.

Mitfuehlender Gruß
Thomas

[Michael Schröpl]

Hi,

<frust>
kann mir mal jemand logisch erklaeren, warum viele
Leute bei der Frage 'strukturiertes' contra 'objektorientiertes'
Programmieren so schwarz-weiss sind, bzw. warum diese
Frage ueberhaupt aufkommt?

Dann frage ich mal dagegen: Wer "programmiert" denn heute noch - in dem Sinne, in dem man es vor 20 Jahren getan hat?
Wer schreibt denn heute noch Compiler oder Datenbanken oder Systemfunktionen oder ... ?

Diejenigen, die das tun, die an großen Projekten arbeiten, die Monatenlang dasselbe Projekt in derselben Programmiersprache bearbeiten (ich verwalte - alleine - die Altlasten eines Projektes mit ca. 15 Mannjahren Entwicklungsaufwand und ebenso vielen Programmiersprachen!), also diejenigen, die Softwareentwicklung in industriellem Maßstab betreiben und nicht "gestern" ihre Lösung beim Kunden abgeben müssen, werden sich das bestmögliche Werkzeug zulegen, weil sie auch die Zeit haben, dieses Werkzeug entsprechend gut zu beherrschen.
Und ich kann mir gut vorstellen, daß ich unter diesen Bedingungen objektorientiert programmieren würde. Ich hatte die Situation allerdings noch nie - deshalb bin ich privat bei Turbo-Pascal und im Dienst bei Perl gelandet, und bei SQL, und bei ...

Hintergrund: Alle Nase wieder muss ich mich mit jemand
darueber streiten, wieso ich doch bitte nicht alles
objektorientiert mache... oder andersrum: warum ich es wage,
eben das zu machen, es sei doch nur Zeitverschwendung...

Dann sollen diejenigen es unter *Deinen* Voraussetzungen mit ihrem Werkzeug schneller vorführen. ;-)

Meiner Meinung nach sollte man ein gesundes Mix verwenden,
d.h. wenn es sich anbietet nimmt man das eine, wenn nicht,
dann das andere.
Ich halte es fuer Bloedsinn, nur weil man auf der 'oo'-Schiene
ist, jede Kleinigkeit auch damit machen zu muessen.

Wenn ich mit OO alles machen könnte, d. h. das hinreichend gut beherrschen würde, dann würde ich in der Tat versuchen, jede Kleinigkeit damit zu machen.
Einerseits, weil ich dabei die entsprechende Sprache immer besser beherrschen lerne, andererseits, weil mein Code dann über alle Projekte möglichst einheitlich ist.
Es geht da nicht allein um meine Coding-Geschwindigkeit, sondern auch um den Zeitaufwand, den mein Kollege braucht, um sich in meine Programme einzuarbeiten - ich habe Perl anhand von 5000 Zeilen undokumentierten Code *ohne* "use strict" und "-w" (und ohne Programmdokumentation!) gelernt, und das war ziemlich bitter.

Tja....aber wie man es macht, so ist es falsch....

Wenn Du die Meinung Anderer anerkennst, mußt Du Deine Gründe dafür haben. ;-)

Aber warum wird man so schief angesehen, wenn man es so macht, wie

Das ist keine Frage aus dem Gebiet "Programmierung", sondern aus dem Gebiet "Menschelei". ;-)

Im ernst; Wenn es um eine mittelkleine Aufgabe geht, dann
ist derjenige der strukturiert programmiert doch schon laengst fertig, wo
der OO-Programmierer noch immer seine Klassen sucht...

Wenn er ständig OO macht, kann er *seine* Klassen wahrscheinlich auswendig.

Natuerlich soll der OO-Programmierer spaeter dann voll
die Vorteile haben, wenn es an groessere Projekte geht...
aber stimmt das wirklich? Wieviele OO-Programmierer mussten spaeter dann doch wieder alles
anedern, schlichtweg, weil sie in der Planungsphase was vergessen
hatten und vorallem, weil sie nach einiger Zeit ihre eigenen
Klassen nicht mehr kennen :))

Je mehr man OO geübt ist,  desto weniger Entwurfsfehler wird man wohl machen. Ich stelle mir den Objektentwurf ganz ähnlich vor wie den Entwurf einer relationalen Datenbank, und auch da muß man zuallererst eine ganz eigene Methode lernen, die mit algorithmischer Programmierung gar nichts zu tun hat. Aber wenn man das drauf hat, dann muß man es auch nicht immer wieder neu lernen.

Viele Grüße
          Michael
(der seit dieser Woche keinen dienstlichen WWW-Zugang mehr hat - schluchz ...)

[kaepten]

Hi Michael

Ich stelle mir den Objektentwurf ganz ähnlich vor wie den Entwurf einer relationalen Datenbank, und auch da muß man zuallererst eine ganz eigene Methode lernen, die mit algorithmischer Programmierung gar nichts zu tun hat. Aber wenn man das drauf hat, dann muß man es auch nicht immer wieder neu lernen.

Ich finde das einen sehr guten Vergleich, der auch so zutrifft!

cheers
kaepten

[Steffen Gerlach]

Hallo,

Ja, ich halte OOP auch für etwas überschätzt. Sie ist eine gute Ergänzung zur proz. Pr., aber kein Ersatz. Wer behauptet, er implementiert jedes Programm rein objektorientiert, der glaubt wahrscheinlich, OO bestünde darin, daß jedes Datum und jede Funktion Member irgendeiner Klasse sind. Wirklich reine OOP kann fürchterlich umständlich sein.

Wie realisiert man z.B. eine Prozedur Doppelpass(Spieler1,Spieler2) in OOP? Vielleicht so: Spieler1.Doppelpass(Spieler2)? Das wäre schon keine richtige OOP mehr, sondern eine Mischung mit prozeduraler Pr. Die wahre OO-Lösung führt eine zusätzliche Klasse ("Doppelspieler"?) ein und schreibt: Doppelspieler(Spieler1,Spieler2).Doppelpass...

Anderes Bsp: RoteKarte(Team,Spieler), sieht in OOP so aus: Team.Spieler.RoteKarte - toll, nur leider ist so innerhalb von RoteKarte zwar der Spieler (implizit, this) bekannt, nicht aber das Team (beforethis?). Man müßte es entweder als prozeduralen Parameter übergeben (keine OOP, hehe!) oder aber in der Spieler-Klasse ein zusätzliches Datenfeld einrichten, das man irgendwann vor Aufruf von RoteKarte für jeden einzelnen Spieler mit einer Referenz auf das Team initialisiert.

Meine Meinung: OOP macht sich dann gut, wenn (1) es sich anbietet oder (2) wenn mehrere Personen an einem Projekt arbeiten und eine klare, nachvollziehbare Schnittstelle benötigt wird. OOP auf Krampf bringt's nicht.

Gruß
Steffen

[Katrin]

Ich habe gestern zu dem Thema einen Erkärung gefunden, die es schön simpel beschreibt:
Programme in strukturierter Programmierung wurden (früher) gewartet und weiterentwickelt,
in dem der Code  kopiert wurde.

Dann wurden die Ergänzungen bzw. neuen Anforderung in dieser Kopie umgesetzt.
Das führt zu einem Haufen von Quellen für die in etwa gleichen Aufgaben... unnötige Wartung usw.
In OO ist die Pflege, Modellierung, Erweiterbarkeit, Schnittstellendefinition
Teil des Systems (der Programmierung und Programmiersprache), also zusätzlicher Aufwand,
der letztlich zu konsistenteren Modulen führt.

Eine sicher etwas reduzierte Sicht, aber einleuchtend, wie ich finde.
Katrin.