nicht angemeldet
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 ...)