Moin,

zu 1.: Ja
zu 2.: Ja
zu 3.: Ja
zu 4.: Implements implementiert ein Interface, während Inherits eine Klasse erbt
zu 5.:

• Public: Öffentlich (für alles und jeden sichtbar)
  
• Private: Privat (nur in dieser Klasse sichtbar)
  
• Protected: Nur für erbende Klassen sichtbar
  
• Shared: Ein statischer Member, auf den ohne Instanz zugegriffen werden kann
  

zu 6.: Ja
zu 7.: Ja
zu 8.: Ich präferiere Optional, da man damit keine Subs/Functions hat, die einfach nur den Aufruf mit weiteren Werten versehen und weiterreichen.
zu 9.: Nein. Es gibt Stellen bei denen Array sinvoll sind. Zum Beispiel Puffer.
zu 10.: Eher ja. Es verschlechtert die Wartbarkeit des Codes.
zu 11.: Damit das Control auch weiß, dass diese Sub aufgerufen wurde.

1. Ja.
2. Ja.
3. Ja.
4. Implements verwendest du, wenn du in einer Klasse ein Interface implementieren möchtest, und Inherits, wenn du eine Klasse beerben möchtest.
5. Private heißt, nur die Klasse selbst kann darauf zugreifen, bei Protected kann die Klasse und ihre Erben darauf zugreifen, Friend heißt, man kann nur innerhalb des Projektes darauf zugreifen und bei Public kann man von überall darauf zugreifen. Shared kennzeichnet Member, die nicht von einer Instanz abhängig sind.
6. Ja.
7. Im Prinzip ja, allerdings können neben Klassen auch Strukturen Interfaces implementieren, die dann ebenso für eine Zuweisung gültig sind.
8. Lieber Überladungen, ist einfacher zu verwalten und sieht in IntelliSense besser aus.
9. Nein. Listen oder andere Auflistungen immer nur verwenden, wenn du sie wirklich brauchst, denn Arrays sind schneller.
10. Theoretisch nicht, aber es macht Dinge eher komplizierter. Geschachtelte Klassen sollte man nur verwenden, wenn die innerere Klasse Private ist, also nur die äußere klasse sie kennt. Soll die innere Klasse auch nach außen hin verfügbar sein, sollte man sie lieber einzeln stellen und dann lieber Namespaces zum Sortieren verwenden.
11. Die On...-Methoden in einer Klasse (können auch andere Klassen als (User-)Controls sein) lösen das entsprechende Event aus. Sie sind dafür da, dass eine abgeleitete Klasse die Events auslösen kann (weil über RaiseEvent gehts nicht, wie du vielleicht schon bemerkt hast) und auch, damit eine abgeleitete Klasse nicht das Event abonnieren muss (ist ein bisschen performanter so). Die Events existieren trotzdem und theoretisch kannst du sie auch abonnieren. MyBase... musst du dann immer aufrufen, damit das Event auch gefeuert wird, also du musst aus deiner neuen Implementierung die alte Implementierung, die du überdeckst, aufrufen. Wenn du das nicht tust, kann möglicherweise unvorhergesehenes Verhalten auftreten, weil notwendiger Code nicht ausgeführt wurde.

Shared hat nichts mit Private, Public etc. zu tun. Private, Public, Protected,... sind Zugriffsmodifizierer welche angeben ob und inwiefern auf etwas zugegriffen werden kann.
Shared gibt an, dass etwas nicht durch eine Instanz eines Objektes verfügbar ist sondern durch das Objekt bzw. den Typ an sich.

Außerdem noch kurz anzumerken. Wenn du eine schöne XML-Doku hast, kannst du diese auch extrahieren und so eine Art Doku-Datei generieren lassen. > wird dann sowas: de.wikipedia.org/wiki/CHM_(Dateiformat)

1) richtig
2) Sollte man nutzen ja.
3) richtig. Wenn du nun eine Methode machen würdest welche als Paramter eine Variable vom Typ IDisposable benötigt, kannst du jedes Objekt welches IDisposable implementiert übergeben (und hast innerhalb der Prozedur auch nur die Member des Interfaces)
4) Implements ist keine Vererbung sondern eine Implementiertung. Inherits ist Vererbung. Bei Vererbung übernehmen Klassen/Interfaces alle Member der Basis Klasse/Interface. Es gibt in .Net aber keine Mehrfachvererbung es ist jedoch möglich mehrere Interfaces zu implementier (Implements)
5) Private -> Nur innerhalb der Klasse zugreifbar; Protected -> Innerhalb der Klasse und vererbten Klassen zugreifbar; Friend -> In allen Klassen der Assembly (deines Projektes) verfügbar; Public -> Überall zugreifbar. Wenn etwas als Shared (statisch) beschrieben wird, benöigt man keine Instanz sondenr kann direkt darauf zugreifen (Bsp.: System.Io.File Methoden)
6) Du kannst eine Variable als Typ der Basisklasse deklareieren und eine Instanz einer Unterklasse erzeugen. Bsp.: Klasse A = Basis; Klasse B erbt von A

umgekehrt funktioniert das aber nicht
7) richtig
8) Schöner sind Überladeungen mMn.
9) Wüsste nicht wieso. Meistens kann man jedoch auf eine List(Of T) umsteigen.
10) Wer bestimmt falsch oder richtig? Wenn es eine Private Klasse ist spricht mMn nichts dagegen. Ist es einen Eigenständige find ich es schöner diese auszulagern
11) Mit MyBase rufst du die Methode der Basisklasse auf. Warum das aber bei UserControls so ist kann ich dir nicht sagen.

lg

8.: Optional. Die Befürworter von Überladung kommen aus der C# Ecke und da gibts das erst seit kurzem

stackoverflow.com/questions/25…parameters-in-c-sharp-4-0
Die Antwort von Jon Skeet ist recht ... erhellend. Insbesondere Punkt 2

Zu 10.
Es hat Sinn Klassen in Klassen zu erstellen. So kann man im Inneren z.B. mit irgendwelchen Template Wrappern arbeiten die von Außen nicht zugänglich sein sollen. Das gehört zur Kapselung, genauso wie die Public, Private und Protected Modifizierer. Kapselung ist zusammen mit Vererbung und Polymorphie das Grundprinzip der OOP. 3. Ist ein Beispiel für Polymorphie und Vererbung ist dir ja klar.

Zur Polymorphie kannste dir sowas nochmal angucken Type Eraser. Ich hab letztens irgendwo den Unterschied zwischen statischer und dynamischer Polymorphie erklärt find den Post aber nicht mehr. Kommt mir das nur so vor oder kommen in letzter Zeit oft solche Fragen ?

/Edit
Habs doch gefunden Polymorphie

ThePlexian schrieb:

Zu 8.: Aber Optional fordert Constants, egal ?

Egal, wenns nicht stört. Wenns stört, Overloads nehmen. Können, nicht müssen!

ThePlexian schrieb:

Zu 9.: Was sind Puffer ?

Die Dinger, die Daten z.B. beim Kopieren von Streams zwischenspeichern (puffern).

ThePlexian schrieb:

Zu 5.: Was ist mit den ganzen anderen Modifizierern (das Wort suche ich schon ewig) ? Friend zB.

Artentus schrieb:

Friend heißt, man kann nur innerhalb des Projektes darauf zugreifen

zu 5:

Artentus schrieb:

Friend heißt, man kann nur innerhalb des Projektes darauf zugreifen

zu 10:
Stell die Klassen einzeln. Wie ich schon sagte, sowas macht man eigentlich nur, wenn die innere Klasse nicht nach außen hin sichtbar ist.

Inwiefern Puffer ? Ein Puffer/Buffer ist allg. ne Zwischenspeicherung von Daten

Eine Klasse kann immer nur genau eine Basisklasse besitzen, aber mehrere Interfaces implementieren.

Jo. Auch wenn man nun Mehrfachvererbung zur Verfügung hat, also wenn eine Klasse soviele Basisklassen haben kann wie sie will, nutzt man immernoch Interfaces. Interfaces sind ein Mittel um Polymorphie zu vereinfachen

Gonger96 schrieb:

Jo. Auch wenn man nun Mehrfachvererbung zur Verfügung hat, also wenn eine Klasse soviele Basisklassen haben kann wie sie will, nutzt man immernoch Interfaces.

Und ich dachte, ich hätte neulich gelernt, in C++ gibts keine Interfaces, weil die Mehrfachvererbung hätten
Hat c++ doch Interfaces?

ErfinderDesRades schrieb:

Hat c++ doch Interfaces?

Streng genommen nicht. Nicht dass ich wüsste. Nichtsdestotrotz lassen sich mit C++ COM-Klassen erzeugen, und die haben Interfaces, aber das wird in C++ dann eher über midl gelöst.

@ErfinderDesRades
Interfaces haben wir schon, nur die Deklaration erfolgt als Klasse. Es sind also eigentlich Klassen, deren Methoden alle virtuell sind und = 0.
Das wär n Interface in C++. Für Vererbung braucht man die aber fast nie, da kommt eher die Mehrfachvererbung zum Zug und man hat mehrere Basisklassen

Gonger96 schrieb:

Interfaces haben wir schon, nur die Deklaration erfolgt als Klasse.

Na, sowas akzeptiere ich nicht, weil eine Vergewaltigung von Begrifflichkeit: "Interfaces haben wir nicht, aber haben wir doch, deklarieren sie aber als Klasse".

Korrekt ist (scheint zu sein): c++ benötigt keine Interfaces, sondern dort ist das OOP-Erfordernis "Vertraglichkeit" durch Mehrfach-Vererbung mit abgedeckt.
c++ tickt halt anners.