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

[Delphi_Fanatic]

( @ Robert_G : Ich hab' ja die "Vorzüge" von OOP gar nicht in Frage gestellt, nur ist es aus meiner Sicht trotzdem Unsinn,
jegliche Verwendung globaler Variablen grundsätzlich auszuschliessen. Es ist keine "Programmierer-Todsünde", so wie
z.B. die Verwendung von "Goto's".

und vor allem ist es Unsinn wg. irgendetwas Objekte anzulegen mit der Absicht, so ein "versehenliches" oder "zufälliges"
Überschreiben von Variablen zu verhindern.
Das es andere sinnvolle Gründe für Objekte geben kann und gibt - das steht natürlich außer Frage. )

[Luckie]

Warum sind jetzt GOTOs eine Todsünde? Sinnvoll eigesetzt können sie durchaus sinnvoll sein. Ein exit oder ein break ist ja im Endeffekt auch nichts anderes.

[Robert_G]

Zitat:

Zitat von Luckie

Warum sind jetzt GOTOs eine Todsünde? Sinnvoll eigesetzt können sie durchaus sinnvoll sein. Ein exit oder ein break ist ja im Endeffekt auch nichts anderes.

Exakt, sinnvolle GOTOs können Code lesbarer machen. Ist äußerst selten, aber auch Luckie wird ab & zu GOTOs verwenden. Genau wie ich es auch machen würde. Aber halt nur innerhalb einer Methode, und dort nur um nicht 1.000 Zeilen AQbruchsbedingeungen in eine Schleife zu knallen.
break ist nunmal auch nur ein implizites GOTO, es springt an die erste Zeile nach der Schleife. ;)

[Delphi_Fanatic]

Zitat:

Warum sind jetzt GOTOs eine Todsünde? Sinnvoll eigesetzt können sie durchaus sinnvoll sein

Das überrascht mich jetzt, Luckie. :gruebel:

Von jemandem, der einerseits die Dinge so "eng" zu sehen scheint (globale Variablen vs. Objekte) hätte ich
jetzt so eine Einstellung bei Goto's nicht erwartet.
Tja, so hat halt jeder seine Meinung ... :???: Ich meine mich erinnern zu können, dass wir über Goto's in
der DP schon mal diskutiert hätten.

[Luckie]

Ich habe mich auch nicht strikt gegen globale Variablen ausgesprochen. Und in der letzten Diskussion über GOTOs sind wir auch zu dem Schluss gekommen, dass sie sinnvoll eingesetzt eine Daseinsberechtigung haben.

[SubData]

Zitat:

Zitat von Robert_G

Zitat:

Zitat von SubData

Hab nämlich irgendwie keine Lust für gerade mal 2 Nur-Lesen Variablen auch noch Klasse anzulegen ...

Hmm... Schonmal von Vererbung und Polymorphy gehört? :gruebel:
Damit kann man nämlich prima Dinge wiederverwenden ohne sie immer wieder neuerfinden zu müssen.

Ich hättte keinen Bock überall den Zustand dieser Variable zu prüfen. Ich müsste es aber machen, da Ich in gewisser Weise defensiv, und somit fehlervorbeugend, programmieren muss.

Muss ich nicht...
Die beiden Variablen werden nur einmal eingelesen und bleiben so erhalten... im ganzen Projekt...
Sie speichern nur einen Pfadnamen der sich zur kompletten Laufzeit NIEMALS ändert.
Dieser Pfadname wird auch nicht wieder zurück in irgend ne Datei geschrieben oder sonstwas...

Ich würds ja mit ner Konstante machen, aber der Pfad ist auf jedem Rechner evtl. anders :mrgreen:

[Delphi_Fanatic]

Zitat:

Und in der letzten Diskussion über GOTOs sind wir auch zu dem Schluss gekommen, dass sie sinnvoll eingesetzt eine Daseinsberechtigung haben.

Du meinst wohl, DU bist zu diesem Schluss gekommen ... ? :zwinker:

Mal eine ganz andere Frage an die "Fraktion" der Gegener von globalen Variablen :
Was ist denn mit den haus-eigenen globalen Variablen von Delphi selbst ?

Nehmt einfach mal "DateSeparator" !

Berechtigt, oder nicht berechtigt ? :roll:

[alcaeus]

Zitat:

Zitat von Delphi_Fanatic

Was ist denn mit den haus-eigenen globalen Variablen von Delphi selbst ?

Nehmt einfach mal "DateSeparator" !

Berechtigt, oder nicht berechtigt ? :roll:

IMO: Nicht berechtigt. Warum? Weil sowas in eine Date-Klasse, oder vielleicht ein SystemProperties gehoert. Zusammen mit DecimalSeparator, PathDelimiter etc. wuerde das eine schoene Sammlung von Optionen geben ;)

Greetz
alcaeus

[Alfons_G]

Man kann zusammenfassend vielleicht sagen, dass es zahlreiche Fälle gibt, wo globale Variablen keinen Schaden anrichten (Disziplin vorausgesetzt), wo man sie aber dennoch durch OOP-Konstrukte ersetzen kann. Ob man sogar die Formularvariablen verbannt, ist vermutlich eine Glaubensfrage. Solange man (vernünftigerweise) in den Formular-Units keine Business-Logik unterbringt, ist das m.E. ohne Auswirkungen auf die Fehleranfälligkeit.
Deshalb sollte man als Ersatz für globale Variablen auch nicht unbedingt Felder im Hauptformular verwenden. Besser ist da eine separate Klasse (oder mehrere logisch aufgeteilte Klassen) mit Business-Regeln, Standardwerten usw. Diese Klasse kann man dann beim Anwendungsstart initialisieren. Damit erleichtert man sich auch die Wiederverwendung, falls man dieselben Werte in einer anderen Anwendung wieder benötigen sollte.

Mit der Begründung "ist ja nur ein kleines Tool" wäre ich vorsichtig ;). Ich habe schon erlebt, dass ein 150-Zeilen-Hilfsprogramm zum Durchführen eines Datenabgleichs plötzlich innerhalb von 18 Monaten zu einer spezialisierten Data-Mining-Anwendung mit einigen Tausend Programmzeilen mutiert ist. Da ist man dann heilfroh, wenn man von Anfang an das Programm sorgfältig aufgebaut hat.
Nur hat man leider oft in der Praxis mit Alt-Quellcode zu tun, bei dem man froh ist, wenn er überhaupt irgendwie strukturiert wurde. Entweder ist da von OOP keine Spur, oder ein Genie hat alle Felder und Methoden einer Klasse als public deklariert und somit auf fast alle Vorteile der Objektorientierung verzichtet.
Für sowas schreibe ich nach Möglichkeit eine Schnittstelle (als Klasse), welche diese Units einbindet und alle Aufrufe kapselt. Dann kann ich den Alt-Code als Black Box behandeln.

Wir erstellen vorrangig Web-Anwendungen, wo man immer davon ausgehen muß, dass von jeder Ressource mehr als eine Instanz benötigt wird. Dazu arbeiten wir zum Teil mit vertraulichen Kundendaten, die auch zu Testzwecken nicht vom Original-Server gezogen werden dürfen und die sich aufgrund ihrer Komplexität auch nicht mit vertretbarem Aufwand simulieren lassen. Da ist es erforderlich, dass ein Tel der Tests dann in der Produktiv-Umgebung vorgenommen wird. Das geht natürlich nur, wenn man vorher bei kritischen Programmteilen genau weiß, wie sie sich verhalten werden. Deshalb ist es bei uns lebenswichtig, dass der Quelltext erstens sauber lesbar ist und zweitens so strukturiert, dass man ohne Probleme Unit-Tests durchführen kann.

Auch wenn öfters mal die Zeit nicht ausreicht, die Sourcen so zu kommentieren, wie ich es gerne hätte - meine Programme sind jedenfalls auch noch nach mehreren Jahren für alle beteiligten Kollegen nachvollziehbar :).

:coder:

[roderich]

Es ist mir echt schleierhaft, wie man dermaßen viel Zeit mit dieser Diskussion verbringen kann. :?

Geht es beim Software-Entwickeln darum, ein gerade "modernes" Konzept zu befriedigen ??
Oder darum, heute und morgen damit sein Geld zu verdienen, sprich effektiv und transparent zu entwickeln ??

Ich meine doch letzteres. Und diese Ziele kann man mit Konzepten aus den 70er Jahren des letzten Jahrtausends ebenso erreichen wie mit denen aus den 0er Jahren des aktuellen Jahrtausends. Wer etwas anderes behauptet, verkauft Leute wie Wirth für dumm. Ich frage mich, was manche Beiträger zu dieser Diskussion eigentlich beruflich (??) machen, 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. Unsere Kunden fragen mich nicht, ob wir XML, public properties, GOTO's oder globale Variablen verwenden. Sie wollen ein stabiles und mächtiges System.

In zehn Jahren wird keiner mehr von denen, die heute ausschließlich darauf schwören, OOP programmieren (dann gibt es nach .NET eh das noch neuere hyperintelligentschnickschnack.NET von Microsoft, was noch viiiiel besser ist). Leider wieder nur für Spielkinder geeignet, die Zeit zum verplempern haben.

Wer nicht das einsetzt, was bestmöglich den Zweck erfüllt, landet im Arbeitsamt.


Roderich

[Luckie]

Zitat:

Zitat von roderich

In zehn Jahren wird keiner mehr von denen, die heute ausschließlich darauf schwören, OOP programmieren (dann gibt es nach .NET eh das noch neuere hyperintelligentschnickschnack.NET von Microsoft, was noch viiiiel besser ist). Leider wieder nur für Spielkinder geeignet, die Zeit zum verplempern haben.

Du vergleichst Äpfel mit Birnen. .NET ist ein Framework und OOP ein Programmierkonzept. Desweiteren verkörper .NET OOP in Perfektion. Somit verliert deine Aussage jeglichen Sinn, wenn sie sich nicht sogar selbst widerspricht. ;)

[Speedmaster]

Zitat:

Zitat von Luckie

Zitat:

Zitat von roderich

In zehn Jahren wird keiner mehr von denen, die heute ausschließlich darauf schwören, OOP programmieren (dann gibt es nach .NET eh das noch neuere hyperintelligentschnickschnack.NET von Microsoft, was noch viiiiel besser ist). Leider wieder nur für Spielkinder geeignet, die Zeit zum verplempern haben.

Du vergleichst Äpfel mit Birnen. .NET ist ein Framework und OOP ein Programmierkonzept. Desweiteren verkörper .NET OOP in Perfektion. Somit verliert deine Aussage jeglichen Sinn, wenn sie sich nicht sogar selbst widerspricht. ;)

.net schließt aber Globale Variablen nicht aus!

[Robert_G]

Zitat:

Zitat von roderich

Wer nicht das einsetzt, was bestmöglich den Zweck erfüllt, landet im Arbeitsamt.

Genau das habe ich mir absichtlic verkniffen. ;) Design paattern und OOP sind nicht erfunden worden weil sie cool sind.
OK, die meisten Patterns sind schon sau cool. ;) Aber der eigentliche Zweck ist etwas möglichst transparent, simpel, wiederverwendbar, fehlerresistent zu machen.

Und ja, ich arbeite noch nicht lange in dem Geschäft, aber auch ich habe mittlerweile ein paar Jährchen Erfahrung. ;)
Und du kannst mir glauben, nur mit Grauen & Abscheu denke ich an meine ersten Monate zurück.

Wer sich OOP Prinzipien, Denkweisen und generelle Herangehensweisen nicht verinnerlicht bzw. akzeptiert hat, mag es für ungeheuer ineffektiv halten.
Ich halte mit viel weniger Bugs und damit auch viel schnelleren Entwicklungszyklen dagegen. ;)

[roderich]

@Luckie:
echt ?? OOP und .NET ist nicht dasselbe ???

@Robert_G:
in der Zeit, in der Du dich in einem einzigen Thread hier im Forum ergießt, habe ich genug Geld mit SW-Entwicklung (objektorientiert, prozedural und/oder mit globalen Variablen) verdient, um damit mit meinen Steuergeldern zehn offensichtlich gelangweilten Menschen zu ermöglichen, den ganzen Tag in einem Delphi-Forum erbittert über veraltete SW-Konzepte herzuziehen.


Roderich

[Muetze1]

Moin!

Zitat:

Zitat von roderich

@Robert_G:
in der Zeit, in der Du dich in einem einzigen Thread hier im Forum ergießt, habe ich genug Geld mit SW-Entwicklung (objektorientiert, prozedural und/oder mit globalen Variablen) verdient, um damit mit meinen Steuergeldern zehn offensichtlich gelangweilten Menschen zu ermöglichen, den ganzen Tag in einem Delphi-Forum erbittert über veraltete SW-Konzepte herzuziehen.

Auch wenn ich den Thread hier nicht hauptberuflich verfolge, so ist es doch sehr auffällig, dass du des öfteren auf dein "dickes Gehalt" verweist - schön und gut - bekommen manche anderen hier auch, aber machen trotzdem nicht so einen Wind drum.
Und gegen eine sachliche Diskussion ist doch nix einzuwenden, so lange es nicht einige immer wieder auf ihr Portmonaie beziehen müssen, welches sich auch unter Nutzung globaler Variablen und vielen nicht OOP Elementen verdienen lässt.

Also bitte mehr zum Thema und weniger zu deinem Gehalt - das interessiert nicht die Bohne.

MfG
Muetze1

[marabu]

Zitat:

Zitat von Robert_G

Und du kannst mir glauben, nur mit Grauen & Abscheu denke ich an meine ersten Monate zurück.

Ich kann dir versichern, du wirst später mit Entsetzen an deine ersten Jahre zurück denken und die Absolutpositionen, die du vertrittst. Noch später wirst du allerdings lächeln, solltest du jemals deine Beiträge von heute in einem Archiv wieder entdecken. Glaube mir, ich weiß es - ich bin schon bei noch später.

@Muetze1: Ich glaube nicht, dass roderich in seinem Beitrag mit seinem Gehaltszettel gewunken hat. Er hat eigentlich nur umschrieben, dass das Gebot zur Wirtschaftlichkeit über jede Diskussion hier erhaben ist.

@roderich: Heute ist nicht dein Tag - du lässt dich so leicht provozieren.

marabu

[Luckie]

Zitat:

Zitat von roderich

@Luckie:
echt ?? OOP und .NET ist nicht dasselbe ???

PKW und Ottomotor sind ja auch nicht das selbe oder?

[Robert_G]

Zitat:

Zitat von Speedmaster

Zitat:

Zitat von Luckie

Zitat:

Zitat von roderich

In zehn Jahren wird keiner mehr von denen, die heute ausschließlich darauf schwören, OOP programmieren (dann gibt es nach .NET eh das noch neuere hyperintelligentschnickschnack.NET von Microsoft, was noch viiiiel besser ist). Leider wieder nur für Spielkinder geeignet, die Zeit zum verplempern haben.

Du vergleichst Äpfel mit Birnen. .NET ist ein Framework und OOP ein Programmierkonzept. Desweiteren verkörper .NET OOP in Perfektion. Somit verliert deine Aussage jeglichen Sinn, wenn sie sich nicht sogar selbst widerspricht. ;)

.net schließt aber Globale Variablen nicht aus!

Ich persönlich kenne nur eine .Net Sprache, die das ermöglicht. Und die verwende ich nicht nur aus dem Grund nicht. ;)
Für 99.99% aller .Net Entwickler kann man also davon ausgehen, dass es keine globalen Variablen mehr gibt.
Du darfst nicht vergessen, globale Variablen und funktionen werden in D.Net an eine implizite Klasse gehängt, die es zu jeder Unit hinzufügt...
Chrome könnte es zwar theoretisch auch, aber der Compiler switch ist standardmäßig aus und wird in den nächsten Versionen verschwinden. Deshlab echne ich es hier mal nicht dazu. ;)

[nieurig]

Hallo Leute,
eine interessante Diskussion.

Robert_G schrieb:

Zitat:

Ich persönlich kenne nur eine .Net Sprache, die das ermöglicht. Und die verwende ich nicht nur aus dem Grund nicht.

Ich denke, dass das static Attribut (vor Variablen) in .NET aber auch Java usw. genau zur Schaffung von globalen Variablen verwendet werden soll/kann.


Ergo: Die Designer der Sprache(n) waren sich offenbar auch nicht einige ob es nicht doch Fälle gibt in denen globale Variablen oder GOTO einfach eine "einfache" Lösung sind und haben die Möglichkeit sie zu nutzen eingebaut (wer sie denn nutzen will - ich vermeide sie aus den genannten Gründen).

Schönen Abend noch.
Niels

@rodrich
Alle und hier meine ich wirklich ALLE aktuellen Programmiersprachen arbeiten objektorientiert. Dafür gibt es eine Reihe guter Gründe.

<edit> unsachliche Kommentar entfernt. Niels </edit>

[Robert_G]

statische Member sind aber kein Widerspruch zu irgendeinem OOP Konzept. ;)
Man kann sie private/protected/internal deklarieren und dadurch erst konsistent Singletons & Co schaffen. :)
Außerdem sind sie thread safe...

[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.

[new4toms]

Liebe DPler,

ich habe diesen Thread angezettelt, da ich ein recht umfangreiches Projekt betreue - mit globalen Variablen (und sogar GOTOs).

Die (noch nicht nachgezählt, dürften aber so rund 400 sein) sind jedoch in(zwischen/seit langem) in einer eigenen Unit "ausgelagert" und tragen Namen, die nicht gerade so aussehen:

i:=Integer;

sondern eher so:

iGthisM_id_42.

i steht für Integer, G für Global, thisM_id_42 für den Datensatz.

Was mich nach wie vor - an den "Global-Gegnern" irritiert:

Wie macht Ihr denn die Einstellung für ein Programm, das mehr als 150 Optionen - verteilt auf ca. 25 Forms anbietet? In jedem Form eine Einstellungsoption? In jedem Objekt ein eigenes "ReadFromIniFile"?

M.M.n. lassen sich größere Anwendungen nur mit globalen Variablen beherrschen. Bestes Beispiel: Die Registry von Windows selbst!

1:0 für die globalen Variablen, oder?

mfg

[alcaeus]

Zitat:

Zitat von new4toms

Wie macht Ihr denn die Einstellung für ein Programm, das mehr als 150 Optionen - verteilt auf ca. 25 Forms anbietet? In jedem Form eine Einstellungsoption? In jedem Objekt ein eigenes "ReadFromIniFile"?

Also ich fuer meinen Teil habe ein Optionsobjekt, in dem alle Optionen gesammelt sind. Dieses Optionsobjekt wird aber als globale Variable zur Verfuegung gestellt, also (IMHO) die ideale Kombination aus globalen Variablen und OOP ;)

Zitat:

Zitat von new4toms

M.M.n. lassen sich größere Anwendungen nur mit globalen Variablen beherrschen. Bestes Beispiel: Die Registry von Windows selbst!

Naja, egal wie man Optionen speichert, und egal wie man sie dann im Programm zur Verfuegung stellt, das sind 2 Paar Schuhe. Im Gegenteil: die Speicherung sollte unabhaengig von der Verwendung im Programm sein. Deshalb verwende ich dafuer auch eine zweite Klasse. So kann ich ohne Probleme von meinem eigenen Format mit cfg-Dateien auf ini-Files oder die Registry umstellen.

Zitat:

Zitat von new4toms

1:0 für die globalen Variablen, oder?

Fuer dich. Andere sehen den Sieg fuer OOP-Konzepte, ich sehe es immer noch als 0:0. Einen eindeutigen Sieger kann und wird es nicht geben. Jeder verwendet das, mit dem er fuer sich besser klarkommt. Fuer dich moegen das Globals sein, fuer andere sind es Objekte. Das muss am Ende jeder fuer sich entscheiden.

Greetz
alcaeus

[Sanchez]

Zitat:

Zitat von new4toms

Wie macht Ihr denn die Einstellung für ein Programm, das mehr als 150 Optionen - verteilt auf ca. 25 Forms anbietet? In jedem Form eine Einstellungsoption? In jedem Objekt ein eigenes "ReadFromIniFile"?

Das klingt für mich nach einem zentralen Einstellungs-Objekt, am besten ein Singleton. Jede Option wird eine Property und es gibt eine Methode zum Lesen und eine zum Schreiben.

Zitat:

Zitat von new4toms

1:0 für die globalen Variablen, oder?

Nö. :mrgreen:

grüße, daniel

[Muetze1]

Moin!

Zitat:

Zitat von MrSpock

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.

Hier sehe ich die Gründe eher darin, das die Systeme in denen diese sicherheitskritische Software umgesetzt wird, kein OOP können bzw. OOP nicht echtzeittauglich ist und daher nicht eingesetzt werden kann. Ich denke da z.B. Matlab/Simulink, wo man nicht alle Elemente des Matlab's einfach so für Echtzeit nutzen kann, da diese nicht dafür tauglich sind.

Auch bei Steuerung wie SPS, wird meistens kein OOP eingesetzt, da es meist über das Ziel hinaus schiesst. Ein komplettes OOP in eine solche SPS zu knallen - da kommt man auf keinen grünen Zweig mehr, da ist man mit einem kleinen nicht-OOP Code besser dran bzw. auch schneller und überschaubarer.

MfG
Muetze1

[runger]

Hallo Sanchez,

das haut dir mein Chef um die Ohren!
Ca 500 Variablen die global sein müssen, weil Sie von 50 Forms benutzt werden!
Dann singleton, property, procedure...
Mein Chef sagt:
Junge du spinnst. Machs einfach, machs mit globalen Variablen.
kostet nur ein zehntel!

Rainer

[Sanchez]

Hallo runger,

Der Unterschied zwischen dem Anlegen einer globalen Variable und einer Property im Singleton ist IMHO minimal. Das ist mir der Vorteil, die Methoden bei den Daten zu haben schon Wert.

grüße, daniel

[runger]

Hallo Sanchez,

bitte gib mir mal ein minimales Codebeispiel damit wir von der gleichen Sache reden.
Für ein Property brauch ich:
-property selber
-Function zum setzen
-Variable selbst

zum Zugriff Zuweisung

für eine globale Variable (alle in der gleichen Unit. Nicht verteilt das wäre katastrophal):
-globale Variable

zum Zugriff Zuweisung

Für die Function brauche ich mindestens 5 Zeilen.

Und was bring das Ganze? Garnichts! Mein Code ist so übersichtlich wie deiner.

Wohlgemerkt: wenn jemand globale Variablen streut bin ich voll deiner Meinung, ansonsten nicht!

Rainer

[Sanchez]

Wenn jede Property mit Funktionen ausgestattet wird, dann wirds natürlich länger. Sofern das nicht nötig ist, lasse ich die Property auf die Variable direkt zugreifen. Wenns nur um Einstellungen geht, dann kann ich auf Setter-Methoden verzichten.

Ein konkretes Beispiel ist eine Klasse, die mir beim Programmstart lokalisierte Strings lädt. Im Programm greifen mehrere Threads beliebig auf diese Strings zu. Da die Properties alle nur Lesbar sind, benötige ich keine Setter- bzw. Getter-Methoden. Andernfalls könnte in denen die Thread-Synchronisation ablaufen.

Delphi-Quellcode:

type
  TMenuMessages = class(TObject)
  private
    FString1: string;
    FString2: string;
    ...
    {1 Lädt die Übersetzungen }
    procedure LoadMessages;
  protected
    constructor Create;
    constructor CreateInstance;
    class function AccessInstance(Request: Integer): TMenuMessages;
  public
    destructor Destroy; override;
    class function Instance: TMenuMessages;
    class procedure ReleaseInstance;
  published
    property String1 : string read FString1;
    property String2 : string read FString2;
    ...
  end;

LoadMessages wird im Konstruktor aufgerufen. Den Klassenrumpf vom Singleton generiert mir dabei der Modelmaker. In Wirklichkeit ist der einzige Vorteil aber, dass ich die Laden-Methode bei den Daten habe.

Eine neue Variable würde in dem Fall eine neue Property und eine Zeile in LoadMessages bedeuten.
Theoretisch könnte ich LoadMessages auch noch automatisieren indem ich von TPersistent ableite und über alle Published-Properties iteriere. Allerdings setze ich in der den Default-Wert und müsste mir dafür noch was überlegen.

Für bessere Lösungen bin ich aber immer offen.

[runger]

Hallo Sanchez,

eins hast du geschafft, du hast mich neugierig gemacht.
Ich werde zumindest über die Art wie ich das Ganze realisiert habe
nachdenken!

Rainer

[Chewie]

Zitat:

Zitat von runger

Für die Function brauche ich mindestens 5 Zeilen.

Und was bring das Ganze? Garnichts!

Nein. Ein einfaches Beispiel ist eine multi-threaded Anwendung (mistiges Denglisch, aber mir fiel grad kein deutsches Wort dafür ein :shock: ), die auf globale Variablen schreibend zugreift. Wenn du das mit einfachen globalen Variablen machst - viel Spaß beim Synchronisieren!
Auch müsstest du bei jedem Schreibzugriff prüfen, ob der Wert erlaubt ist. Da ist eine set-Funktion (oder eben eine Methode) wesentlich einfacher und auch weniger zu schreiben.