Verständnisfrage zu Mustinherit, Overrides, Protected Sub New(), ...

  • VB.NET
  • .NET (FX) 4.5–4.8

Es gibt 22 Antworten in diesem Thema. Der letzte Beitrag () ist von Bartosz.

    Verständnisfrage zu Mustinherit, Overrides, Protected Sub New(), ...

    Moin zusammen,

    ich experimentiere gerade mit Klassen herum, um zu lernen.

    Als Erstes habe ich meine Form1-Klasse:

    VB.NET-Quellcode

    1. Public Class Form1
    2. 'Was hier schreiben, um Instanz zu bauen?
    3. Public Pfad As String = ""
    6. Private Sub Button1_Click(sender As Object, e As EventArgs) Handles Button1.Click
    7. Using OFD As New CommonOpenFileDialog
    8. OFD.Title = "Bild auswählen"
    9. OFD.Filters.Add(New CommonFileDialogFilter("JPEG", ".jpg"))
    10. OFD.Filters.Add(New CommonFileDialogFilter("Bitmap", ".bmp"))
    11. OFD.Filters.Add(New CommonFileDialogFilter("PNG", ".png"))
    12. OFD.Multiselect = False
    13. OFD.InitialDirectory = Environment.GetFolderPath(Environment.SpecialFolder.Desktop)
    14. OFD.IsFolderPicker = False
    15. OFD.RestoreDirectory = True
    16. If OFD.ShowDialog() = DialogResult.OK Then
    17. Pfad = OFD.FileName
    18. Else
    19. Exit Sub
    20. End If
    21. End Using
    23. '' Wie aufrufen?
    24. End Sub
    26. Private Sub Form1_FormClosing(sender As Object, e As FormClosingEventArgs) Handles MyBase.FormClosing
    27. PictureBox1.Image = Nothing
    28. End Sub
    29. End Class


    So, nun möchte ich eine Public MustInherit Class verwenden.
    Ich habe noch Schwierigkeiten mit allem. Sobald ich einen Fehler korrigiere, kommen 2 neue..Ich muss gestehen, dass ich keine Ahnung vom MustInherit habe

    VB.NET-Quellcode

    1. Public MustInherit Class Abstrakte_Klasse : Inherits SharedPtrObject
    2. Protected Sub New()
    3. End Sub
    4. Public Shared Function Create() As Abstrakte_Klasse
    5. Return New abstrakte_Klasse_1 'Fehler! ?? Der Typ abstrakte_klasse_1 ist nicht definiert.
    6. End Function
    7. Public ReadOnly Property Ptr1 As IntPtr
    8. End Class
    An die Neulinge: Nutzt Option Strict On und Option Infer Off. Dadurch kommt ihr mit Datentypumwandlungen nicht durcheinander und der Code verbessert sich um Einiges! Solche Fehler à la Dim Beispiel As Integer = "123" können nicht mehr passieren.

    Ok, Du hast ne Basisklasse SharedPtrObject. Die Klasse Abstrakte_Klasse erbt von SharedPtrObject. Aber was ist abstrakte_Klasse_1? Die hast Du nicht definiert. Sieht mir irgendwie so aus, als willst Du ein Singleton-Pattern nachbauen. Aber das geht ja ohne abstrakte Klasse. Hm. Was hast Du vor?
    Dieser Beitrag wurde bereits 5 mal editiert, zuletzt von „VaporiZed“, mal wieder aus Grammatikgründen.

    Aufgrund spontaner Selbsteintrübung sind all meine Glaskugeln beim Hersteller. Lasst mich daher bitte nicht den Spekulatiusbackmodus wechseln.

    @VaporiZed Danke für die schnelle Antwort.
    Das ist nur ein Beispiel.
    ich weiß auch nicht, was ein Singleton-Pattern ist.

    Am besten, ich fange ganz einfach an. Kennst du noch diesen Thread hier? Drehzahlmesser grafisch visualisiert
    Da habe ich auch ne andere Klasse für das Painten in der PictureBox verwendet, das war aber einfach nur ne stinknormale Klasse. Jetzt will ich etwas mehr lernen und muss mich mal ein bisschen mit diesen Schlagwörtern MustInherit (und wie sie alle heißen) beschäftigen.

    Ich habe vorhin auch schon Threads gesucht, bin auf RFGs und EDRs Antworten gestoßen und habe das einfach mal kopiert, jedoch kamen immer Fehler.

    Ich würde euch gerne bitten, ein Beispiel mit mir durchzugehen.

    Aber was ist abstrakte_Klasse_1? Die hast Du nicht definiert.
    Das verstehe ich nicht. Gerade die mache ich doch neu ?! :|
    An die Neulinge: Nutzt Option Strict On und Option Infer Off. Dadurch kommt ihr mit Datentypumwandlungen nicht durcheinander und der Code verbessert sich um Einiges! Solche Fehler à la Dim Beispiel As Integer = "123" können nicht mehr passieren.

    He? Bisher hast Du nur Abstrakte_Klasse und SharedPtrObject. Aber für den Compiler ist abstrakte_Klasse_1 etwas, was noch nicht existiert. Das ist wie mit
    Public Class Auto. Wenn Du die hast, kannst Du schreiben: Dim MeinAuto As New Auto
    Aber wenn Du Public Class Auto nicht hast, weiß der Compiler auch nicht, von welchem Typ MeinAuto sein soll. Und daher: Du hast nirgends stehen Public Class abstrakte_Klasse_1. Nur Public Class Abstrakte_Klasse. Das sind aber 2 paar Schuhe. Genauso könntest Du statt New abstrakte_Klasse_1 auch New Bartosz schreiben. Damit kann der Compiler auch nix anfangen.
    Dieser Beitrag wurde bereits 5 mal editiert, zuletzt von „VaporiZed“, mal wieder aus Grammatikgründen.

    Aufgrund spontaner Selbsteintrübung sind all meine Glaskugeln beim Hersteller. Lasst mich daher bitte nicht den Spekulatiusbackmodus wechseln.

    Ok, da muss ich niedriger ansetzen. Gebe ich zu xD

    ich habe hier mal etwas Fertiges herausgesucht. Hoffe, das ist OK. Was sind die einzelnen Abläufe in Post #31 (von @fichz)

    VB.NET-Quellcode

    1. Public MustInherit Class Tower
    3. Private _Reichweite As Integer
    4. Public Property Reichweite() As Integer
    5. Get
    6. Return _Reichweite
    7. End Get
    8. Set(ByVal value As Integer)
    9. _Reichweite = value
    10. End Set
    11. End Property
    13. Private _Schaden As Double
    14. Public Property Schaden() As Double
    15. Get
    16. Return _Schaden
    17. End Get
    18. Set(ByVal value As Double)
    19. _Schaden = value
    20. End Set
    21. End Property
    23. Protected Sub New(ByVal Manager As TowerManager)
    24. Manager.TowerList.Add(Me)
    25. End Sub
    27. End Class
    29. Public Class LaserTurm : Inherits Tower
    31. Protected Sub New(ByVal manager As TowerManager)
    32. MyBase.New(manager)
    33. End Sub
    35. End Class
    37. Public Class TowerManager
    38. Private _TowerList As List(Of Tower)
    39. Public Property TowerList() As List(Of Tower)
    40. Get
    41. Return _TowerList
    42. End Get
    43. Set(ByVal value As List(Of Tower))
    44. _TowerList = value
    45. End Set
    46. End Property
    47. End Class
    An die Neulinge: Nutzt Option Strict On und Option Infer Off. Dadurch kommt ihr mit Datentypumwandlungen nicht durcheinander und der Code verbessert sich um Einiges! Solche Fehler à la Dim Beispiel As Integer = "123" können nicht mehr passieren.

    Der Post ist etwas älter, es haben sich inzwischen Vereinfachungen ergeben:

    VB.NET-Quellcode

    1. Public MustInherit Class Tower
    2. Public Property Reichweite() As Integer
    3. Public Property Schaden() As Double
    5. Protected Sub New(Manager As TowerManager)
    6. Manager.TowerList.Add(Me)
    7. End Sub
    8. End Class
    10. Public Class LaserTurm : Inherits Tower
    11. Protected Sub New(manager As TowerManager)
    12. MyBase.New(manager)
    13. End Sub
    14. End Class
    16. Public Class TowerManager
    17. Public Property TowerList() As List(Of Tower)
    18. End Class

    Was haben wir nun:
    Wir haben eine Tower-Klasse. Da sie als MustInherit gekennzeichnet ist, kannst Du nicht schreiben: Dim MyTower = New Tower, da Tower durch jenes Schlüsselwort als abstrakte Basisklasse gekennzeichnet ist. Anderes Beispiel: Lebewesen. Es könnte als Eigenschaft z.B. Alter haben. Aber so ziemlich alles andere muss durch Unterklassen festgelegt werden, z.B. Prokaryonten und Eukaryonten. Oder Pflanzen, Tiere, Pilze, Bakterien, SonstigeEinzeller. Würdest Du also sagen: Ich erschaffe nun ein neues Lebebwesen, ergäbe das wenig Sinn, da diese Klasse viel zu unspezifisch ist, um ein konkretes Wesen zu erzeugen. Die Klasse ist einfach zu allgemein gehalten.
    Zurück zum Tower. Der Laserturm erbt von Tower und hat darüberhinaus … hm, keine weiteren Eigenschaften. Normalerweise wird Vererbung verwendet, um spezifischere Türme zu generieren, die eben noch zusätzliche Eigenschaften oder Funmtionen aufweisen. Daher: ungünstiges Beispiel.
    Dieser Beitrag wurde bereits 5 mal editiert, zuletzt von „VaporiZed“, mal wieder aus Grammatikgründen.

    Aufgrund spontaner Selbsteintrübung sind all meine Glaskugeln beim Hersteller. Lasst mich daher bitte nicht den Spekulatiusbackmodus wechseln.

    ich würd empfehlen, sich da nicht so drin zu verbeissen.
    MustInherit braucht man nur selten, und das einzige Beispiel dieses Threads (der LaserTower) ist sinnlos, denn der LaserTower hat nichts, was Tower nicht schon selbst hatte.

    Das halte ich für ganz wichtig, wenn man sich mit SprachFeatures auseinandersetzt: Dass man auch ein wirkliches Problem hat, was durch das SprachFeature auch überzeugend gelöst wird.
    Sonst wurstelt man sich ieinen Mist zusammen, und denkt hinterher "ich kanns" - und stimmt garnet, sondern ist eher ein AntiPattern.

    Ich hab zB. bislang insgesamt nur 3 mal MustInherit verwenden müssen, und meist für eher abgedrehte Sachen, die ich gefühlt kaum verständlich machen kann:
    • DatasetAdapterBase - das ist noch gut verstehbar:
      Davon ist abgeleitet der XmlDatasetAdapter, der ein typDataset einfach auf Platte speichert, und der DbDatasetAdapter, der in eine Datenbank persistieren kann
    • BinarySearcherBase
      ziemlich abgedreht: ein 'normaler' BinarySearcher für normale Binärsuchen - die Treffer sind unbestimmtt, wenn der Datenbestand einen Bereich gleicher Werte enthält (Dubletten). Und ein BinaryRangeSearcher - wenn Dubletten vorhanden, kann dieser BinarySearcher den ersten / letzten Eintrag des DublettenRanges auffinden
    • CompletionPreviewBase
      ZusatzFeature zu AutoCompletion. AutoCompletion gibts für Textboxen, aber auch für Comboboxen - intern tickt das verschieden.
    Also wie gesagt: Such dir erst ein Problem, was mit einer abstrakten Basisklassen überzeugend zu lösen ist.
    Sonst kann das eiglich nur BrainF** werden.

    Was du auch machen kannst ist nach "Strategy-Pattern" googeln, weil abstrakte Basisklassen sind eiglich der Königsweg, um diesen Pattern umzusetzen.
    Aber wie google so ist: kann natürlich auch sein, dass du an einen echten BrainF**er gerätst - vlt. posteste die Links, die dir vielversprechend erscheinen. (ein Anhaltspunkt z.B.: es muss eine BeispielSolution zum Download stehen (die auch funktioniert))

    @VaporiZed Danke für deine Metapher mit dem Lebewesen und für die gute Erklärung! :)
    @ErfinderDesRades Verstehe ich, ist ein bissl unnütz mit dem Tower-Beispiel. Und mit MustInherit... War vorhin nur auf die Schnelle rausgesucht.
    es muss eine BeispielSolution zum Download stehen (die auch funktioniert)
    Vielleicht finde ich morgen in der Suche etwas besseres zu Klassen allgemein, oder ich denke mir etwas Konkretes aus, vielleicht das mit Lebewesen. Danke dir für die gute Erklärung :)

    Noch 3 Sachen zum Verständnis:
    1.) Muss das so, wie im Anhang, mit der List? Nee oder? Das ist doch nur eine Liste mit den neuen Instanzen?
    2.) Verstehe ich das richtig: in der

    Quellcode

    1. Public MustInherit Class Tower
    muss es ein

    Quellcode

    1. Protected Sub New()
    geben, weil man das gewöhnliche

    Quellcode

    1. Dim MyTower = New Tower
    nicht schreiben kann? In der abgeleiteten Klasse (ist das Wort richtig?) gibt es auch ein

    Quellcode

    1. Protected Sub New()
    worin

    Quellcode

    1. MyBase.New(manager)
    steht. Was macht das? Muss das?
    3.) Wie rufe ich das, mit dem man arbeiten will (meinetwegen eine Prozedur, die hier noch nicht steht), aus Form1 auf?

    Viele Grüße
    Bilder

    • screenshot geschnitten rote Linie - Kopie.jpg

      77,37 kB, 548×460, 67 mal angesehen
    An die Neulinge: Nutzt Option Strict On und Option Infer Off. Dadurch kommt ihr mit Datentypumwandlungen nicht durcheinander und der Code verbessert sich um Einiges! Solche Fehler à la Dim Beispiel As Integer = "123" können nicht mehr passieren.

    Nee, vergiss das Beispiel, das ist irreführend. Durch MustInherit ist Dim MyTower = New Tower schon nicht möglich, da meckert der Compiler rum, dass man abstrakte Klassen nicht instanziieren kann. Das mit Protected Sub New muss nicht sein. Und das mit der TowerList schon gleich 3x nicht. Mag damals relevant gewesen sein, weil spezifischer Fall. Aber eine Klasse sollte normalerweise nix über seinen Container wissen. Von CEs z.B. mal abgesehen. Da find/bastel ich ein besseres Beispiel.

    ##########

    Nehmen wir das Towerbeispiel. Ich hab zwar kein Spiel, aber brauchen wir ja auch nicht.

    Spoiler anzeigen

    VB.NET-Quellcode

    1. Public MustInherit Class Tower
    3. Protected ShootingRangeInPixels As Integer
    4. Protected LifeEnergyInPercent As Integer = 100
    5. Protected Damage As Integer
    7. Public Function IsAlive() As Boolean
    8. Return LifeEnergyInPercent > 0
    9. End Function
    11. Public MustOverride Sub Shoot()
    13. End Class
    15. Public Class CannonTower : Inherits Tower
    17. Public Sub New()
    18. ShootingRangeInPixels = 50
    19. Damage = 10
    20. End Sub
    22. Public Overrides Sub Shoot()
    23. MessageBox.Show("Kaboom!")
    24. End Sub
    26. End Class
    28. Public Class LaserTower : Inherits Tower
    30. Public Sub New()
    31. ShootingRangeInPixels = 100
    32. Damage = 8
    33. End Sub
    35. Public Overrides Sub Shoot()
    36. MessageBox.Show("Spratzel!")
    37. End Sub
    39. End Class

    Dieser Beitrag wurde bereits 5 mal editiert, zuletzt von „VaporiZed“, mal wieder aus Grammatikgründen.

    Aufgrund spontaner Selbsteintrübung sind all meine Glaskugeln beim Hersteller. Lasst mich daher bitte nicht den Spekulatiusbackmodus wechseln.

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

    jo, zumindest ein sauberes Beispiel ohne so komisches wie Protected Sub New etc. (nix gegen Protected Sub New - es gibt Probleme, die damit zu lösen sind)
    Aber nachwievoer nicht wirklich überzeugend, denn die Unterschiede der Tower-Erben sind marginal.
    Im Grunde sinds ja nur verschiedene Voreinstellungen. Aber um Default-Werte zu setzen braucht man nicht unbedingt ein KlassenSystem mit Abstrakta.

    Wie gesagt: Es ist garnet so einfach, ein geeignetes Problem zu finden.

    Dann geb ich Dir ein spezielles:

    VB.NET-Quellcode

    1. Public MustInherit Class TypedBindingSource(Of T) : Inherits BindingSource: End Class

    Den Rest der Funktionalität lass ich mal raus. Aber da - wie wir schon in einem anderen Thread vor einigen Wochen feststellten - WinForms keine generischen CEs akzeptiert, muss man hier mit MustInherit arbeiten:

    VB.NET-Quellcode

    1. Public Class BsProcesses : Inherits TypedBindingSource(Of Process) : End Class
    Und das Teil kann ich mir auf's Form ziehen und all die kleinen Feinheiten genießen, die ich in die Basisklasse eingebaut habe.
    Dieser Beitrag wurde bereits 5 mal editiert, zuletzt von „VaporiZed“, mal wieder aus Grammatikgründen.

    Aufgrund spontaner Selbsteintrübung sind all meine Glaskugeln beim Hersteller. Lasst mich daher bitte nicht den Spekulatiusbackmodus wechseln.

    @VaporiZed Cool, danke! Ich erkenne: 2 Gegner (Lasertower und Cannontower); beide erben von Tower, weil's halt beide Tower sind. Mit Public Sub New() werden die Integers des Tower jeweils befüllt. Prinzip verstanden :thumbsup:

    Ich bin jetzt so vorgegangen und es funktioniert. Da fehlt nur noch die Verarbeitung des Schadens. Noch ein bisschen ungewohnt, dass die .shoot() nicht im IntelliSense vorgeschlagen wird

    VB.NET-Quellcode

    1. Public Class Form1
    2. Dim myCannonTower = New CannonTower
    3. Dim myLaserTower = New LaserTower
    4. Private Sub Form1_Load(sender As Object, e As EventArgs) Handles MyBase.Load
    5. End Sub
    7. Private Sub Button_Cannon_Click(sender As Object, e As EventArgs) Handles Button_Cannon.Click
    8. If myCannonTower.IsAlive() Then
    9. myCannonTower.shoot()
    10. End If
    11. End Sub
    13. Private Sub Button_Laser_Click(sender As Object, e As EventArgs) Handles Button_Laser.Click
    14. If myLaserTower.isAlive() Then
    15. myLaserTower.shoot()
    16. End If
    17. End Sub
    18. End Class
    20. Public MustInherit Class Tower
    22. Protected ShootingRangeInPixels As Integer
    23. Protected LifeEnergyInPercent As Integer = 100
    24. Protected Damage As Integer
    26. Public Function IsAlive() As Boolean
    27. Return LifeEnergyInPercent > 0
    28. End Function
    30. Public MustOverride Sub Shoot()
    32. End Class
    34. Public Class CannonTower : Inherits Tower
    36. Public Sub New()
    37. ShootingRangeInPixels = 50
    38. Damage = 10
    39. End Sub
    41. Public Overrides Sub Shoot()
    42. MessageBox.Show("Kaboom!")
    43. End Sub
    45. End Class
    47. Public Class LaserTower : Inherits Tower
    49. Public Sub New()
    50. ShootingRangeInPixels = 100
    51. Damage = 8
    52. End Sub
    54. Public Overrides Sub Shoot()
    55. MessageBox.Show("Spratzel!")
    56. End Sub
    58. End Class
    An die Neulinge: Nutzt Option Strict On und Option Infer Off. Dadurch kommt ihr mit Datentypumwandlungen nicht durcheinander und der Code verbessert sich um Einiges! Solche Fehler à la Dim Beispiel As Integer = "123" können nicht mehr passieren.

    Bartosz schrieb:

    Noch ein bisschen ungewohnt, dass die .shoot() nicht im IntelliSense vorgeschlagen wird
    Hab ich was vergeigt?
    Bei mir wird's angezeigt:


    Der Vorteil der Vererbung ist auch, dass Du die verschiedenen Türme nun zusammenfassen kannst:

    VB.NET-Quellcode

    1. Dim TowerList As New List(Of Tower)
    2. TowerList.Add(New LaserTower)
    3. TowerList.Add(New CannonTower)
    5. For Each Tower In TowerList
    6. If Tower.IsAlive Then Tower.Shoot()
    7. Next

    andere Schreibweise:

    VB.NET-Quellcode

    1. Dim TowerList As New List(Of Tower) From {
    2. New LaserTower,
    3. New CannonTower
    4. }
    6. TowerList.Where(Function(x) x.IsAlive).ForEach(Sub(x) x.Shoot())


    Und ganz kurz noch: Das MustOverride in der Basisklasse ist eben dafür da, dass Du sagst: "Hey, alle, die von mir erben, müssen eine Shoot-Methode haben. Wie die aussieht, ist mir aber egal." Dadurch geht eben das mit der Schießen-For-Schleife. Würde die Shoot-Methode nicht bereits in der Tower-Basisklasse stehen, würde die Schleife nicht funktionieren.
    Dieser Beitrag wurde bereits 5 mal editiert, zuletzt von „VaporiZed“, mal wieder aus Grammatikgründen.

    Aufgrund spontaner Selbsteintrübung sind all meine Glaskugeln beim Hersteller. Lasst mich daher bitte nicht den Spekulatiusbackmodus wechseln.

    1.) Einmal das Bild von meinem IntelliSense. Kann das an meiner Version iegen?
    Microsoft Visual Studio Professional 2019 Version 16.6.1
    Ist aber nicht so schlimm. Ich weiß nun, dass die Subs in Wirlichkeit da sind. Ich hatte letztens einen ähnlichen Fall. Post 15 von EDR

    2.) Jetzt habe ich das mit der Liste verstanden. Ist demnach nur eine Zusammenfassung.
    Bilder

    • IntelliSense - Kopie.jpg

      108,85 kB, 986×433, 61 mal angesehen
    An die Neulinge: Nutzt Option Strict On und Option Infer Off. Dadurch kommt ihr mit Datentypumwandlungen nicht durcheinander und der Code verbessert sich um Einiges! Solche Fehler à la Dim Beispiel As Integer = "123" können nicht mehr passieren.

    Tja, das dürfte daran liegen, dass Du Deine eigene Signator ignorierst: An die Neulinge: verwendet Option Strict On
    Denn Du hast Deine Tower nicht korrekt deklariert. Die gelten als Object und können daher nicht korrekt von IntelliSense als Tower erkannt werden.
    Dieser Beitrag wurde bereits 5 mal editiert, zuletzt von „VaporiZed“, mal wieder aus Grammatikgründen.

    Aufgrund spontaner Selbsteintrübung sind all meine Glaskugeln beim Hersteller. Lasst mich daher bitte nicht den Spekulatiusbackmodus wechseln.

    Ups...ich habe heute Morgen ein neues Projekt aufgemacht, extra für diese Tower-Geschichte. Da habe ich Option Strict On nicht angestellt. :whistling:
    An die Neulinge: Nutzt Option Strict On und Option Infer Off. Dadurch kommt ihr mit Datentypumwandlungen nicht durcheinander und der Code verbessert sich um Einiges! Solche Fehler à la Dim Beispiel As Integer = "123" können nicht mehr passieren.

    Grundsätzlich nochmal zu den Zugriffsebenen

    Dim
    Wird fast ausschließlich innerhalb von Methoden und Funktionen verwendet. Es gibt hier ein paar Ausnahmen, z.B. Property Get und Set, aber im Regelfall wird mit Dim (auch wenn es möglich ist) nicht klassenweit deklariert. Hierfür gibt es Private.

    Private
    Wird verwendet wenn eine Variable ausschließlich innerhalb der deklararierenden Klasse zugreifbar gemacht werden soll. Also ist die Variable von außerhalb der Klasse nicht erreichbar. Diese Zugriffsebene wird am häufigsten als Pendant zu Dim verwendet um auf Klassenebene zu deklarieren.

    Public
    Logischerweise das genaue Gegenteil von Private. Wird verwendet um klassenübergreifend oder (innerhalb von Modules) global zu deklarieren.

    Protected
    Ist ein geschütztes Element innerhalb einer Klasse und von außerhalb nicht zugreifbar. Der haupsächlich relevante Unterschied zu Private ist, dass Instanzen von erbenden Klassen dennoch auf die Variablen zugreifen können, was bei Private nicht der Fall ist. Beispiel In Klasse Alpha wird

    VB.NET-Quellcode

    1. Protected Property ModuleName As String

    deklarariert und Klasse Beta erbt von Alpha. Dann ist ModuleName auch in Klasse Beta zugreifbar.

    Friend
    Friend ist ähnlich wie Public innerhalb des Projektes / der Assembly zugreifbar jedoch anders als Public nicht Projekt / Assembly übergreifend.

    Es gibt noch einige Kombination aus diesen Schlüsseln beispielsweise Private Protected, um festzulegen dass die Variable nur dann in der Instanz der erbenden Klasse zugreifbar ist, wenn sich die erbende Instanz in der selben Assembly befindet. Oder Protected Friend wo ich bis heute kein gutes Anwendungsbeispiel für gefunden habe, wofür man das braucht, aber da gibt es bestimmt einen.


    Zur Vererbung:

    MustInherit
    Wird verwendet um Abstrakte Basisklassen zu schreiben, die bestimmte Methoden beinhalten müssen (siehe MustOverride).

    Inherit
    Wird verwendet um eine Klasse von einer anderen Klasse erben zu lassen.

    MustOverride
    Wird verwendet um erbende Klassen zu zwingen bestimmte Methoden oder Funktionen aus der Basisklasse zu überschreiben. Kann nur in abstrakten Basisklassen (siehe Mustinherit) verwendet werden.

    Overridable
    Ähnlich wir MustOverride nur ohne den Zwang. Ermöglicht es erbenden Klassen, einzelne Methoden und Funktionen zu überschreiben.

    Overrides
    Wird verwendet um eine Methode / Funktion einer vererbenden Klasse zu überschreiben.

    Shadows
    Shadows ist etwas abstrakter und schwieriger zu erklären. Es wird verwendet um in der Basisklasse deklarierte Elemente (Properties, Subs, Functions, etc.) in einer erbenden Instanz zu überladen und zu verbergen, also quasi auch bis zu einem gewissen Grad zu überschreiben.

    Ich versuche mal ein Anwendungsbeispiel zu geben:
    Wir haben 4 Klassen:

    - Alpha
    - AlphaModel
    - Beta
    - BetaModel

    In Alpha in eine Property deklariert die MyModel heißt und vom Typ AlphaModel ist. Beta erbt nun von Alpha, aber kann mit dem AlphaModel nichts anfangen, weil es das BetaModel braucht. Bedauerlicherweise ist MyModel, das bereits als AlphaModel deklariert ist in die gesamte Logik in Alpha eingebunden, die an Beta vererbt wird und dort auch benötigt wird. MyModel muss als in Beta zu einem BetaModel werden. Das geht mit Shadows sofern BetaModel von AlphaModel erbt und alle grundlegenden Eigenschaften besitzt, für die Logik in Alpha benötigt werden. Also wird in Beta MyModel wie folgt neu deklariert:

    VB.NET-Quellcode

    1. Protected Shadows MyModel As BetaModel


    Ich hoffe das war einigermaßen verständlich. Wie gesagt, Shadows ist abstrakt.

    Ein Computer wird das tun, was du programmierst - nicht das, was du willst.

    Dieser Beitrag wurde bereits 4 mal editiert, zuletzt von „Yanbel“ ()

    Bartosz schrieb:

    Ups...ich habe heute Morgen ein neues Projekt aufgemacht, extra für diese Tower-Geschichte. Da habe ich Option Strict On nicht angestellt. :whistling:
    In Visual Studio - Empfohlene Einstellungen ist gezeigt, wie man das ProjectTemplate auf Strict On stellt.
    Also die Vorlage aller Projekte, die man neu anlegt.
    Dann kann das nicht mehr passieren, dass man ein neues Projekt anlegt und vergisst, die Deppen-Einstellungen zu korrigieren.

Facebook
Telefonspende