Halte das Beispiel nicht für gut geeignet.
Klassen braucht man eiglich nur, wenn man mehrere Objekte einer Klasse haben will.
Hier gibt es aber nur 1 Telefon und 1 AB - es wäre also garnet angezeigt, eine Klasse überhaupt zu entwickeln. Damit ist das mit den Events erst recht hinfällig.

Wie wärs mit einem Apfelbaum?
Sind viele Äppel dran, und die wachsen unterschiedlich schnell. Ab einem bestimmten Gewicht fallen sie runter. Vlt hat auch jeder Apfel sein eigenes individuelles Runterfall-Gewicht.

keine Klasse Baum, denn Baum ist wieder nur einer, daher nicht notwendigerweise eine Klasse.
Aber vonne Äppel gibts ja mehrere.

Und einfach anfangen: einfach nur verschiedene Äppel generieren, die mw. alle gleich wachsen, aber je bei verschiedenem Gewicht runterpurzeln.

Komplizierter kannstes jederzeit machen, mit Würmern, Jahreszeiten, Wirbesstürmen, Holzfällern und Auto-Unfällen.

@ErfinderDesRades ich denke es ist schon sinnvoll wenn man sich das OOP Konzept direkt angewöhnt auch wenn es nicht unbedingt notwendig wäre.

Was passiert wenn später eine "Wiese" mit mehreren Apfelbäumen hinzukommt??

Es macht schon sinn mit Objekten zu arbeiten auch wenn dies später nur 1x instanziiert wird.

shaebich schrieb:

ich denke es ist schon sinnvoll wenn man sich das OOP Konzept direkt angewöhnt auch wenn es nicht unbedingt notwendig wäre.

unbedingt.
Und dazu gehört auch die Fähigkeit, unterscheiden zu können, wann eine Klasse sinnvoll ist, und wann nicht.

Und klar - bei einer Streuobst-Wiese muss zusätzlich zur Apfel-Klasse auch eine Baum-Klasse her.

Ich finde grad so zeigt sich der Sinn von Klassen erst.
Und es zeigt sich, wie die Klassenstruktur etwas modelliert - Datenmodell - eines meiner Lieblings-Themen.
Und es zeigt sich, wie man erweitert, wenn weitere Anforderungen hinzukommen.

---

shaebich schrieb:

Es macht schon sinn mit Objekten zu arbeiten auch wenn dies später nur 1x instanziiert wird.

welchen denn?

Wie gesagt, wenn eine Wiese zu modellieren ist, dann braucht man die Baum-Klasse, weil dann hat man ja mehrere Bäume. Aber vorher nicht, und deshalb soll man sie vorher auch nicht programmieren.
Aus 2 Gründen

1. Du weißt nocht nicht, wie die Baumklasse dann wirklich aussehen muss, wenn sie denn nötig wird.
   
2. Vorauseilendes Programmieren kann ins Unendliche führen - warum nicht auch eine Wiese-Klasse? Und dann eine Gemarkungs-Klasse? Und eine Landkreis-Klasse? Bundesland-Klasse? Staat-Klasse? Welt-Klasse nicht vergessen! Sonnensystem! Universum! Multiversum! Multi-Multiversum!
   (Und das alles nur für paar blöde Äppel)
   

ErfinderDesRades schrieb:

Du weißt nocht nicht, wie die Baumklasse dann wirklich aussehen muss, wenn sie denn nötig wird.

Aber ich muss doch die Property und Funktionen die ein Baum hat sowieso implementieren. Wieso also nicht gleich sauber als Objekt bzw. eigene Klasse?

Ich sehe kein Nachteil darin, im gegenteil..dies entspricht absolut allem was man unter Kapselung verstehen sollte

Hä? In dem Modell kommt doch gar kein Baum vor - wassn für Properties willste da implementieren?

Die Nachteile hab ich doch schon genannt:

1. Die vorzeitige Implementation ist immer erstmal falsch.
   
2. Das Prinzip, iwas vorauseilend zu entwerfen, führt ins Unendliche - es gibt kein Kriterium, wo man damit aufhören sollte.
   
3. noch ein drittes: Wenn man so anfängt, erschwert man sich, den Sinn von Objekten zu verstehen: dass mehrere Objekte einer Klasse existieren können.
   Es gibt nunmal Objekte, und es gibt noch anderes. Sieh mal die Math-Klasse: So viel Funktionalität - und kein Objekt!
   

ein Baum, dem du eine List(Of Apfel) übergibst - der macht doch nichts, was die List(Of Apfel) nicht selbst könnte.

Nenn meinetwegen die List(Of Apfel) "Baum" - Nomen est Omen!Mach alles immer so einfach wie möglich.
Kompliziert wirds schon von ganz von selbst, da brauchst du keinerlei Extra-Bemühungen für hineinzulegen, mit Bäumen und was dir sonst noch einfällt.

Eine Klasse, die eigentlich gar keine eigene Aufgabe hat, ist ein Greuel, und macht Code unverständlicher als so mancher anderer Code-Horror.
Sinnloser, lauffähiger Code ist meist schlimmer, als wenn du einen richtigen Fehler drinne hast, der zumindest gelegentlich auftritt, und den man dann beheben kann.

schon ganz hübsch, aber wenn das nur bei einem Apfel bleibt...

Klar haut das damit hin - wieso sollte das nicht hinhauen?

Ich möchte nur nebenbei hinweißen das die Benamung von Klassen ohne "C", "c" am Anfang des Namens realisiert wird.

Mehr zu Naming Guidlines findest du hier: msdn.microsoft.com/en-us/library/0b283bse.aspx

zum Stil hätte ich auch noch was zu sagen, aber das heb ich mir auf für wenns läuft.

Die Liste hat doch bereits eine Count Eigenschaft. Count an der Apfelklasse macht für mich wenig Sinn, außer du hast dort irgendwie noch eine Auflistung der Kerne.

Keinesfalls hat ein Apfel eine Count-Property. Ein Apfel ist er selbst, er ist keine Auflistung.
Betrachte die Realität: Weiß ein Appel am Baum, wieviele annere Äppel da rumhängen?

Eine Auflistung hat eine Count-Property, wie gesagt: Mach nichts überflüssiges. List(Of Apfel) ist eine Auflistung, und hat auch eine Count-Property.
Noch eine Count-Property sich auszudenken kann nur Chaos stiften.

Ich hab dir den Code in post#10 doch schon gegeben, ist iwas nicht in Ordnung damit?

Edit: zu spät