Forums Neueste Beiträge
 

Programmierstil - Objektorientierung (Anfängerfrage)

03/03/2011 - 23:20 von Paul Pierot | Report spam
Hallo,
ich habe ein paar Fragen zum Programmieren mit VB6 und im Allgemeinen.
Sachen, wo mir als Laie die Erfahrung des Berufsprogrammierers fehlt.

Inzwischen habe ich etliche Routinen, die ich immer wieder in meinen
Programmen einsetze (Zuletzt-Geöffnet-Historie, Dateien in den
Papierkorb löschen, kleinere GUI-Anpassungen, usw.)

Bislang habe ich diese Routinen eher linear implementiert, also meist
über globale Variablen und Funktionen. Der übliche Kleinkram halt, zur
besseren Bedienbarkeit.

Langsam erkenne ich aber die objektorientierte Methode als einen echten
Quantensprung. Der Bausteingedanke ermöglicht extrem schnelle
Anpassbarkeit und beinah beliebige Integration. Das Programm wird viel
_schöner_.

* Was sind generell die Nachteile? Für mich steigt der Grad der
Komplexitàt und Co-Abhàngigkeit der Objekte untereinander (oder wie
nennt man das?) Das macht auch das Debuggen komplizierter.

* Wie objektorientiert ist VB6?
Könnte ich für jede meiner Routinen eine Klasse erstellen und als Objekt
implementieren? Wàren, sagen wir 50 Klassen + 20 eigene Controls noch
performant? (vorausgesetzt, alles ist sauber programmiert)

Wie handhabt ihr das, und wie objektorientiert und "vererbbar" soll
eigentlich guter Programmierstil generell sein?


Gruß und schon mal Danke für's Antworten,
Paul.
 

Lesen sie die antworten

#1 Ulrich Korndoerfer
04/03/2011 - 03:09 | Warnen spam
Hallo Paul,

Paul Pierot schrieb:
Hallo,
ich habe ein paar Fragen zum Programmieren mit VB6 und im Allgemeinen.
Sachen, wo mir als Laie die Erfahrung des Berufsprogrammierers fehlt.

Inzwischen habe ich etliche Routinen, die ich immer wieder in meinen
Programmen einsetze (Zuletzt-Geöffnet-Historie, Dateien in den
Papierkorb löschen, kleinere GUI-Anpassungen, usw.)

Bislang habe ich diese Routinen eher linear implementiert, also meist
über globale Variablen und Funktionen. Der übliche Kleinkram halt, zur
besseren Bedienbarkeit.

Langsam erkenne ich aber die objektorientierte Methode als einen echten
Quantensprung. Der Bausteingedanke ermöglicht extrem schnelle
Anpassbarkeit und beinah beliebige Integration. Das Programm wird viel
_schöner_.

* Was sind generell die Nachteile? Für mich steigt der Grad der
Komplexitàt und Co-Abhàngigkeit der Objekte untereinander (oder wie
nennt man das?) Das macht auch das Debuggen komplizierter.

* Wie objektorientiert ist VB6?
Könnte ich für jede meiner Routinen eine Klasse erstellen und als Objekt
implementieren? Wàren, sagen wir 50 Klassen + 20 eigene Controls noch
performant? (vorausgesetzt, alles ist sauber programmiert)

Wie handhabt ihr das, und wie objektorientiert und "vererbbar" soll
eigentlich guter Programmierstil generell sein?




Die Grenze zu ziehen, wann genau objektorientiertes Vorgehen vorzuziehen
ist, ist schwierig und hàngt vom Anwendungsfall ab. *Keinesfalls* ist
objektorientiertes Vorgehen *pauschal* vorzuziehen. Die Unterscheidung
ist von vielen Faktoren abhàngig. Einer diese Faktoren ist zb, ob man
mehr privat alleine für sich programmiert oder kommerziell und/oder im Team.

Deshalb hier ein paar Anregungen, die sich jeweils auf einen
Anwendungsfall beziehen.

Fall A)

Im Laufe der Zeit sammeln sich einige Routinen an, die man immer wieder
benötigt und eng umrissene Aufgaben durchführen (so wie oben von Dir
erwàhnt). Die Routinen selber benötigen keinen "State", es müssen also
nicht irgendwelche Daten *zwischen* zwei Aufrufen gespeichert werden.
Einer Routine werden alle benötigten Daten als Parameter übergeben, die
Routine tut ihre Arbeit, danach werden die Daten nicht mehr benötigt.

Das kann man ohne weiteres in Modulen implementieren. Die Nachteile
dabei sind:

- notgedrungen müssen die Routinen öffentlich (global) sein. Das führt
zu einer gewissen "Verschmutzung" des Namensraumes und kann zu
Nameclashes (zwei Module haben eine Routine gleichen Namens) führen.

- man kann die Routinen nur im Sourcecode verwenden. Die entsprechenden
Module müssen also immer direkt als Sourcecode in jedes Projekt, welches
sie verwendet, eingefügt werden. Verwendet zB das Hauptprogramm ein
Modul und soll eine Dll ebenfalls die Routinen des Moduls verwenden
können sollen, muß das Modul als Source sowohl im Projekt des
Hauptprogrammes als auch im Projekt der Dll vorhanden sein.

Das führt zu unnötiger Vergrößerung der kompilierten Dateien, da der
gleiche Code zweimal vorhanden ist (im Hauptprogramm und in der Dll).

Und man kann die Routinen nicht kompiliert anderen zur Verfügung
stellen, sondern muß immer den Sorucecode weitergeben, was nicht immer
erwünscht ist.

- Ausserdem erschwert das die Wartung. Ändert man zB den Code des
Modules, welches im Hauptprogramm verwendet ist, muß man daran denken,
die Änderungen auch im Modul des Dll-Projekts durchzuführen.

Man könnte natürlich das Modul einfach als Datei kopieren. Oder beide
Projekte auf die gleiche Datei verweisen lassen. Aber irgendwann wird
das unübersichtlich (spàtestens dann, wenn man 30 Hauptprogramme und 40
Dlls hat, die alle den Code dieses Moduls verwenden).

Und jede Änderung führt dann dazu, daß man alle Projekte, die dieses
Modul verwenden, neu kompilieren muß.

Man könnte diese Routinen auch in einer Klasse implementieren.

Ein Vorteil wàre, daß es nun keine Namensraumverschmutzung mehr gibt und
Namenskollisionen nicht mehr auftreten, da jede Klasse einen eigenen
Namensraum besitzt.

Ein weiterer Vorteil wàre, daß man nun diese Klasse über eine Dll
kompiliert zur Verfügung stellen kann. Der Code ist dann nur noch an
einer Stelle zu warten: im Dll-Projekt. Alle, die den Code verwenden
wollen, binden die Dll in das Projekt per Verweis ein. Hat man zB in
einer Routine einen Fehler festgestellt, reicht es, den an einer Stelle
zu korrigieren und die Dll neu zu kompilieren. Alle Projekte, die diese
Dll verwenden, kommen dann automatisch in den Genuß der Verbesserung.
Hat man die Binàrkompatibilitàt der Dll beim kompilieren gewahrt,
brauchen diese anderen Projekte noch nicht mal neu kompiliert zu werden.

Nachteilig ist, daß nun Projekte von der Dll abhàngig werden und man die
entsprechenden Anforderungen berücksichtigen muß. Zudem sind
Methodenaufrufe von Methoden in einer Klasse etwas langsamer als der
Aufruf von Methoden in einem Modul. Und der Code in einer Modulmethode
làuft etwas schneller ab als der Code in einer Klassenmethode. Aber das
sind wirklich nur marginale Unterschiede, die sich so gut wie nie
wirklich negativ bemerkbar machen. Eine Ausnahme wàren àußerst
rechenintensive Aufgaben, die auch noch jede Menge Daten bearbeiten.
Eine solche Methode, die dann in einem Modul implementiert schon sagen
wir mal 10 Sekunden braucht, würde dann halt in einer Klasse Pi mal
Daumen 12 Sekunden brauchen.

Fall B)

Zwischen den Methodenaufrufen müssen Daten gespeichert werden. Oder eine
Methode benötigt so viele Parameter, daß man alleine schon aus Gründen
der Übersichtlichkeit einen Teil der Daten nicht als Parameter übergibt,
sondern vor dem Aufruf in globalen Variablen setzt.

Oder die gleichen Methoden sollen von verschiedenen Stellen im Code
aufgerufen werden, sich aber unterschiedlich verhalten, gesteuert durch
globale Variable.

Also eigentlich immer dann, wenn man in seinem Modul nicht nur Methoden
global definiert hat, sondern auch globale Variablen hat.

Hier sollte der Klasse der Vorzug gegeben werden. Klassen bzw. Objekte
sind für diesen Anwendungsfall "erfunden" worden: Daten und Methoden
bilden eine Einheit.

Fall C)

Es sollen Events verwendet werden.

Hier kommt man an Klassen nicht vorbei, da in VB nur Klassen Events
werfen und empfangen können, in Modulen ist dies nicht möglich.

Ulrich Korndoerfer

VB tips, helpers, solutions -> http://www.prosource.de/Downloads/
MS Newsgruppen Alternativen -> http://www.prosource.de/ms-ng-umzug.html

Ähnliche fragen