wozu Module und Klassen?

  • Allgemein

Es gibt 15 Antworten in diesem Thema. Der letzte Beitrag () ist von RodFromGermany.

    wozu Module und Klassen?

    Hallo Forum, hab mich die letzten Wochen mal an VisualBasic versucht und bin soweit ganz gut vorwärts gekommen.
    Jetzt bin ich an der Stelle wo es um Module und Klassen geht und da stehe ich momentan wohl etwas auf dem Schlauch :huh:

    So wie ich im Inet gelesen habe, sollte man auf Module komplett verzichten.
    Jetzt stellt sich mir jedoch die Frage warum und wieso es sie dann überhaupt gibt?
    Finde die eigentlich ganz praktisch, da ich in diesen, der Übersicht halber, doch Prozeduren und Funktionen auslagern kann.

    Eine Klasse ist doch der "Bauplan" eines Objektes, welche Methoden und Eigenschaften dieses anbietet oder?
    Sollte man für oft verwendete Prozeduren und Funktionen eine eigene Klasse schreiben oder hab ich das komplett falsch verstanden ?(

    zu den Modulen: sie sind veraltetete Reliquien
    zu den Klassen: Ja, alle Eigenschaften, Variablen und Methoden, die zusammengehören sollte man in einer Klasse bündel, sodass der Code logisch geordnet ist.

    Hey,

    willkommen im Forum!!!!

    Module werden z. B. noch für Extensions gebraucht.

    Ansonsten solltest Du darauf achten, Deine Programmierprobleme entsprechend objektorientiert zu lösen, dann brauchst Du in der Regel keine Module mehr.

    Denn Module bieten keine Vererbung und Module kann man nicht instanzieren. In Modulen wird einfach Code ausgelagert (Sub, Functions). Aber Du solltest darauf verzichten und ein Augenmerk auf die Objektorientierung legen, dann wirst Du mit Modulen, abgesehen von Extensions, nicht viel zu tun haben.
    Die Unendlichkeit ist weit. Vor allem gegen Ende. ?(
    Manche Menschen sind gar nicht dumm. Sie haben nur Pech beim Denken. 8o

    Hey vielen Dank für die nette Begrüßung und die Antworten.

    Ok also werden mich Module wohl in naher Zukunft erst einmal nicht interessieren :)

    Mit den Klassen habe ich jetzt auch verstanden wozu sie gut sind.
    Jetzt stellt sich aber die Frage wie erstelle ich sinnvoll eine Klasse und sollte ich alles in Klassen erstellen was ich
    vielleicht auch in anderen Programmen brauchen könnte?

    Hab mir mal eine Prozedur geschrieben wie ich "einfacher" TreeNodes erstellen kann.

    VB.NET-Quellcode

    1. Public Sub CreateNode(TreeViewObjekt As TreeView, Text As String, ToolTip As String, ImgIndex As Integer, SelImgIndex As Integer)
    2. Dim NewNode As New TreeNode()
    3. NewNode.Text = Text
    4. NewNode.ToolTipText = ToolTip
    5. NewNode.ImageIndex = ImgIndex
    6. NewNode.SelectedImageIndex = SelImgIndex
    7. TreeViewObjekt .Nodes.Add(NewNode)
    8. End Sub


    Sollte ich soetwas auch in eine Klasse "umbauen"?

    VB.NET-Quellcode

    1. TreeView


    ist schon eine Klasse und stellt entsprechende Funktionen und Properties zur Verfügung. Du kannst natürlich die TreeView-Klasse erweitern (vererben), und Deine eigenen Funktionen, die Du als sinnvoll erachtest, hinzufügen.

    Vererbung ist ein grundlegendes Konzept der OOP (Object Oriented Programming).
    Die Unendlichkeit ist weit. Vor allem gegen Ende. ?(
    Manche Menschen sind gar nicht dumm. Sie haben nur Pech beim Denken. 8o

    Dieser Beitrag wurde bereits 1 mal editiert, zuletzt von „SpaceyX“ ()

    Ok das macht Sinn und von Vererbung steht in meinem Buch auf den nächsten Seiten auch was darüber.

    Aber um noch mal auf mein Beispiel zurück zukommen, was würdest du mir für den optimalsten Weg empfehlen?
    1) Die Prozedur in meinem Formular lassen oder kann ich das auch in einem Modul "auslagern"?
    2) Oder wäre es wirklich sinnvoll für das TreeView-Steuerlement eine eigene erweiterte Klasse (vererbt von TreeView) zu erstellen nur um sie um eine Prozedur zu erweitern?

    Sorry für die blöden Fragen aber möchte es gerne richtig und effizient umsetzen können.

    Das sind keine blöden Fragen, ganz im Gegenteil.

    Nun, es gibt mehrere Möglichkeiten. Wenn Du vor hast, diese "erweiterten" TreeView-Klassen in mehreren Projekten zu nutzen, dann macht es durchaus Sinn, eine Ableitung der TreeView-Klasse zu erstellen. Dies würde im Weiteren dazu führen, dass Du Deine eigens erstellten (abgeleiteten) Controls in einer .dll sammelst und diese .dll in weiteren Projekten einbindest. Das musst Du entscheiden, ob es nur für dieses eine Projekt von Nutzen für Dich ist. Generell aber macht es Sinn, eine Klasse zu erweitern, da so der Code einfach aufgeräumter ist. Sprich, die Klasse kümmert sich selbst um ihr Zeugs. Stünde ich jetzt vor dieser Frage, gäbe es für mich 2 Möglichkeiten.

    1. Ich erstelle eine abgeleitete Version des TreeViews
    2. Ich erstelle mir eine Extension für die TreeView-Klasse

    Letzendlich würde ich mich aber für die Vererbung entscheiden. Auch, wenn es nur für dieses eine konkrete Projekt von Nutzen ist. Schau Dir mal die Klassen des FrameWorks an. Vererbung findest Du überall und das ist auch das gängige Vorgehen. Also, ja. Erstelle Dir eine Ableitung des TreeViews und erweitere es um Deine Methoden.
    Die Unendlichkeit ist weit. Vor allem gegen Ende. ?(
    Manche Menschen sind gar nicht dumm. Sie haben nur Pech beim Denken. 8o

    KabelMops schrieb:


    VB.NET-Quellcode

    1. Public Sub CreateNode(TreeViewObjekt As TreeView, Text As String, ToolTip As String, ImgIndex As Integer, SelImgIndex As Integer)
    2. Dim NewNode As New TreeNode()
    3. NewNode.Text = Text
    4. NewNode.ToolTipText = ToolTip
    5. NewNode.ImageIndex = ImgIndex
    6. NewNode.SelectedImageIndex = SelImgIndex
    7. TreeViewObjekt .Nodes.Add(NewNode)
    8. End Sub
    Ich finde das ein gar nicht soo schlechtes Beispiel, wie eine Methode in einem Modul Sinn machen könnte.
    Der TE will ja nicht Treenode beerben, sondern einfach nur ein Dings haben, wie er viele Zeilen sich ersetzen kann durch einen Aufruf mit vielen Parametern. Kann man jetzt diskutieren, ob das konkret hier viel Sinn macht, aber prinzipiell ist das ein denkbares Anliegen, und eine passable Lösung.

    Aber seit Einführung der Extensions geht das natürlich ganz viel besser, also es gibt kaum jemals einen Grund, eine Modul-Funktion nicht gleich auch als Extension zu gestalten:

    VB.NET-Quellcode

    1. <Extension> _
    2. Public Function AddNode(nodes As TreenodeCollection, Text As String, ToolTip As String, ImgIndex As Integer, SelImgIndex As Integer)
    3. Dim NewNode As New TreeNode()
    4. NewNode.Text = Text
    5. NewNode.ToolTipText = ToolTip
    6. NewNode.ImageIndex = ImgIndex
    7. NewNode.SelectedImageIndex = SelImgIndex
    8. nodes.Add(NewNode)
    9. Return NewNode
    10. End Function
    11. 'aufzurufen:
    12. TreeView1.Nodes.AddNode("blu", "blublu", 1, 2) 'also wie eine Objekt-Funktion, aber es ist eine Modul-Funktion
    13. TreeView1.Nodes(2).Nodes.AddNode("bla", "blabla", 1, 2)

    Ich find, man braucht Module nicht so pauschal verteufeln - tatsächlich kommt jeder wie von selber darauf, dasserse kaum noch braucht.

    (und das sag ich, der ich ühaupt keine Hemmungen habe, Pauschal-Aussagen zu treffen, wenn ich finde, dasse richtig sind!)

    Hi ErfinderDesRades, wollte grad mal dein Beispiel unter VB-Express nachvollziehen aber irgendwie bringt er mir bei
    <Extension> _ immer eine Fehlermeldung:
    Der Attributspezifizierer ist keine vollständige Anweisung.
    Verwenden Sie eine Zeilenfortsetzung, um das Attribut auf die folgende Anweisung anzuwenden.

    Hab den Code testweise direkt im Formular und einmal in einem Modul geschrieben aber immer
    die selbe Fehlermeldung.

    Hey,

    der Spass muss so aussehen:

    VB.NET-Quellcode

    1. Imports System.Runtime.CompilerServices
    3. Module Module1
    4. <Extension> _
    5. Public Sub Wooo(ByVal tB As TextBox, ByVal wooo As String)
    6. tB.Text = wooo
    7. End Sub
    8. End Module


    Unter dem Attribut Extension muss sofort die Deklaration der Function, Sub kommen.
    Die Unendlichkeit ist weit. Vor allem gegen Ende. ?(
    Manche Menschen sind gar nicht dumm. Sie haben nur Pech beim Denken. 8o

    Die VB-Syntax zur Befehlserweiterung sieht folgendermaßen aus:

    VB.NET-Quellcode

    1. Imports System.Runtime.CompilerServices
    2. Module MyExtensions
    3. <Extension()> _
    4. Public Sub Print(ByVal aString As String)
    5. Console.WriteLine(aString)
    6. End Sub
    8. <Extension()> _
    9. Public Function MyAdd(ByVal a As PointF, ByVal b As PointF) As PointF
    10. Return New PointF(a.X + b.X, a.Y + b.Y)
    11. End Function
    12. End Module
    Falls Du diesen Code kopierst, achte auf die C&P-Bremse.
    Jede einzelne Zeile Deines Programms, die Du nicht explizit getestet hast, ist falsch :!:
    Ein guter .NET-Snippetkonverter (der ist verfügbar).
    Programmierfragen über PN / Konversation werden ignoriert!

    Coole Sache mit den Extensions damit kann ich die Steuerelemte ja noch viel einfacher erweitern als über Vererbung.
    Hat das gegenüber der Vererbung Nachteile?

    @SpaceyX
    Hab mir gestern Abend noch mal deinen Tipp mit der Vererbung des Treeviews zu Gemüte geführt.
    Soweit funktioniert auch alles bestens :)
    Nur eine Frage hab ich dazu aber noch, besteht die Möglichkeit ein reguläres TreeView, welches ich im Designer erstellt habe,
    in das von mir erweiterte TreeView-Objekt zum Beispiel über Casten umzuwandeln, so dass ich meine hinzugefügten Methoden nutzen kann?
    Sonst müsste ich mein TreeView-Objekt erst zu Laufzeit auf das Form platzieren.


    Vielen Dank für die vielen und schnellen Antworten... echt tolles forum hier :thumbsup:

    Hat das gegenüber der Vererbung Nachteile?

    Ja. Aber nur einen kleinen.
    Modul-Prozeduren sind global verfügbar. Du kannst also sowas schreiben:

    VB.NET-Quellcode

    1. Private Sub Foo()
    2. AddNode(DasNodeObjektZuDemHinzugefügtWird, Text, ToolTip, RestlicheParameter...)
    3. End Sub

    Das ist der Nachteil bei Modulen.
    Also wenn Du viele Prozeduren in Modulen hast, sind die immer und überall verfügbar und stören ein bisschen im Intellisense-Fenster.

    Edit:
    Wenn Du ein eigenes Control in deinem Projekt hast, dann musst Du das Projekt einmal erstellen (Oben über Erstellen -> Projektmappe erstellen) oder einfach einmal debuggen.
    Dann findest Du das Control in der Toolbox:
    "Luckily luh... luckily it wasn't poi-"
    -- Brady in Wonderland, 23. Februar 2015, 1:56
    Desktop Pinner | ApplicationSettings | OnUtils

    Ok am Anfang wird das nicht stören, wenn die Modulprozeduren alle im Intellisense-Fenster
    erscheinen, aber hast schon recht, bei größereren Projekten wird das dann irgendwann mal nervig.

    Das ist mir garnicht aufgefallen das er mein angepasstes TreeView mit in die Toolbox genommen hat :whistling:
    Dann ist es ja genauso einfach zu bedienen wie die Extensions.

    Vielen vielen DANK an alle, ihr habt mir wirklich weiter geholfen :thumbsup:

    KabelMops schrieb:

    Nur eine Frage hab ich dazu aber noch, besteht die Möglichkeit ein reguläres TreeView, welches ich im Designer erstellt habe,
    in das von mir erweiterte TreeView-Objekt zum Beispiel über Casten umzuwandeln, so dass ich meine hinzugefügten Methoden nutzen kann?
    Nein.
    Erstelle Dein MyTreeView-Control. Compiliere das ganze.
    Sieh in der Designer-Toolbar nach, da erscheint oben ein MyTreeView-Control, dass Du dann statt des schnöden MS-Controls auf Deine Form zuiehen kannst. :thumbsup:
    Falls Du diesen Code kopierst, achte auf die C&P-Bremse.
    Jede einzelne Zeile Deines Programms, die Du nicht explizit getestet hast, ist falsch :!:
    Ein guter .NET-Snippetkonverter (der ist verfügbar).
    Programmierfragen über PN / Konversation werden ignoriert!