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