Whiz-zarD

Antwort auf welche Frage? Ich sehe aber hier keine Frage.

Was genau möchtest du mit dem Code überhaupt erreichen? Wozu soll der gut sein? Was genau hast du dort vor? Lass uns teilhaben an deinen Ideen. Nur so können wir dir auch helfen. Wie @KeeperOfCoffee schon sagt, der Code ist unnötig.

Auch Visual Basic 6 ist Objektorientiert und die Forms funktionieren genauso, wie jede andere heutige grafische Oberfläche. Selbst Spiele funktionieren nach diesem Prinzip. Die Endlosschleife nennt sich dort Game Loop. Dir fehlen nicht nur die Grundlagen von C#, sondern die Grundlagen der Objektorientierung. Aber offenbar hast du es schon damals nicht verstanden, denn ansonsten würden wir hier nicht sitzen und dir die Grundlagen der Objektorientierung zu erklären und diese Grundlagen sind erstmal sprachenunabhängig. Ich glaube auch nicht mal, dass du ein Hallo Welt-Programm vollständig erklären kannst. Mir ist nicht klar, was du mit einer Klasse ResultWriter erreichen willst, die zudem noch eine Form ist? ResultWriter klingt für mich eher nach eine Klasse, die irgendwas in ein Stream (z.B. Datei) schreibt.

Ist halt nur schlecht, wenn der Kunde eine Dokumentation haben will, wie z.B. Kennzahlen berechnet werden.

Ich arbeite überwiegend mit Entwicklern, die so auf die 50 zugehen und da muss ich feststellen, dass viele doch ihren Antrieb verloren haben (wenn sie ihn jemals besessen haben) und sich auch gar nicht mehr weiterbilden wollen und lieber nur noch das machen wollen, was sie kennen. Da sind dann Spezialisten bei, die meinen, sie seien Schlauer als Microsoft und Oracle und bauen Datenbank-Features nach und verteufeln das yield return in C#, weil der Compiler zusätzlichen IL-Code drumherum baut und Microservices sind ja per Se schlecht, weil ist so aber produzieren fleißig Spaghetticode und von agilen Prozessen braucht man erst gar nicht reden, weil das ja nur Chaos bedeutet. Da bleibt man ja lieber beim Wasserfallmodell und fällt jedes Mal wieder auf die Fresse. Es sind gerade unsere Werksstudenten, die die Nerdigkeit in das Unternehmen bringen. Klar, entsprechen sie nicht mehr dem Klischee eines typischen Nerds. Einer baut in Fitnessstudio seine Muskeln auf und ein anderer läuft Marathons aber das ist nun mal der Wandel der Zeit und ich würde sagen, dass die heutigen Nerds doch aktiver sind, was ihre Freizeitgestaltung angeht und der typische Klischee-Nerd (im dunklen Keller hocken und D&D zocken) verdrängt wird.

Aus diesem Grund finde ich es nicht gerade sinnvoll, dass Anfänger gleich mit einer grafischen Oberfläche anfangen, denn das Wissen ist einfach nicht vorhanden, wie Events eigentlich funktionieren. Eine grafische Oberfläche läuft in einer Endlosschleife. In der Schleife werden jedes Mal die Eingabe entgegengenommen, verarbeitet und die Oberfläche neu gezeichnet. Ein Mausklick löst also im Grunde nicht das Event aus, sondern die Schleife befindet sich wieder an dem Punkt, wo sie die Eingabe überprüft wird und merkt, dass die Maustaste gedrückt wird. Schaut dann nach, ob ein Event implementiert wurde und wenn ja, dann wird die Implementierung aufgerufen. So ist es nun auch beim FileSystemWatcher. Es läuft eine Endlosschleife, die sich ein Stream mit Dateiänderungen anschaut und bei jedem Durchlauf wird geschaut, ob die letzte Dateiänderung mit deinen Filterkriterien, etc. übereinstimmt und dann schaut, ob das jeweilige Event implementiert wurde. Den FileSystemWatcher kannst du auch in einer Form verwenden. Beispiel: public Form1() { InitializeComponent(); FileSystemWatcher watcher = new FileSystemWatcher(@"D:\Test"); watcher.Changed += (sender, e) => textBox1.Text = $"Changed: {e.Name}"; watcher.Created += (sender, e) => textBox1.Text = $"Created: {e.Name}"; watcher.Deleted += (sender, e) => textBox1.Text = $"Deleted: {e.Name}"; watcher.Renamed += (sender, e) => textBox1.Text = $"Renamed: {e.OldName} => {e.Name}"; watcher.SynchronizingObject = this; watcher.EnableRaisingEvents = true; } Hierbei muss man aber wissen, dass die Endlosschleife in einem anderen Thread läuft als die Endlosschleife der grafischen Oberfläche und Änderungen an der UI darf nur der Thread der UI machen. Der FileSystemWatcher besitzt deswegen die Eigenschaft SynchronizingObject. Hier kann man das Objekt reinreichen, wer den FileSystemWatcher erzeugt hat und somit wird der Code über den UI-Thread ausgeführt. Der FileSystemWatcher steht sogar in der Toolbox zur Verfügung und kann per Drag'n'Drop in die Form geschoben werden. Dabei wird der FilesystemWatcher folgendermaßen initialisiert: // // fileSystemWatcher1 // this.fileSystemWatcher1.EnableRaisingEvents = true; this.fileSystemWatcher1.SynchronizingObject = this; this.fileSystemWatcher1.Changed += new System.IO.FileSystemEventHandler(this.fileSystemWatcher1_Changed); this.fileSystemWatcher1.Created += new System.IO.FileSystemEventHandler(this.fileSystemWatcher1_Created); this.fileSystemWatcher1.Deleted += new System.IO.FileSystemEventHandler(this.fileSystemWatcher1_Deleted); this.fileSystemWatcher1.Renamed += new System.IO.RenamedEventHandler(this.fileSystemWatcher1_Renamed); Das, was ich im oberen Code gemacht habe, kann man sich auch generieren lassen.

Einen Timer brauchst du nicht. Der FileSystemWatcher besitzt Events, die implementiert werden können, um auf Änderungen in einem Ordner zu reagieren. Mal ein simples Beispiel einer Konsolenanwendung: class Program { private FileSystemWatcher watcher; public Program() { this.watcher = new FileSystemWatcher(@"D:\Test"); this.watcher.Changed += (sender, e) => Console.WriteLine($"Changed: {e.Name}"); this.watcher.Created += (sender, e) => Console.WriteLine($"Created: {e.Name}"); this.watcher.Deleted += (sender, e) => Console.WriteLine($"Deleted: {e.Name}"); this.watcher.Renamed += (sender, e) => Console.WriteLine($"Renamed: {e.OldName} => {e.Name}"); this.watcher.EnableRaisingEvents = true; } static void Main(string[] args) { Program program = new Program(); Console.ReadKey(); } } Nun werden alle Änderungen im Ornder D:\Test angezeigt

SQL ist eigentlich nicht dafür bestimmt, Analysen auf Daten zu machen. Es ist eigentlich dafür gedacht, Daten aus einer Datenbank zu lesen. Ein DBMS besitzt aber in der Regel einige analytische Funktionen. Wie @sylenz schon richtig nachfragt, ist es wichtig zu wissen, welche DBMS du verwendest, da die analytischen Funktionen immer unterschiedlich implementiert sind. Falls du MySQL verwenden solltest, könnte man erst ab 8.0 mit den Funktionen RANK() bzw. DENSE_RANK() arbeiten. Ansonsten ist die Lösung von @PVoss die präferierte Lösung, wenn es reines SQL sein soll.

Allerdings würde ich das so nicht machen, denn das würde wieder gegen das Single-Responsibility-Prinzip verstoßen, weil die Addition-Klasse wieder für zwei Dinge zuständig ist. Die Ausgabe sollte auch in der Nähe der View angesiedelt sein und nicht in der Geschäftslogik. Angenommen, man will die Addition unterschiedlich darstellen. Dann müsste man ja mehrere Methoden in ICalculation und ehe man sich versieht, besitzt das Interface plötzlich 50 Methoden. Wenn man eine hübsche Ausgabe will, dann könnte man auch die benötigten Informationen zur Verfügung stellen und eine weitere Klasse bastelt aus den Informationen einen String.

Das stimmt nicht ganz. Stellt man den Taschenrechner auf "Wissenschaftlich", so kennt er auch eine Operatorreihenfolge.

Ich glaube, es wird echt mal Zeit, dass ich mein Artikel "Wie man einen Taschenrechner programmiert" veröffentliche. Du meinst wohl die (umgekehrte) polnische Notation. Genannt auch Postfix- und Präfix-Schreibweise. Eine Umwandlung von der bekannten Infix-Schreibweise in die Post-/Präfix-Schreibweise, lässt sich durch den Shunting-Yard-Algorithmus lösen. Das würde hier aber viel zu weit gehen.

Im Grunde haben wir schon alles, was wir brauchen. Wir haben doch das Interface ICalculation, dessen Methode Calculate() ein double zurückgibt, also ein Parameter für die Addition-Klasse. Wenn du drei Zahlen miteinander addieren möchtest, kannst du es ganz einfach machen: new Addition(new Addition(1,2).Calculate(), 3) Jetzt rechnet er 1 + 2 + 3.

File.AppendAllText() macht im Grunde nichts anderes, was du geschrieben hast: public static void AppendAllText(String path, String contents) { // ... InternalAppendAllText(path, contents, StreamWriter.UTF8NoBOM); } private static void InternalAppendAllText(String path, String contents, Encoding encoding) { // ... using (StreamWriter sw = new StreamWriter(path, true, encoding)) sw.Write(contents); } So sieht der Source Code im .NET Framework aus.

Genau

Es geht um das DRY-Prinzip (Don't Repeat yourself). Wenn du nicht nur die Addition implementieren willst, sondern auch noch weitere Rechenoperationen, dann brauchen sie ebenfalls left und right. Damit man beide Variablen nicht für jede Operation kopieren muss, habe ich sie in eine abstrakte Klasse ausgelagert und jede Operation erbt von dieser Klasse. So braucht man die beiden Variablen nur ein mal definieren. Abstrakte Klassen sind nicht instanziierbar. Du kannst also kein new BinaryCalculation() aufrufen. Das führt sofort zu ein Kompilierfehler. Abstrakte Klassen dienen für eine Basisimplementierung einer Funktionalität. Klassen, die dann von der abstrakten Klasse erben, implementieren dann die konkrete Fachlogik. Die Subtraction-Klasse wird dann einfach so aussehen: Public Class Subtraction Inherits BinaryCalculation Public Sub New(left As Double, right As Double) MyBase.New(left, right) End Sub Public Overrides Function Calculate() As Double Return Me.left - Me.right End Function End Class left und right braucht man ja nicht noch mal definieren, weil sie eben schon in BinaryCalculation definiert worden sind.

Viele Wege führen nach Rom. Allerdings ist das Problem von WinForms-Anwendungen, dass sie den Entwickler nicht an "die Hand nehmen". Eine Form sollte eigentlich nur die Logik besitzen, die auch für die Anzeige notwendig ist. Siehe das MVC (Model-View-Controller) bzw. MVP (Model-View-Presenter) oder für WPF-Anwendungen das MVVM (Model-Viel-ViewModel)-Pattern. Da es aber so schön einfach ist, ein Button in die Form per Drag'n'Drop in die Form zu schieben und dann mit einem Doppelklick das Event zu implementieren, sind diese Patterns nicht so ganz ersichtlich. Bei den Patterns wird die grafische Oberfläche von der Geschäftslogik getrennt. Der Grund ist einfach der, wenn man die Geschäftslogik von der grafischen Oberfläche trennt, kann man die grafische Oberfläche recht leicht austauschen. Angenommen du entwickelst eine WinForms-Anwendung und willst sie später in eine Web-Applikation überführen. Wenn die Geschäftslogik aber nun in der grafischen Oberfläche steckt, müsstest du die gesamte Anwendung neu schreiben. Lagert man sie hingegen in eine separate Klasse aus, so braucht man letztendlich im Idealfall nur die grafische Oberfläche austauschen. Man lagert also die Geschäftslogik in eine separate Klasse (der Controller) aus und die grafische Oberfläche (die View) kommuniziert über eine Schnittstelle mit der Geschäftslogik. Ein weiterer Grund für das Auslagern der Geschäftslogik ist wieder die Testbarkeit. Wenn du das Logging automatisch per Unittest testen möchtest, musst du wiederrum die Form-Klasse erzeugen und ein Klick auf den Button simulieren. Da die Events private sind, kannst du die Events nicht von Außen aufrufen. Dann muss man wieder andere Tools verwenden, die eine Anwendung automatisch starten und testen kann oder man muss mittels Reflection das Event ausführen aber das alles verkompliziert den Test und sollte vermieden werden und ist auch sehr fehleranfällig. Liegt das Logging aber in einer separaten Klasse, die von außen steuerbar ist, ist der Unittest mit drei Zeilen Code erledigt. Die LoggableCalculation-Klasse ist im Grunde auch nur ein Kompromiss, weil die Calculate()-Funktion nicht nur das Ergebnis berechnet und zurückgibt, sondern auch das Ergebnis loggt und somit auch gegen das Single-Responsibility-Prinzip verstößt aber es ist in dem Sinne ein Kompromiss, weil die Berechnung in einer separaten Klasse liegt und die LoggableCalculation-Klasse erweitert die Berechnung ums Logging. Dieses Vorgehen nennt sich auch Decorator-Pattern. Wenn du in deinem Beispiel das Ergebnis der Addition in eine Textdatei speichern möchtest, müsstest du im Grunde nur folgende Zeile Dim Addi As New Addition(2, 5) gegen Dim logger As New FileLogTraceListener With { .CustomLocation = "D:\", .BaseFileName = "test" } Dim LoggableCalculation As New LoggableCalculation(New Addition(2, 5), logger) austauschen. Visual Basic besitzt schon mehrere integrierte Logger. Der FileLogTraceListener ist ein Logger, der in eine Datei schreibt. Einen Standard-Logger könnte man über die app.config-Datei konfigurieren und per My.Application.Log aufrufen aber ich erzeuge hier mal eine eigene Instanz von einem Logger, weil es sonst zu weit führen würde. Die LoggableCalculation-Klasse sieht dann wie folgt aus: Public Class LoggableCalculation Inherits ICalculation Private ReadOnly calculation As ICalculation Private ReadOnly logger As TraceListener Public Sub New(calculation As ICalculation, logger As TraceListener) Me.calculation = calculation Me.logger = logger End Sub Public Overrides Function Calculate() As Double Dim result As Double result = Me.calculation.Calculate() Me.Log(result) Return result End Function Private Sub Log(result As Double) logger.WriteLine(result) End Sub End Class Wenn du dann die Calculate()-Funktion aufrufst, wird dann unter D:\ die Datei test.log erzeugt. Den Pfad und den Dateinamen kannst du im oberen Code anpassen. Wie du dann siehst, ist das Erzeugen der Log-Datei komplett unabhängig von der Form und ich könnte den Code somit auch z.B. in einer Konsolen-Anwendung verwenden: Sub Main() Dim logger As New FileLogTraceListener With { .CustomLocation = "D:\", .BaseFileName = "test" } Dim LoggableCalculation As New LoggableCalculation(New Addition(5, 3), logger) Console.WriteLine(LoggableCalculation.Calculate()) Console.ReadKey() End Sub Oder als Test (hier als Beispiel mit dem Unittest Framework von Microsoft): <TestClass()> Public Class UnitTest1 <TestMethod()> Public Sub Five_Plus_Two() Dim calculation As New Addition(5, 2) Assert.AreEqual(7.0, calculation.Calculate()) End Sub <TestMethod()> Public Sub Log_Five_Plus_Two() Dim calculation As New Addition(5, 2) Using logger As TraceListener = CreateTraceListener() Dim LoggableCalculation As New LoggableCalculation(calculation, logger) LoggableCalculation.Calculate() End Using Assert.AreEqual(True, File.Exists("D:\test.log")) Assert.AreEqual($"7{Environment.NewLine}", File.ReadAllText("D:\test.log")) End Sub Private Function CreateTraceListener() As TraceListener Return New FileLogTraceListener With { .CustomLocation = "D:\", .BaseFileName = "test", .Append = False } End Function End Class Ich kann hier also die gesamte Funktionalität testen, ohne dabei die Anwendung starten und auf den Button drücken zu müssen. Die Prozedur Five_Plus_Two() überprüft, ob das Ergebnis von 5 + 2 = 7 ist und Log_Five_Plus_Two() überprüft, ob eine Log-Datei geschrieben wurde und ob dort 7 drinnensteht. Unter Visual Studio sieht es dann so aus: So kann man auf Knopfdruck etliche Tests durchführen, ohne einmal die Anwendung gestartet zu haben. Das erleichtert das Leben erheblich, weil man so schnell Feedback bekommt, ob die Geschäftslogik funktioniert. Man muss sich dann nicht mühselig durch alle Buttons und Menüs klicken. Ob der Button allerdings das tut, was er auch soll, muss dann aber per manuellen Test herausgefunden werden aber ich habe die darunterliegende Funktionalität per Unittest getestet.

ICalculation ist keine Klasse, sondern ein Interface. Ein Interface definiert die Schnittstelle nach außen. Es ist quasi eine leere Hülle und gibt die Funktionen vor, die eine Klasse implementiert haben müssen. Deswegen ist es in meinem Beispiel dem Logger egal, was für eine Berechnung dahintersteckt, da alle Berechnungen das Interface implementieren und somit alle eben die Funktion Calculate() haben. Der Logger war von mir nur frei erwunden. Es gibt den in dieser Form nicht. Er war von mir nur ein abstraktes Beispiel, um die Prinzipien zu verdeutlichen und was passiert, wenn man weitere Features hinzufügen möchte. Wenn du etwas loggen willst, kannst du natürlich einen eigenen Logger schreiben. In Visual Basic bin ich aber leider nicht so firm drinnen, da ich mit C# arbeite aber ich denke mal, für Visual Basic gibt es auch schon fertige OpenSource-Logger, die man verwenden kann. Für C# gibt es z.B. NLog und NLog bietet von Haus aus über 30 verschiedene Möglichkeiten, etwas zu loggen (z.B. auf die Konsole, als Textdatei, als E-Mail, in eine Datenbank, in Slack, ...) und wenn das nicht reicht, der kann weitere hinzuprogrammieren.

Wie gesagt, ich kenne mich mit MS SQL nicht aus, da ich hauptsächlich mit Oracle Database zu tun habe. Dort gibt es die sog. Table Functions. Also eine Funktion, in der du Parameter reinreichen kannst und dir eine Tabelle zurückliefert. Unter MS SQL scheint sowas unter dem Begriff "Table-Valued Functions" zu geben. https://www.codeproject.com/Articles/167399/Using-Table-Valued-Functions-in-SQL-Server

Ich vermute mal, dass jeder Tag zwischen den beiden Daten ausgewiesen werden soll. Also: ID Datum Von Bis 1 01.01.2000 01.01.2000 10.01.2000 1 02.01.2000 01.01.2000 10.01.2000 1 03.01.2000 01.01.2000 10.01.2000 1 04.01.2000 01.01.2000 10.01.2000 1 05.01.2000 01.01.2000 10.01.2000 1 06.01.2000 01.01.2000 10.01.2000 1 07.01.2000 01.01.2000 10.01.2000 1 08.01.2000 01.01.2000 10.01.2000 1 09.01.2000 01.01.2000 10.01.2000 1 10.01.2000 01.01.2000 10.01.2000 Sowas ist mit reinem SQL nicht möglich, da SQL auf der Menge arbeitet, die in der Datenbank stehen. Du willst hier aber neue Zeilen dazudichten. Sowas würde höchstens mit einer Stored Procedure gehen. Ich kenne mich aber mit MS SQL nicht wirklich gut aus und weiß auch nicht, was man dort für Stored Procedure bauen könnte. Mit Oracles PL/SQL wäre es möglich.

Genau, die Methode macht einfach zu viel. Außerdem ist es sie schwieriger zu testen, da die Funktion nun eine sog. zyklomatische Komplexität von 5 hat. Das bedeutet, dass deine Funktion fünf Pfade hat, die durchlaufen werden können. Wenn du jetzt Unittests schreiben würdest, müsstest du mindestens 5 Tests schreiben, nur um diese eine Funktion zu testen. Du merkst auch vielleicht selber, dass du mit Return 0 ein Hilfskonstrukt bauen musstest, damit die Funktion funktionieren kann. Also zusätzliche Komplexität, die beim Lesen nur stört. Desweiteren verstößt diese Art von Porgrammierung gegen das sog. OpenClosed-Prinzip, da wir bei weiterer Funktionalität die Funktion modifizieren müssen. Angenommen, wir wollen auch noch Modulo-Operator implementieren. Dafür müssen wir dann die Funktion modifizieren. In meiner Variante muss nur eine neue Klasse angelegt werden. Das verhindert, dass der Entwickler, bei der Modifikation, Fehler einbaut, sodass andere Operationen plötzlich nicht mehr funktionieren. Da wir den Code nämlich nicht modifizieren, funktioniert alles so wie gehabt. Darüberhinaus ist der Funktionsaufruf nun auch noch schwerer zu lesen. Du verstehst vielleicht noch, was die 1 bedeutet aber jemand anderes weiß es nicht und ist entweder auf deine Dokumentation oder auf den Code angewiesen, um nachzuschauen. Sicherlich, die 1 könnte man auch noch gegen ein Enum austauschen, um es sprechender zu machen aber nicht desto trotz hast du die o.g. Probleme. Du musst nämlich eines bedenken: Ein Entwickler liest 80% seiner Tageszeit Code und in den restlichen 20% schreibt er Code und da sollte der Code so verständlich und einfach wie möglich sein. Das ist zwar schon alles auf einen höheren Niveau, was ich hier erzähle aber ich weiß noch, wie ich angefangen habe, zu entwickeln und für mich wären diese Informationen damals echt Goldwert gewesen. Wenn du es am Anfang nicht verstehst, ist es auch in Ordnung. Softwareentwicklung ist nun mal eine Gratwanderung und in jeder Situation muss man neu abschätzen, welcher Weg am sinnvollsten ist. Es kommt sogar sehr häufig vor, dass man sich verzettelt und sein Plan über den Haufen schmeißen muss, weil eine Situation kommt, an die man nicht gedacht hat. btw. die ganzen Prinzipien, die ich genannt habe, sind unter dem Begriff SOLID-Prinzipien zusammengefasst. SOLID steht für: Single-Responsibility-Prinzip Open-Closed-Prinzip Liskovsches Substitutionsprinzip Interface-Segregation-Prinzip Dependency-Inversion-Prinzip

Kann man machen, würde ich aber nicht tun. Methoden, die statische Methoden aufrufen, sind schwerer zu testen, weil man die statische Methode mittestet. Besonders wenn die statische Methode Fehler verursachen kann, wird es sehr problematisch, da die Lokalisierung des Fehlers aufwendiger wird, da der Fehler ggf. in der statischen Methode aufgetreten ist. Beispiel: Man möchte, dass die Berechne()-Funktion nicht nur das Ergebnis zurückliefern soll, sondern das Ergebnis soll in eine Log-Datei geschrieben werden und beim Schreiben in die Log-Datei könnten Probleme auftreten. Außerdem würde so eine Klasse gegen das Single-Responsibility-Prinzip verstoßen, weil sie zwei Dinge macht: Zwei Zahlen addieren Ergebnis loggen Ich persönlich meide statische Funktionen/Methoden so weit, wie es geht. So umgeht man viele Probleme. Ich hab angefangen Klassen so zu schreiben, sodass sie von Außen kaum gesteuert werden. Die Additionsklasse hätte ich wie folgt geschrieben: Public Class Addition private ReadOnly left As Double private ReadOnly right As Double Public Sub New (left As Double, right As Double) Me.left = left Me.right = right End sub Public Function Calculate() As Double Return Me.left + Me.Right End Function End Class Das hat jetzt den Vorteil, dass man die Calculate()-Funktion in ein separates Interface ablegen kann, was jede erdenkliche Art von Berechnungen implementieren könnte, wenn wir weiterdenken, als die vier Grundrechenarten. z.B. Quadratwurzel, Sinus, Cosinus, Tangens, etc. Darüber hinaus könnte man noch die Variablen left und right in eine abstrakte Klasse abstrahieren, weil sie auch für die anderen drei Grundrechenarten benötigt werden und wir somit das DRY-Prinzip einhalten. Das ganze Konstrukt könnte dann so aussehen: Public MustInherit Class ICalculation MustOverride Function Calculate() As Double End Class Public MustInherit Class BinaryCalculation Inherits ICalculation Protected ReadOnly left As Double Protected ReadOnly right As Double public Sub New (left As Double, right As Double) Me.left = left Me.right = right End Sub End Class Public Class Addition Inherits BinaryCalculation Public Sub New(left As Double, right As Double) MyBase.New(left, right) End Sub Public Overrides Function Calculate() As Double Return Me.left + Me.right End Function End Class Die Klassen für Subtraktion, Multiplikation und Division würden analog so aussehen, wie die Addition-Klasse. Eine Klasse für einen Logger könnte so aussehen: Public Class LoggableCalculation Inherits ICalculation Private ReadOnly calculation As ICalculation private ReadOnly logger As Logger Public Sub New(calculation As ICalculation, logger As Logger) Me.calculation = calculation Me.Logger = logger End Sub Public Overrides Function Calculate() As Double Dim result as Double result = Me.calculation.Calculate() Me.Log(result) Return result End Function private Sub Log(result As Double) If(Not Me.logger Is Nothing) logger.Log(result) End If End Sub End Class Es ist dem Logger nun egal, ob es eine Addition oder die Berechnung zur Weltherrschaft ist, solange calculation das ICalculation-Interface implementiert. Somit könnte man die Berechnungen und den Logger isoliert testen.

Du schmeißt hier Begriffe etwas durcheinander. "Vererben" bedeutet was anderes. Vererben ist, wenn eine Klasse von einer anderen Klasse erbt. Beispiel: Public Class BonusAddiere Inherits Addiere public Function BerechneBonus() As Integer Return MyBase.Berechne() * 2 End Function End Class Die Klasse BonusAddiere erbt von Addiere (achte auf das Schlüsselwort Inherits). Die Methode BerechneBonus() holt sich das Ergebnis von Berechne() aus der Basisklasse und multipliziert diesen Wert mit 2. Die Vererbung ist einer der Grundkonzepte der Objektorientierung, die du verstanden haben solltest, wenn du mit einer objektorientierten Sprache arbeiten möchtest. Die Zeile Dim add As New Addiere Erstellt nur ein Objekt der Klasse Addiere, und weist es der Variable add zu. In anderen Programmiersprachen (z.B. C#) würde es so aussehen: var add = new Addiere(); Da wird es vielleicht ein bisschen deutlicher, dass wir hier nur eine Variable mit dem namen add definieren, die als Wert ein Objekt von Addiere bekommt.

Deine Prozedur ShowErgebnis() ist schon mal nicht richtig. Es muss eine Funktion sein, die eben zahl1 und zahl2 addiert und das Ergebnis zurückgibt. Dann kannst du in der Prozedur Button3_Click() einfach das Ergebnis einer TextBox zuweisen. Public Class Addiere Public Property Zahl1 As Integer Public Property Zahl2 As Integer Function Berechne() As Integer Return Zahl1 + Zahl2 End Function End Class Private Sub Button1_Click(sender As Object, e As EventArgs) Handles Button1.Click Dim add As New Addiere add.Zahl1 = 5 add.Zahl2 = 3 TextBox1.Text = add.Berechne() End Sub Deine Addieren-Klasse sollte nicht dafür zuständig sein, das Ergebnis in die Textbox zu schreiben. Sie sollte nur das Ergebnis zurückliefern und die Anzeige in der Textbox sollte die Klasse übernehmen, die es auch braucht. Ansonsten ist deine Addieren-Klasse abhängig von der TextBox und die Klassen sollten so unabhängig wie möglich sein.

So, wie ich das sehe, unterstützt MobyDick doch tel:// sip:// und callto:// URIs.

Lass mich raten: Java ist langsam und unsicher. Stimmt's?