Ich würde immer sooft wie möglich Beispiel01 nehmen. Die Daten, die andere nix angehen, sollten Private sein. Sonst könnte ja jeder Hinz und Kunz die Klassendaten ändern. Encapsulation ist eines der Programmierprinzipien. Eine Klasse sollte nur so viele Infos wie nötig von sich preisgeben. Eine direkte Manipulation von Feldern (also Klassenmembervariablen) sollte unterbleiben. Tell, don't ask ist auch so ein Prinzip. Man soll ne Klasse nicht nach Daten fragen, sondern einen Befehl geben, dass bestimmte Sachen gemacht werden sollen. Stell Dir vor, dass Du n Bankkonto programmierst. Schwupps - kommt ein Verbrecher und ändert seinen Kontostand auf Integer.MaxValue.

oobdoo schrieb:

Wann trennt man am besten die Daten vom dazugehörenden Code?

Komische Frage.
Mir geht es bei Daten nicht darum Code und Daten zu trennen, sondern es geht darum, eine Datenmodell zu schaffen, was der Realität entspricht.
Da kann einmal eine Beispiel01-ähnliche Struktur angemessen sein, mal eine Beispiel02-ähnliche.
Aber beide Beispiele sind eiglich total ungeeignet, weil es gibt keine Realität, die in irgendeiner Weise einem Class1 oder Class2 ähneln könnte.

Denk dir was konkretes aus - wie würdest du etwa MichaHo's neuliches Problem modellieren: Ein Kampfsportverein mit Mitgliedern, und die Mitglieder haben KarateGürtel verschiedenen Ranges.
Über sowas kann man reden, und aufzeigen, wie ein Datenmodell stimmig ist, und wie nicht.

@ErfinderDesRades Jou: Komische Frage.
@oobdoo Nicht Daten und Code trennen, sondern Daten und GUI trennen.
Datenhaltung in Datenklassen, diese verarbeiten in Datenverarbeitungsklassen und Daten präsentieren und manipulieren in der GUI.
Das bedeutet z.B.

• Eine TextBox ist kein Speicherort für einen RW-String, sondern eine String-Variable, die zur Anzeige und zum Bearbeiten einer Textbox zugewiesen wird.
  
• Ein DataGridView ist kein Control zum Speichern einer Tabelle, dafür gibt es eine DataTable. Weise diese dem DGV als DataSource zu
  
• usw.