Globale Variablen - warum in der DP so verpönt?

[Daniel]

Zitat:

Zitat von nieurig

Die Arroanz stinkt ...
Alle und hier meine ich wirklich ALLE aktuellen Programmiersprachen arbeiten objektorientiert. Dafür gibt es eine Reihe guter Gründe. Wenn Du so gut programmieren kannst, laß Dir eines gesagt sein: Wenn Du OOP verwenden würdest, könntest Du noch mehr Geld scheffeln :-))

Ich möchte Euch bitten, umgehend zur sachlichen Diskussion zurück zu finden.


Was ist denn im Moment mit einigen von Euch los? Ihr haut Euch völlig kompromisslos und stur Eure Philosophien um die Ohren, ohne die Position des Gegenüber zu respektieren bzw. sachlich dagegen zu argumentieren. Und das geht nicht nur so in diesem Thread. Zu allem Überfluss versteift Ihr Euch dabei auch noch auf Eure Position anstatt die möglichen positiven Effekte einer Kombination mehrerer Techniken in Erwägung zu ziehen. OOP und Patterns sind schön und gut - aber eine sture Anwendung derer alleine wird auch keine brauchbare Anwendung hervorzaubern. Wie immer will der Einsatz jeder Technik und jedes Werkzeuges wohl überlegt sein.

Ich bitte jetzt alle Beteiligten, sich auch mal an die eigene Nase zu fassen und das eigene Diskussionsverhalten kritisch zu überdenken. So habt Ihr hier früher nicht diskutiert und ich möchte auch nicht, dass dieser Stil so fortgeführt wird.

[nieurig]

Hallo Daniel,
sorry, das geht mich an.
OK. Ich hätte die Art des von mir Zitierten ignorieren sollen ...
oder aber mich selbst im Ton mäßigen sollen. (Erster Beitrag wird entsprechend geändert)
Aber irgendwie konnte ich die Art nicht unkommentiert lassen.

Zitat:

@Robert_G
Ja, Du hast recht ... aber wenn static nicht für singletons verwendet werden, sind es doch einfach nur einfache globale Variablen. Sowas ist manchmal auch einfacher zu handhaben, als überall eine Referenz "durchzureichen".

Schönen Abend.
Niels

[Delphi_Fanatic]

Zitat:

Er hat eigentlich nur umschrieben, dass das Gebot zur Wirtschaftlichkeit über jede Diskussion hier erhaben ist.

Und den Hinweis auf die Wirtschaftlichkeit finde ich auch absolut korrekt.

In dem Zusammenhang kann ich es mir auch nicht verkneifen, dass mir aufgefallen ist, dass es tendenziell eher jüngere Diskussions-Teilnehmer waren, die hier in diesem Thread die OOP-Geschichten den globalen Variablen vorgezogen haben.

Woran das wohl liegen mag ?

Eine "modernere" Ausbildung ?

Oder vielleicht einfach nur weniger Erfahrung, so wie roderich es hier wohl andeuten wollte :

Zitat:

ob sie überhaupt schon mal ein Produkt oder Projekt in Händen hatten, welches 20 Menschen über 10 Jahre ernährt hat und dies auch weiterhin tun soll.

[Hansa]

Zitat:

Zitat von Delphi_Fanatic

Wie "qualitativ hochwertig" und leicht pflegbar ein Quelltext ist - das hängt viel mehr von der allgemeinen Anwendungsarchitektur ab und vor allem auch davon , ob und welche Programmier-Standards- und Richtlinien man vorher festgelegt hat

Ohne das gehts wohl auch kaum. Du bist nur noch viel zu kurz gesprungen, es gibt nämlich noch ganz andere Sachen, als diese mittlerweile lächerliche Diskussion über "globale" Variablen. :twisted: Ohne eine eindeutige Nomenklatur geht nämlich gar nichts im Team. Und das geht noch alles sehr viel weiter : Beispiel Interbase : Was ist mit Bool-Typen ? Soll dafür eine Domain gemacht werden oder besser nicht ? Soll man da 1 und 0 verwenden oder T und F ? Letztens war doch was zu lesen mit true : "ist in Liste" und false : "noch nicht erfaßt". Und das für ein boolsches Datenbank-Feld. :zwinker: Soll man ein Smallint nehmen oder ein Char (1) oder sonstwas? Also Leute ! Bleibt auf dem Teppich. Da helfen weder Singletons noch sonstwas. Brauche ich eine Variable überall, dann denke ich mir einen guten Namen, sinnvolles Prefix usw. aus und benutze die eben. Das muß dann natürlich auch jedem Beteiligten mitgeteilt werden. Kapiert der das nicht, dann wird eine eigene Klasse das Wissensdefizität höchstens später aufdecken und die Fehler werden an anderer Stelle gemacht.

Das hier war fast klar :

Zitat:

Zitat von Robert_G

...Wo kommt man denn hin, wenn Entwickler A einfach so eine globale Variable einführt, weil er zu faul oder zu unfähig ist um es richtig zu machen, auf die ICH nun überall achten muss, weil es eben keinen Kompilierfehler/Laufzeit fehler gibt, wenn ich in einer dummen Situation darauf zugreife.

Wie kann so eine dumme Situation denn überhaupt entstehen ? Selbst eigene Klassen werden da nicht helfen. Ob du jetzt auf die eigenen komplizierten Klassen achten mußt oder auf eine Variable, das dürfte wohl egal sein. Dein Chef wird aber wissen, daß es viel mehr Arbeit macht eine Klasse zu entferfen, anstatt ein simple Variable an der bestmöglichen Stelle zu deklarieren und natürlich auch zu initialisieren. 8) Aber eben nur dann, wenn alles andere zu aufwändig ist !!!

[Delphi_Fanatic]

Zitat:

Zitat:

Delphi_Fanatic hat folgendes geschrieben:
Wie "qualitativ hochwertig" und leicht pflegbar ein Quelltext ist - das hängt viel mehr von der allgemeinen Anwendungsarchitektur ab und vor allem auch davon , ob und welche Programmier-Standards- und Richtlinien man vorher festgelegt hat

Ohne das gehts wohl auch kaum. Du bist nur noch viel zu kurz gesprungen, es gibt nämlich noch ganz andere Sachen, als diese mittlerweile lächerliche Diskussion über "globale" Variablen. Ohne eine eindeutige Nomenklatur geht nämlich gar nichts im Team. Und das geht noch alles sehr viel weiter :

Ja, ist ja gut, Hansa, ich hab' nur einige Möglichkeiten aufgezählt, die die Qualität des Quelltextes erhöhen. Ich habe nicht gesagt, dass das schon alles ist.
Man muss mit diesen Standardisierungen und Richtlinien aber auch immer einen "goldenen Mittelweg" finden und sollte nicht bis in den letzten Winkel eines Programmes jede kleine Belanglosigkeit irgendwelchen Standards unterwerfen.
Beispielsweise kannte ich schon mal ein Team, bei dem man erstmal eine etliche hundert Seiten dicke Dokumentation durchlesen musste, in der alle Standards, Richtlinien und Nomenklaturen dokumentiert sind, ehe man dort überhaupt nur eine einzige Zeile Code programmieren kann.
Teams, die das tun, sind dann oftmals schon mehr damit beschäftigt, sich selbst zu verwalten als was Brauchbares zu programmieren. Und der Kunde bekommt dann für selbst noch so kleine Änderungen / Erweiterungen wahnwitzige Aufwandsschätzungen von zig Mann-Tagen präsentiert. Solange, bis der Kunde sich eine andere Software-Firma sucht, und das erste Team mit samt seinen Nomenklaturen, Standards und sonstigem Wichtigtuer-Spielkram beim Arbeitsamt landet. Dumm gelaufen.

[Phoenix]

Zitat:

Zitat von Delphi_Fanatic

Beispielsweise kannte ich schon mal ein Team, bei dem man erstmal eine etliche hundert Seiten dicke Dokumentation durchlesen musste, in der alle Standards, Richtlinien und Nomenklaturen dokumentiert sind, ehe man dort überhaupt nur eine einzige Zeile Code programmieren kann.
Teams, die das tun, sind dann oftmals schon mehr damit beschäftigt, sich selbst zu verwalten als was Brauchbares zu programmieren. Und der Kunde bekommt dann für selbst noch so kleine Änderungen / Erweiterungen wahnwitzige Aufwandsschätzungen von zig Mann-Tagen präsentiert. Solange, bis der Kunde sich eine andere Software-Firma sucht, und das erste Team mit samt seinen Nomenklaturen, Standards und sonstigem Wichtigtuer-Spielkram beim Arbeitsamt landet. Dumm gelaufen.

Oder bis andere Firmen, die dieses System nicht einsetzen genaus aus diesem Grunde z.B. Regierungsaufträge nicht erhalten, weil Sie bei der Ausschreibung erst gar nicht berücksichtigt werden.

Ich habe - bevor ich mir gedacht habe ein Diplom würde sich recht gut machen - bei einer Firma gearbeitet die Software für Krankenhäuser entwickelt. Fakt ist: Man bekommt keine Aufträge wenn man nicht garantieren kann das die Software strukturiert und gemäß eindeutig festgelegter Richtlinien entwickelt wird. - Es könnten hier nämlich unter Umständen Menschenleben davon abhängen ob ein Bug in der Software ist oder nicht.

Es gibt also durchaus Bereiche, in denen eben diese von Dir 'angeprangerte' Verhalten die wirtschaftlich einzige Sinnvolle Lösung ist, weil die Kunden eben abspringen würden würde man dieses organisierte Verhalten ändern.

Genauso ist es mit dem OOP-Konzept. Robert hat das richtig erkannt: OOP wurde vielleicht erfunden, weil es jemandem ungeheuer cool vorkam. Es hat sich aber offensichtlich nur deshalb durchgesetzt, weil es den Entwicklern die OOP einsetzen einen (wirtschaftlichen) Vorteil gegenüber denen eingeräumt hat, die es nicht tun. Andernfalls wäre OOP schon eine Totgeburt gewesen, denn einen Nachteil verzeiht die Wirtschaft nicht.

Andersrum: Ein Konzept zu verwenden, das sich in den letzten Jahren bereits als Nachteilig gegenüber einemn anderen Konzept herausgestellt hat kann sich letzten Endes nur Nachteilig auf die Wirtschaftlichkeit des Projektes auswirken.

Irgendwann wird der Zeitpunkt kommen, an dem die erwähnten 10 Jahre alten Programme abgelöst werden müssen. (Beispiel: .NET setzt sich durch, alles was nicht .NET ist wird nicht mehr lauffähig sein). Es wird dann aber mit grossem Aufwand verbunden sein, alten prozeduralen Code weiterzuverwenden bzw. zu portieren. Wahrscheinlich wäre man schneller, wenn man alles neu schreibt. Verwendet aber bereits heute für neue Module bereits reines OOP kann man zumindest diesen Code (bzw. diese Klassen) grösstenteils auch später noch weiter verwenden. Und wieder die Frage: Was ist hier wohl wirtschaftlicher?


Auch den UML-Hype kann ich aus diesem Grunde nicht verstehen. Es zeigt sich immer mehr, das UML einfach nicht das Leistet was sich viele davon versprochen haben. Wer heute bei einem neuen Projekt noch auf UML setzt wird einen Nachteil gegenüber denen haben, die sich den Stress sparen und auf Methoden setzen, die durchgängiger und flexibler sind. UML wird in Zukunft immer unwichtiger werden, bis es irgendwann einmal in den Schulbüchern steht wie jetzt SA: Es war einmal...

[kalmi01]

Hallo Phoenix,

Zitat:

Genauso ist es mit dem OOP-Konzept. Robert hat das richtig erkannt: OOP wurde vielleicht erfunden, weil es jemandem ungeheuer cool vorkam. Es hat sich aber offensichtlich nur deshalb durchgesetzt, weil es den Entwicklern die OOP einsetzen einen (wirtschaftlichen) Vorteil gegenüber denen eingeräumt hat, die es nicht tun. Andernfalls wäre OOP schon eine Totgeburt gewesen, denn einen Nachteil verzeiht die Wirtschaft nicht.

Und was ist mit MS-Windows ?
Wurde da nicht der Standard nur des standardisierens Willen zum Standard ?
Nur weil's lebt, muß es nicht das Beste sein.

Doch nun zum Ursprungs-Thread:
Globale Variablen und GOTO's können sehr nützliche Werkzeuge sein, wenn man sie richtig einsetzt, genau wie OOP.
Wer Stifte (kleine Nägel) mit dem Vorschlaghammer in die Wand haut, oder 12"-Nägel mit nem 50g-Hämmerchen in Douglasie, der verwendet halt zur falschen Zeit das falsche Werkzeug.

Ich programmiere seit 15 Jahren in Postscript, welches OOP-Strukturen bieten kann, wenn man es will, aber was mir immer gefehlt hat sind GOTO's.
Das verlassen komplexer Schleifenkunstrukte ist damit einfach eleganter und lesbarer.

Ebenso fehlen mir andererseits in Delphi Funktionen, die ich lieben und schätzen gelernt habe.

Globale Variablen können einem das Leben schon erheblich erleichtern.
Das ist halt wie mit dem Salz in der Suppe: ohne ist sie fad, zuviel Salz und die Suppe ist ungenießbar.

Zitat:

Es wird dann aber mit grossem Aufwand verbunden sein, alten prozeduralen Code weiterzuverwenden bzw. zu portieren.

Wie meinst Du das ?

[MrSpock]

Hallo ihr Diskutierwütigen,

lasst mich einmal folgende zwei Aussagen in den Thread werfen, die für sicherheitskritische Software gelten:

1. Globale Variablen werden eingesetzt. Es gibt kein Verbot globaler Variablen und es ist kein Ausschlusskriterium, um einen Kundenauftrag zu bekommen.

2. OOP wird in der Regel in sicherheitskritischer Software nicht eingesetzt. Ich arbeite in Standardisierungsgremien, in denen wir uns darüber Gedanken machen. Viele der Großen wie Boeing, Lockheed Martin, EADS sind da eher zögerlich.

Also ihr, die ihr OOP als nahezu heilig anpreist, kommt mal von Eurem hohen Ross runter! Ich mag es überhaupt nicht, wenn ein paar Leute hier meinen, die Weisheit mit Löffeln gefressen zu haben, während andere wohl dumm sind, oder was!?

Übrigens, mag ich OOP und setze sie in meinen Projekten ein, aber nicht 100%-ig und auch ich verdiene trotzdem ein paar Kröten damit. :mrgreen:

[Hansa]

Hi MrSpock, das mit den globalen lasse ich mir noch gefallen. Aber eine Nebenfrage : Setzt ihr auch noch GOTOs ein ? :mrgreen: Davon abgesehen : wenn ihr kein OOP einsetzt, dann aber wohl weil es nicht überall geht ? Bin allerdings Deiner Meinung, daß nichts zum Selbstzweck werden darf, wie oben angesprochene Klassenorgien :lol: um eine Variable zu benutzen.

P.S.: inwiefern sind die "Großen" zögerlich ?

[Sharky]

Mir ist es ja egal was, wer, wann benutzt.

Aber es gibt keinen Grund so zu tun als wäre hier einer der bessere Programmierer als der Andere nur weil der eine diese oder andere Methode benutzt!
Jeder der das nicht versteht sollte lieber für sich alleine arbeiten!

Es gibt, wie in vielen Dingen des Lebens, ein "Für und Wieder". Darüber kann man sicher auch diskutieren.
Aber sich hier so aufzuführen ist doch wirklich so wie im Kindergarten. :roll:

Also holt doch einfach mal tief Luft, denkt nach, denkt noch einmal nach, und dann schreibt wieder etwas zu dem Thema.