lokale Variablen mit globaler Lebensdauer?

Zitat von negaH:

Betrachtet man das mal aus dieser Sichtweise so erscheinen viele Aussagen in diesem Thread einfach lächerlich.

Boom! Autsch... getroffen...

Zitat von negaH:

Eben weil man die heutige Technologie nicht als Indiz zur Beweisführung eines guten Programmierstils heranziehen darf.

Ich hoffe das ging nicht einschließlich gegen mich...
Meine Einwände gegen typ. Konstanten hatte ich IMHO begründet. Den Singleton stub hatte ich nur auf Dizzys Post geantwortet, da ich ihn a)falsch verstanden hatte und b) dachte es könnte vielleicht helfen.

Der OOP-Krieg wurde wohl erst losgetreten als jemand das Wort class darin entdeckt und sofort losgeschossen hat...

So... nun lese ich mal die neueren Antworten...

@Hagen:

na dann ist es okay ... hatte mich halt gewundert. Sorry, wenn's beim ersten Mal nicht exakt genug rüberkam.

*sich-die-2-Cent-von-Nico-einsteck*
Wenn ich das bei allen mache, die ihre 2 Cent irgendwo hinterlassen, bin ich bald reicher als Bill Gates. Ich mach mich mit Google erstmal auf die Suche nach weiteren Cents. Zur Not nehme ich auch US-Cent

**GuenterS**

Zitat von malo:

Zitat von Sprint:

Zitat von malo:

Auch, wenn es manchmal ach so leicht ist, eine Klasse zu erstellen und alles was dazu passt in dieser Klasse auszulagern, macht so etwas manchmal einfach zu viel Arbeit (besonders für Leute wie mich, die keine Pro-Versionen besitze/nutze

Das spielt doch gar keine Rolle, ob du 'ne Standard/Personal, Professional, CS/Enterprise oder 'ne Architect hast.

Doch, wenn es um OOP-Programmierung geht. Methoden deklarieren etc, funktioniert in Pro/Ent/Arc-Versionen bedeutend einfacher und schneller, Stichwort: Code-Completion mit Strg+Shift+C. Dieses Feature wird in PE-versionen nicht unterstützt und erleichtert in Pro/Ent/Arc-Versionen die OOP-Programmierung bedeutend.

Zitat von Luckie:

Faulheit oder Bequemlichkeit ist für mich keine Ausrede nicht sauber zu programmieren, sei es jetzt OOP oder nicht.

Das ist es auch nicht. Allerdings wollte ich damit ausdrücken, dass manches, was man mit der OOP macht, einfach overkill ist (besonders wenn man PE-Versionen benutzt), da man da einige Zeit an Tipparbeit verliert, die genausogut für wichtigere Dinge genutzt werden kann. Das ist imho einer der Nachteile an OOP."Sauber" Programmieren ist natürlich immer wichtig, aber der Weg dorthin spielt auch eine wichtige Rolle. Man kann sich stundenlang hinsetzen und ein ausgeklügeltes OOP-Konzept entwickeln, man kann aber auch procedural arbeiten und nur das in Klassen schreiben, was dort wirklich besser aufgehoben ist (zum Beispiel, wenn dabei Vererbung einem hilfreich zur Seite stehen könnte). Und solange man nachher noch durch das ganze durchsteigt, kann man imho arbeiten wie mal will/kann/es für richtig hält

//edit: Sorry, wenn das hier auch OT ist... da hab ich beim posten nicht drauf geachtet

Wer behauptet denn, dass man auch alles in Klassen packen muss? Wenn Du alle Deine proceduren und funktionen in eine einzige Klasse packst ist es schon klar, dass Du in OOP keine Vorteile sehen wirst.

Es gibt schon einige (oder viele) schöne Dinge.

Ich stell mir das immer so vor, ich schreibe nicht allein sondern zu zweit, dritt, viert oder zu noch mehr an einem bestimmten Programm. Programmierer B hat mit Proceduren/Funktionen einen bestimmten Ablauf geschaffen. Ok schön. Ich verwend den jetzt schön brav, genauso wie ich seine globalen Variablen verwende. Jetzt geht besagter Programmierer her und stellt fest, hey das könnt ich so viel eleganter lösen und verwendet die Variable plötzlich ganz anders. Nach der Änderung, darf ich dann mal ne Weile grübeln bis ich feststelle, achso, jetzt muss ich die Variable auf dies oder jene Werte setzen, es gibt sie nicht mehr, es hat sich der Typ geändert oder was auch immer. Möglicherweise darf ich deshalb meinen kompletten Code umschreiben.

Hätten sich in diesem Beispiel die Programmierer an OOP gehalten, Sichtbarkeiten von Variablen entsprechend eingeschränkt und sich an eine gegebene Schnittstelle gehalten, die nur noch erweitert werden darf, allerdings so dass sie rückwärtskompatibel ist, hätte ich deswegen keine einzige Zeile meines Codes ändern müssen.

Naja das ist eine Sicht, gibt sicher noch andere.

Ach ja, die PE Versionen sind von Borland ja absichtlich eingeschränkt, wollen ja wohl lieber Architect und wenn nicht die dann die Enterprise oder wenigstens die Professional Version verkaufen. Da läßt man dann schon mal en liebes/nettes Feature weg...

**negaH**

@GuenterS:

Zitat:

Hätten sich in diesem Beispiel die Programmierer an OOP gehalten,

Sichtbarkeiten von Variablen entsprechend eingeschränkt und sich an eine gegebene Schnittstelle gehalten, die nur noch erweitert werden darf, allerdings so dass sie rückwärtskompatibel ist, hätte ich deswegen keine einzige Zeile meines Codes ändern müssen.

Der Anfang des Satzes hat rein garnichts mit dem Ende des Satzes zu tun. Wer sagt das die OOP alleinig dafür verantwortlich ist das man
- die Sichtbarkeit der Variablen beschränken kann ?
- eine Schnittstelle immer OOP sein muß ?

Umgekehrt wird ein Schuh draus: Man hat in der Geschichte der Programmiersprachen herausgefunden das das Black-Box Prinzip zu
- definiterten Schnittstellen führt
- modular programmiert werden muß
- die Sichtbarkeit von Typen, Variablen und Objekten eingeschränkt werden muß

Ergo stellt es sich exakt andersherum dar, durch das Nachdenken über bessere Schnittstellen, stärkere Restriktionen in der Sichtbarkeit von Variablen ist erst die OOP entstanden.

@NicoDE: da stimme ich dir zu, das man solche "schlechten Eigenarten" nicht als den zu bevorzugenden Weg propagieren sollte. Denoch sollte jeder Entwickler über alle Möglichkeiten seiner Werkzeuge bescheid wissen, und eben nicht nur über OOP alleine. Und schlußendlich haben solche Infos, Methoden und Werkzeuge trotzdem nichts mit einem guten Programmierstil zu tun.

Gruß hagen

**sniper_w**

Zitat:

Hätten sich in diesem Beispiel die Programmierer an OOP gehalten, Sichtbarkeiten von Variablen entsprechend eingeschränkt und sich an eine gegebene Schnittstelle gehalten, die nur noch erweitert werden darf, allerdings so dass sie rückwärtskompatibel ist, hätte ich deswegen keine einzige Zeile meines Codes ändern müssen.

Eine Möglichkeit. Andere über dll-s. Und da kann jeder nach seinem Stil programmieren, auch ganz ohne OOP, solange man sich an eine gegeben Schnittstelle hält.

EDIT:
negaH war schneller.

**Hansa**

Einfach köstlich, diese Glaubenskriege !

IMHO ist es so, daß es nur die gesunde Mischung macht. Man muß sich schon überlegen wozu man was braucht. negaH denkt wohl in dieselbe Richtung. Natürlich verwende ich globale Variablen, aber genau dosiert und möglichst wenig ! Und OOP ist die Würze. Ich erfinde das Rad nämlich nur einmal. Und unterschätzen würde ich das Ganze nicht. Um OOP sinnvoll nutzen zu können, gehört auch ein gehöriges Maß an Disziplin. Schließlich vererben sich auch die Fehler ! Trotzdem wären meine Programme ohne OOP schlechter zu warten. Das Ganze ist nämlich nur gut, sofern die Hierarchie der Objekte gut durchdacht ist.

**GuenterS**

Zitat von negaH:

@GuenterS:

Zitat:

Hätten sich in diesem Beispiel die Programmierer an OOP gehalten,

Sichtbarkeiten von Variablen entsprechend eingeschränkt und sich an eine gegebene Schnittstelle gehalten, die nur noch erweitert werden darf, allerdings so dass sie rückwärtskompatibel ist, hätte ich deswegen keine einzige Zeile meines Codes ändern müssen.

Der Anfang des Satzes hat rein garnichts mit dem Ende des Satzes zu tun. Wer sagt das die OOP alleinig dafür verantwortlich ist das man
- die Sichtbarkeit der Variablen beschränken kann ?
- eine Schnittstelle immer OOP sein muß ?

Gruß hagen

Ich weiß nicht wer das sagt, dass OOP alleinig für die Sichtbarkeit von Variablen verantwortlich ist und Schnittstellen immer OOP sein muss?

Wenn Du mein vorheriges Posting bis zum Ende liest, wirst Du sehen, dass ich schon auch geschrieben habe, dass es sicher auch andere Sichten (Möglichkeiten) gibt.

Mir _persönlich_ gefällt die Idee von OOP sehr gut.

**Sidorion**

Was haltet Ihr denn von diesem Konstrukt?:

zusammenfalten · markieren

Delphi-Quellcode:

			Unit Foo;

Interface

Function Foo(_someParameters): ResultType;

Implementation

Var

  Bar: Integer=0; //hier die GloKale Variable

Function Foo(_someParameters): ResultType;

Begin

  Inc(Bar);  //hier der Zugriff drauf

  DoSomething;

End;

End.

ausser diesem Zeug kommt NICHTS in die Unit und schon hasst Du eine Globale Variable, die nur der Funktion bekannt ist, ohne mit Compilerschaltern rumzufummeln. Und in diesem Fall ist wurscht, ob OOP oder nicht von ausserhalb der Unit sieht man nur die Funktion, nicht die Variable.
Abgesehen davon kann man auch einen Kommentar Marke !!!!Do Not use this Variable it's for Function Foo!!! an die Variable dranschreiben. Dann sollten sich eigentlich alle dran halten und wenn nicht, ist klar, wer schuld ist.

**Hansa**

Zitat von Sidorion:

...und wenn nicht, ist klar, wer schuld ist.

Und wem nützt das dann was ?

Was Du meinst, das ist eine Unit-globale Variable. Aber wie gesagt, es kommt auf den Einsatzzweck an und ich bleibe dabei : die Sichtbarkeit möglichst gering zu halten. 8) Das verhindert unerwünschte Quereffekte.

**sniper_w**

Zitat:

ausser diesem Zeug kommt NICHTS in die Unit und schon hasst Du eine Globale Variable, die nur der Funktion bekannt ist, ohne mit Compilerschaltern rumzufummeln.

Auf ein Ergebniss einer Funktion zu warten ist immer langsamer als auf eine einzige Variable zuzugreifen.