Dein Blog Beispiel passt ja hervorragend... Natürlich hast du, zumindest jetzt, nur einen Blog. Aber was, wenn du morgen einen weitern willst. In der OO bist du da prinzipiell besser beraten.
Aber bleiben wir mal bei einem Blog. Der besteht doch aus mehreren Einträgen, welche an den gleichen Blog gehaftet sind. Dafür sollte jeder Eintrag als ein einziges Objekt dargestellt werden. Der Blog selbt beinhaltet dann, neben Blog spezifischen Eigenschaften wie Farbe, dann eine Liste aller Blogeinträge. Willst du den Blog darstellen, dann rufts du eine Methode
auf. Die Show Methode geht die Blog eigenen Einträge durch (z.B. als Collection vorliegend), prüft ob der Blogeintragsdatum innerhalb der Grenzen liegt
Code:
Blog.Items[i].Date betwenn from and til
und zeigt das Teil an:
Code:
print Blog.Items[i].Subject ;
Natürlich kannst du das auch anders lösen. Aber Murphy sagt, dass immer wieder Änderungen in deinem Blog eintreten werden. Zum Beispiel braucht es irgendwann eine Methode um die Einträge eines bestimmten Authors anzzuzeigen. OO gehst du hin, erstellst in der Blog-Klasse eine neue Methode (oder leitest sogar eventuell von der Blogklasse eine neue ab).
Code:
Blog.ShowFromAuthor(author)
geht dann wieder die Kollektion durch, prüft ob der Autor des Eintrags stimmt
Code:
if Blog.Item[i].Author == author
und wenn ja, so zeigst du den Beitrag an.
Dein Beispiel mit der
DB Verbindung musst du mal etwas präzisieren. Aber prinzipiell hast du Recht, dass du gewisse Problematiken siehst bei der Gegenüberstellung tabellerarischer Daten (Datenbank) und einer dazu passenden objektorientierten Modellierung... Das ist nicht immer trivial, spätestens dann nicht mehr, wenn Relationen zwischen deinen Daten ins Spiel kommen.