Opened by der_thomas at 2013-10-13 11:26
User since
2006-07-10
2611 Artikel
BenutzerIn
2006-07-10
2611 Artikel
BenutzerIn
Es gibt ein paar Gründe für und gegen ein Interface, also eine klar definierte Schnittstelle zwischen zwei Programmteilen oder Programmen.
Ein Vorteil ist die Wiederverwendbarkeit. Ein einmal nach dem Interface geschriebener Code kann immer wieder an verschiedenen Stellen neu eingesetzt werden.
Dann die Reimplementierbarkeit. Der Code hinter einem Interface kann ausgetauscht werden, ohne die restliche Applikation verändern zu müssen.
Die Dokumentierbarkeit ist auch ein Vorteil. Eine Definiere Schnittstelle erklärt auch die Funktion eines Codeabschnitts.
Dagegen spricht das Interfacecode komplexer sein muss als nötig um seine Aufgabe zu erfüllen. So müssen übergebene Parameter geprüft werden, oder Funktionen für Eventualitäten bereit gestellt werden, die dort wo der Code eingesetzt wird niemals auftauchen werden.
Schnittstellen beschränken die Handlungsfreiheit des Programmierers und können dadurch zu schlechterem Code führen.
Um dein Codebeispiel heran zu ziehen. Es kann nötig sein nicht nicht nur immer eine Spalte weiter zu springen sondern auch gezielt eine Spalte an zuspringen, oder Spalten zu vergleichen, darin zu suchen, bestimmte Spalten zu löschen oder weitere einzufügen. Es hängt sehr von deinem Interface-Design ab wie sinnvoll deine "db" Anbindung funktioniert. Dein Interface hängt sehr am Konzept des Arrays, obwohl es dich eigentlich nicht interessiert, ob du es mit einem Array zu tun hast oder einer anderen Datenstruktur.
Du willst organisiert auf Daten zugreifen und dabei sollen die Daten nach bestimmten Kriterien organisiert sein. Eines dieser Kriterien soll die Gruppierung zu Datensätzen sein. Dabei sollen sie bestimmte Eigenschaften repräsentieren. Einer solcher Datensätze bildet also ein "Objekt" das ein bestimmtes Format aufweist das man als "Klasse" zusammen fassen kann. Viele dieser Objekte sind in einer eindeutigen Folge angeordnet und lassen sich darüber gezielt ansprechen. Aber ist diese Anordnung tatsächlich die beste Möglichkeit die Daten zu strukturieren? Hier ist wieder die Frage was willst du mit den Daten machen? Soll primär darin nach bestimmten Kriterien gesucht werden? Sollen sie nur gelistet werden? Sollen sie sortierbar sein? Das entscheidet die Struktur des Interfaces.
Du hast das schon mal programmiert und benutzt. Was hat dich daran gestört? Was fandest du Praktisch? Wo hast du dir gesagt "Zu dumm das ich das so programmieren muss." "Ob das auch eleganter geht?" "Ob das auch übersichtlicher geht?"
An deinem Beispiel wie man es auch machen kann:
Hier habe ich Wert auf ein einfaches und möglichst selbst erklärendes Interface gelegt. Man kann aus den Namensgebungen schon schließen was im Code passiert. Nachteil ist natürlich das viel im Code des db-Objekts gemacht werden muss. Wie du die Daten intern organisierst ist nicht wichtig, ob als "Array of Arrays" oder als "Array of Hashes" oder als "Array of Objects" oder anderes. Durch das recht hoch abstrahiere Interface kannst du alles dahinter nach gut dünken implementieren, oder auch verschiedenen Varianten um bestimmte Zugriffe zu beschleunigen. Aber diese hohe Abstraktion geht auf Kosten der Leistungsfähigkeit. Hinter dem Interace muss einiges gemacht werden, um die Befehle sinnvoll umzusetzen.
Ein Vorteil ist die Wiederverwendbarkeit. Ein einmal nach dem Interface geschriebener Code kann immer wieder an verschiedenen Stellen neu eingesetzt werden.
Dann die Reimplementierbarkeit. Der Code hinter einem Interface kann ausgetauscht werden, ohne die restliche Applikation verändern zu müssen.
Die Dokumentierbarkeit ist auch ein Vorteil. Eine Definiere Schnittstelle erklärt auch die Funktion eines Codeabschnitts.
Dagegen spricht das Interfacecode komplexer sein muss als nötig um seine Aufgabe zu erfüllen. So müssen übergebene Parameter geprüft werden, oder Funktionen für Eventualitäten bereit gestellt werden, die dort wo der Code eingesetzt wird niemals auftauchen werden.
Schnittstellen beschränken die Handlungsfreiheit des Programmierers und können dadurch zu schlechterem Code führen.
Um dein Codebeispiel heran zu ziehen. Es kann nötig sein nicht nicht nur immer eine Spalte weiter zu springen sondern auch gezielt eine Spalte an zuspringen, oder Spalten zu vergleichen, darin zu suchen, bestimmte Spalten zu löschen oder weitere einzufügen. Es hängt sehr von deinem Interface-Design ab wie sinnvoll deine "db" Anbindung funktioniert. Dein Interface hängt sehr am Konzept des Arrays, obwohl es dich eigentlich nicht interessiert, ob du es mit einem Array zu tun hast oder einer anderen Datenstruktur.
Du willst organisiert auf Daten zugreifen und dabei sollen die Daten nach bestimmten Kriterien organisiert sein. Eines dieser Kriterien soll die Gruppierung zu Datensätzen sein. Dabei sollen sie bestimmte Eigenschaften repräsentieren. Einer solcher Datensätze bildet also ein "Objekt" das ein bestimmtes Format aufweist das man als "Klasse" zusammen fassen kann. Viele dieser Objekte sind in einer eindeutigen Folge angeordnet und lassen sich darüber gezielt ansprechen. Aber ist diese Anordnung tatsächlich die beste Möglichkeit die Daten zu strukturieren? Hier ist wieder die Frage was willst du mit den Daten machen? Soll primär darin nach bestimmten Kriterien gesucht werden? Sollen sie nur gelistet werden? Sollen sie sortierbar sein? Das entscheidet die Struktur des Interfaces.
Du hast das schon mal programmiert und benutzt. Was hat dich daran gestört? Was fandest du Praktisch? Wo hast du dir gesagt "Zu dumm das ich das so programmieren muss." "Ob das auch eleganter geht?" "Ob das auch übersichtlicher geht?"
An deinem Beispiel wie man es auch machen kann:
Code (perl): (dl
)
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25
my %dbconf=( db_file => 'buecher.db', row_names => qw(Autor Titel Jahr Seiten), auto_update => 0, ); my $db = db->new(%dbconf); if(my $elm=$db->get_first_eq('Autor','Orwell')) { $elm->set('Autor','George Orwell'), $db->update(); } for my $elm ($db->get_all_regexp('Autor',qr/georg/i)) { print join( ',', $elm->get('Titel','Jahr','Autor') )."\n"; } my $first=$db->get_by_pos(100); die("Zeile 100 existiert nicht!") unless defined $first; print $first->get('Titel')."\n"; my $next=$elm; while( $next = $next->next() ){ if( ! $next->equal($elm) ) { print $next->get('Titel')."\n"; } }
Hier habe ich Wert auf ein einfaches und möglichst selbst erklärendes Interface gelegt. Man kann aus den Namensgebungen schon schließen was im Code passiert. Nachteil ist natürlich das viel im Code des db-Objekts gemacht werden muss. Wie du die Daten intern organisierst ist nicht wichtig, ob als "Array of Arrays" oder als "Array of Hashes" oder als "Array of Objects" oder anderes. Durch das recht hoch abstrahiere Interface kannst du alles dahinter nach gut dünken implementieren, oder auch verschiedenen Varianten um bestimmte Zugriffe zu beschleunigen. Aber diese hohe Abstraktion geht auf Kosten der Leistungsfähigkeit. Hinter dem Interace muss einiges gemacht werden, um die Befehle sinnvoll umzusetzen.