OOP in Visual Basic

[mst]

Ich möchte in VB von Klassen ableiten.

Geht das überhaupt????

Wenn ja, wie?

[BlearSun]

VB ist eine sehr mächtige Sprache, du kannst in VB genau so wie in allen anderen Sprachen, Objektorientiert arbeiten.

Das einzige was unter vb nicht möglich ist, ist die Vererbung.

Selbst die Vererbung gibt es seit VB.NET.

[Technician]

<BLOCKQUOTE><font size="1" face="Verdana, Arial, Helvetica, sans-serif">Zitat:</font><HR>Original erstellt von BlearSun:

<STRONG>VB ist eine sehr mächtige Sprache, du kannst in VB genau so wie in allen anderen Sprachen, Objektorientiert arbeiten.</STRONG>

[mst]

Also keine Vererbung unter VB 6?

[Technician]

<BLOCKQUOTE><font size="1" face="Verdana, Arial, Helvetica, sans-serif">Zitat:</font><HR>Original erstellt von mst:

<STRONG>Also keine Vererbung unter VB 6?</STRONG>

[BlearSun]

Hi..

War ja auch nicht so gemeint, dass man in jeder Sprache objektorientiert arbeiten kann!

Vererbung geht zwar nicht, jedoch Implementierung der Klassen!

Ich muss ehrlich zugeben, dass ich noch nie die Vererbung so richtig gebraucht habe..wäre zwar schon in vielen Bereichen praktischer und "professioneller", jedoch kommt man auch ohne Vererbung gut voran, denke ich.

Wenn dir jedoch die Vererbung so wichtig ist, dann ist VB 6 nicht die richtige Wahl. Nicht zu vergessen: Ab .NET gibt es auch Vererbung und noch viele viele interresante Verbesserungen..

gruss

Blear

<FONT COLOR="#a62a2a" SIZE="1">[ 20. Dezember 2001 16:22: Beitrag 1 mal editiert, zuletzt von BlearSun ]</font>

[mst]

Ich will auch nicht unter VB programmieren, aber leiden kann der Rest vom Team nichts anderes.

Gibt es unter VB andere Möglichkeiten eine Methode einer Klasse aufzurufen, auch wenn die genau Klasse nicht bekannt ist, z.B. Ein Klasse Viereck und die Klass Kreis haben bei eine Draw-Methode und ich will verschiedene grafische Elemente aufrufen, ohne das ich weiß, ob es eine Viereck oder Kreis oder ... ist.

In C++ hätte ich das natürlich mit einer gemeinsamen Basisklasse gemacht

[BlearSun]

Hi

Ich bin im Bereich Datenbank- und Internetprogrammierung tätig und kenne mich ehrlich gesagt mit "Grafik"-Programmierung nicht so gut aus. Das Problem was du mir schilderst, ist ein typischer Fall, wie man es mit Vererbung lösen würde. Gar keine Frage.

Also es gilt immer: Was du nicht vererben kannst, musst du "neu" schreiben.

In deinem Fall eine Klasse Viereck->Methode Draw; eine Klasse Kreis-> Methode Draw usw entwerfen.

Gruss

Blear

[mst]

Das sind dann echt schlechte Nachrichten.

Aber kann ich in VB eine Liste von Werten haben bei denen ich nicht den Datentyp kenne und bei jedem dann z.B. Draw() aufrufen?

Erkennt VB dann selbst ständig, das die Klasse ein Draw kennt?

(Das wäre zwar eigentlich unlogisch, aber in VB kann ich mir alles vorstellen)

[BlearSun]

(Das wäre zwar eigentlich unlogisch, aber in VB kann ich mir alles vorstellen)

************

Wenn dir das unlogisch vorkommt, dann ist das auch nicht möglich.

VB ist heute eine der wenigen Sprachen mit glänzender Zukunft. Neben C++ und C# zählt VB zu den wichtigsten Programmiersprachen in Microsoftwelt.

Mit VB ist es möglich ohne größere Aufwendungen komplexte Klassenstrukturen und Geschäftlogiken zu schreiben.

Es mag sein, dass C++ im Bereichen der Systemprogrammierung ihre Stärken hat. Wenn es aber darum geht, Datenbankprgorammierung, und Mittelschicht programmierung(geschäftslogiken) zu machen, ist VB die beste Alternative, weil es einfach, produktiv und sehr stabil läuft, oder willst du mir erzählen, dass du mit C++ schnellere und stabilerer DB-Applikationen schreiben kannst, als in VB? VB ist eine der meist verwendenteden Programmiersprachen der Welt, ich glaube sogar die Nummer EINS!!

Nicht umsonst investiert Microsoft vielmehr in VB als in C++.

Wobei, eigentlich ist es überhaupt so eine Disskusion mittlerweile nicht mehr notwendig. Die .NET sprachen haben alle die gleiche Stärken und schwächen.

Also, es mag sein, dass du lieber in C++ programmieren willst, kannst mir aber glauben, dass es viele gute Gründe gibt, auf VB umzusteigen. Also versuch bitte nicht zu übertreiben....VB ist, was Synthax angeht, meine Ansicht nach logischer und verständlicher als C++.

Ich habe auch 1 Jahr in C++ Kosolenanwendungen geschrieben, jedoch habe ich mich nach dem ich mit Windows und Datenbankprogrammierung anfangen wollte, bewusst für VB entschieden und du kannst mir glauben, die Entscheidung habe ich NIE bereut!..

Gruss

Blear

[mst]

<BLOCKQUOTE><font size="1" face="Verdana, Arial, Helvetica, sans-serif">Zitat:</font><HR>VB ist heute eine der wenigen Sprachen mit glänzender Zukunft. Neben C++ und C# zählt VB zu den wichtigsten Programmiersprachen in Microsoftwelt.

[BlearSun]

VB ist meiner Meinung nach für simple Programm ganz gut geeignet. Nen paar Formulare und so. Meinetwegen auch mit Datenbankzugriff. Aber bei komplexen Programmen kommt VBasic einfach nicht mit.

Wenn ich Windows-Programme in C programmiere, habe ich vielmehr Möglichkeiten auf die Details einzuwirken. VB ist immer an der Grenze der Fähigkeiten.

[BlearSun]

VB ist meiner Meinung nach für simple Programm ganz gut geeignet. Nen paar Formulare und so. Meinetwegen auch mit Datenbankzugriff. Aber bei komplexen Programmen kommt VBasic einfach nicht mit.

Wenn ich Windows-Programme in C programmiere, habe ich vielmehr Möglichkeiten auf die Details einzuwirken. VB ist immer an der Grenze der Fähigkeiten.

**********

Was verstehst du bitte unter komplexe Programme? Wo siehst du die Grenzen von VB? Nenne mir bitte konkrete Beispiele?

WAS MEINST DU mit ein paar Formulare? Wir arbeiten in der Firma mit VB und schreiben ein Datenbanksystem und DB-Applikation für Speditionsfirmen, mehr als 60 Module und das Projekt an sich (Module außenvor gelassen) hat weiss nicht mehr genau, aber auf jeden Fall mehr als 40 Formulare drin!

Kann ich nochmal zählen und dir sagen wieviele das sind, wenn du es mir nicht glaubst.

Wie schon gesagt, Systemnahe Programmierung ist mit C++ zu realisieren, wenn es aber um Datenbankprogrammierung geht, dann hast du weder Performancegewinn, noch bist du bei der Entwicklung schneller als ein VB Programmierer...

Im gegenteil.

Also wenn du da zweifel hast, dann kannst du gerne auch hier reinschauen:

http://www.microsoft.com/GERMANY/ms/msdnbiblio/artikel/vbcom.htm

Gruss

Blear

[lapso]

Original geschrieben von BlearSun

WAS MEINST DU mit ein paar Formulare? Wir arbeiten in der Firma mit VB und schreiben ein Datenbanksystem und DB-Applikation für Speditionsfirmen, mehr als 60 Module und das Projekt an sich (Module außenvor gelassen) hat weiss nicht mehr genau, aber auf jeden Fall mehr als 40 Formulare drin!

Du beschreibst eine kleine bis mittlere Anwendung. Bei großen Anwendungen setzt kein vernünftiger Mensch VB

und Windows ein.

Einen Haken hat die Sache sowieso: in fünf Jahren gibt es drei Betriebssystems-Versionssprünge und die tolle VB6-Anwendung wird nicht mehr ohne umfangreiche Anpassungen laufen. Oder wird dann immer noch Windows2000 auf den dann modernen Rechnern aufgespielt? Das wird auch wieder problematisch. Oder die Spedition expandiert schnell, oder sie wird aufgekauft. Wie sieht es dann mit Skalierbarkeit und Schnittstellen aus? Beschissen auf hochdeutsch.

VB ist plattformabhängig. Und was das für eine Plattform ist, wissen wir doch alle. Es ist propritärer, hochriskanter Müll.

Die arme Spedition. Oder dumme? Warum wird das nicht in Java implementiert? Gelbe Seiten!

Gruss

Matze

[murph]

oop und vb, ist das nicht ein wiederspruch an sich?

mfg

murph

[murph]

hi matze,

du vergisst bei der ganzen sache nur, das der "proprietäre schrott" von 95 % der firmen als Arbeitsplatz-System eingestzt wird. und eine arbeitsplatz-anwendung in java ist ja wohl mehr als eine zumutung. für kleinere bis mittelgrosse projekte (bis ca. 50 000 loc) kann man ohne weiteres vbasic einsetzen, da kommt es dann wohl eher darauf an, ob der programmierer der davor sitzt diese gewisse komplexität erfassen kann oder nicht. wirklich grosse projekte kann man zwar mit vb auch realisieren, da sollte man sich aber dann fragen, ob eine andere sprache die oop besser unterstüzt, also volle einsetzbarkeit von polymorphi, kapselung und vererbung total unterstüzt nicht besser geeignet wäre? aber java als allgeingültige lösung für alles mögliche einzusetzen ist wohl die total falsche herangehensweise.

wenn sich bei einem system grundlegende dinge ändern sind anpassungen unumgänglich. so laufen z. b. java-programme die unter einer alten vm geschrieben wurden, auch nicht mehr mit der neuesten vm, da muss man dann entweder die alte nehmen und auf neuerungen verzichten, oder eben ANPASSUNGEN vornehmen. ausserdem habe ich noch keine clientseitige wirklich grosse anwendung gesehen die in java entwickelt wurde. java hat natürlich seine berechtigung und ist bei gewissen dingen voll angebracht, aber wie gesagt, komplexe arbeitsplatzanwendungen, egal ob diese auf linux, macintosh, oder dem pc laufen, werden i. d. r. NICHT in java geschrieben.

mfg

murph

[lapso]

Original geschrieben von murph

Du vergisst bei der ganzen sache nur, das der "proprietäre schrott" von 95 % der firmen als Arbeitsplatz-System eingestzt wird. und eine arbeitsplatz-anwendung in java ist ja wohl mehr als eine zumutung.

Das muss keine zumutung sein. Ich habe den Verdacht, dass du nciht ganz im Bilde bist. Dass zu 95% Windows am Arbeitsplatz eingesetzt wird ist eine rein spekulative Zahl. In einigen Branchen wirst du 95% non-Win-Arbeitsplätze finden. Was sich die Win-Arbeitsplatz-Besitzer für einen Ärger mit ihrem System aufgehalst werden, wird immer mehr klar.

wenn sich bei einem system grundlegende dinge ändern sind anpassungen unumgänglich.

Und wenn es regnet, dann wird es nass.

so laufen z. b. java-programme die unter einer alten vm geschrieben wurden, auch nicht mehr mit der neuesten vm, da muss man dann entweder die alte nehmen und auf neuerungen verzichten, oder eben ANPASSUNGEN vornehmen.

Mit dem Unterschied zu MS, dass dies nicht alle 1,5 Jahre notwendig ist und auch nicht in den bekannten Umfängen. Die Planungssicherheit ist wesentlich größer. Alleine die Umstellungen im Zuge von DOTNET sind ja wohl nur noch mit "bizarr" zu bezeichnen.

Natürlich ist mir klar, dass Photoshop nicht mit swing realisiert wird. Aber klar ist mir, dass C und VB eine Menge Tücken mit sich bringen, die alle Anwender täglich zu spüren bekommen.

gruss

matze

[Crush]

Ich weiß von Softwareprodukten die komplett in VB geschrieben sind. Selbst kompliziertere Anwendungen die stark datenbank- und netzwerkorientiert sind lassen sich mit VB offensichtlich gut realisieren. Allerdings gibt es halt sicherlich einige Schwierigkeiten wenn man "tieferliegende" Funktionen des Systems nutzen möchte oder die Geschwindigkeit eine Rolle spielt. Doch ich habe jedenfalls jetzt das erste mal gehört, daß VB objektorientiert sein soll - vielleicht eine Anspielung auf die COM-Objekte?!?! Also habe ich mich mal schlau gemacht...

Beim Suchen fand ich das was die Aussage bestätigt. Schaut man sich die Erklärung zur Objektorientierung an, finde ich diese Kategorisierung ziemlich dürftig. Andere Links sagen das Gleiche (falsche).

Professionellere, zuverlässigere (aber englische) Quellen und Wörterbücher meinen, daß Smalltalk die einzige wirklich objektorientierte Programmiersprache ist (nicht so Java oder C++ und schon zweimal nicht VB), an der sich alle anderen (möchtegern) objektorierntiert-erweiterten Sprachen messen lassen müssen. Genau diese Aussage habe ich mehrfach in meinem Bücherschrank zu C++ gelesen: Nur Smalltalk ist OO pur. Zu VB sagen die, daß es sich nicht um eine echte objektorientierte Sprache handelt, sondern eine mit objektorientierer Philosophie und einer Event-gesteuerten Objektbehandlungsmethode auf Drag´n´Drop-Objekte wie Buttons, Dialog-Boxen und Controls. Sieht mir sehr eingeschränkt aus man ist ziemlich abhängig von den zur Verfügung gestellten Elementen.

Also sollten sich mal alle am Riemen reißen, akzeptieren, daß es nur eine einzige "echte" objektorientiere Programmiersprache (nämlich Smalltalk) gibt - auch wenn´s den C++ oder Java-Programmierer schmerzt ... das sind nur Programmiersprachen mit objektorientierter Erweiterung und alle sind noch einiges von Smalltalk und dem echten OO-Grundgedanken entfernt!

Ich behaupte einfach mal, daß VB (außer .NET) eine schwer eingeschränkte Objektorientierung zugrunde liegt, aber ganz Ohne ist es wohl auch nicht. Aus der Sicht eines 4GL-Coders sind die OO-Möglichkeiten und Ansatze bei VB mehr als leicht eingeschränkt und somit sehen die das schon gleich gar nicht als objektorientiert an. Allerdings müssen die sich auch damit abfinden, daß selbst ihre Programmiersprachen noch lange nicht perfekt dem OO-Grundgedanken entsprechen.

Man sollte hier nicht so aufeinander rumhacken und ELO Recht geben, weil ich weiß, daß der ein professioneller Smalltalk-Programmierer mit langjähriger Erfahrung ist (und das sind bestimmt verdammt Wenige in der FI-Welt)! Wenn hier einer etwas Genaues von der OO-Materie und Smalltalk-betreffendes weiß, wird er es mit Sicherheit sein, der da wirklich mitreden kann.

Ich verstehe eh nicht, warum man plötzlich aus einer Aussage zum Thema einen neuen Thread gemacht hat, der erstens von den zugrundeliegenden Aussagen getrennt wurde und sich dann plötzlich so im Sande verlaufen hat weil die anderen Teilnehmer am Gespräch gar nicht genau wußten was die Vordiskussion überhaupt war und plötzlich wurde das Ganze auch noch gesperrt (wahrscheinlich dachten alle: Der ELO spinnt, sowas als Thread zu eröffnen).

Also nochmal: Mit VB kann man schon was anfangen, "echt" objektorientiert ist nur Smalltalk und alles weitere nur ein mehr oder weniger schwer eingeschränkter Abklatsch davon.

[nic_power]

Original geschrieben von Crush

... "echt" objektorientiert ist nur Smalltalk und alles weitere nur ein mehr oder weniger schwer eingeschränkter Abklatsch davon.

Genau . Das liegt einfach daran, dass Smalltalk die "reine Lehre" implementiert und von Grunde auf als objektorientierte Sprache entworfen wurde (Anfang der 80er am PARC). Objektorientiertheit ist bei praktisch allen anderen Sprachen ein Add On. In Smalltalk _muss_ man objektorientiert Denken und Programmieren, eine andere Moeglichkeit Code zu erzeugen gibt es nicht.

Nic

[Bitschubser]

Original geschrieben von Crush Also nochmal: Mit VB kann man schon was anfangen, "echt" objektorientiert ist nur Smalltalk und alles weitere nur ein mehr oder weniger schwer eingeschränkter Abklatsch davon.

Du nennst viele richtige Punkte und es tut gut, hier auch mal so ausgewogene Beiträge zu lesen. Ich war, zugegeben, etwas verblüfft, als ich eben die Email vom FI-Mailer bekam.

Bei Smalltalk kann ich nicht mitreden, aber verdächtig ist es schon, dass es im Lauf der Jahre keine größere Verbreitung fand.

Ich möchte einmal ein aktuelles Projekt von mir in den Raum stellen, um diesem Sprachenstreit etwas zu verbreitern (*zündel*). Ich entwickle gerade eine Software für größere WindowsCE-Geräte und bin dabei darauf angewiesen, diese entweder in embedded Visual C++ oder embedded Visual Basic 3.0 zu implementieren. DotNet ist (leider) noch nicht im Gespräch. Das eVC fiel gleich links herunter, da wir zu wenig Erfahrung haben und C auf WinCE allzu fehlerträchtig ist. Nun sitze ich hier mit eVB und verfluche diese Sprache aufs tiefste. Es lassen sich zwar schnell Ergebnisse erzielen, aber sie ist unlogisch, inkonsequent und überhaupt nicht stringent; von Objektorientierung keine Spur. Diese Eigenschaften behindern einen sehr deutlich. Es gab hier das Argument, dass nicht die Sprache an sich, sondern die Fähigkeit des Entwicklers, die Komplexität der Aufgabe zu erfassen und umzusetzen, auschlaggebend ist. In meinem Fall kann ich das nicht bestätigen - die Sprache hindert mich schlichtweg sehr deutlich an der Umsetzung. Nicht zuletzt Fehlermeldungen wie "An Error occured while running the Application: Errors occured." können einen an den Rand der Verzweiflung bringen (einen grandioseren Fehler hatte ich bisher nur in JScript: "Undefined is not defined. Line 1 Row 1".. hehehe). Auf jeden Fall ist sowas nicht sehr Entwicklerfreundlich, wie es auch die VB-Fehlerbehandlung ist. Ein Graus. Mir ist es ein Rätsel, wie man damit größere Applikationen schreiben soll; es ist ein einziges Gekrampfe. Und unästhetisch ist der Code dazu, vond er Syntax her wie auch vom gesamten Aufbau.

Nun hätten wir das ganze sicherlich sehr gerne in Java gemacht, aber ein VM-Prozessor ist in den Geräten nicht integriert und daher wäre das viel zu langsam (Reaktion der GUI, Verfügbarkeit von RAM).

So, an die Arbeit.

Grüße

Matze

(war mal Lapso)