Funktionen zusammenfassen? (gelöst) (Allgemeines zu Perl)

[thread]18857[/thread]

Funktionen zusammenfassen? [gelöst]

Tags: perl5 Ähnliche Threads

Leser: 27

Articles: hide open all | hide show old branches

+24 replies
der_thomas

2014-01-19 12:34
User since
2013-09-07
158 Artikel
BenutzerIn
Ich habe eine Frage (die mir schon länger unter den Nägeln brennt ;) ) bezüglich der 'richtigen' oder besser 'best-practice-mässigen' Zusammenfassung von Funktionen.

Momentan arbeite ich an einem kleinen Modul dass mir zweidimensionale Arrays als eine art Datenbank verwaltet.

Nun ergibt sich immer wieder der Fall dass ich ganz ähnliche Funktionen habe die fast das gleiche machen.

Z.B. soll das Modul in der Lage sein ein bestehendes zweidimensionales Array um ein weiteres zweidimensionales Array
zu ergänzen.
Aus (["Hubert", "Mayer"], ["Laura", "Dern"])
und (["Petra", "Müller"], ["Karl", "Bauer"])
soll also ein (["Hubert", "Mayer"], ["Laura", "Dern"], ["Petra", "Müller"], ["Karl", "Bauer"]) werden.

Das was angefügt werden soll, kann wie oben direkt (als Argument) übermittelt werden, oder aus eine Textdatei stammen oder aus einer binären Datei (Storable).

Dementsprechend habe ich 3 Funktionen:
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 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43

sub join_raw{ sort_datasets($#{$testliste[0]}-1); cut_column(-1); # Indexspalte löschen cut_column(-1); # laufende Nummer löschen @testliste = (@testliste,@_); add_column("extensions"); } sub join_sto{ my $dateiname = shift; sort_datasets($#{$testliste[0]}-1); cut_column(-1); # Indexspalte löschen cut_column(-1); # laufende Nummer löschen my @temp = @testliste; @testliste = (); load_sto($dateiname); cut_column(-1); # Indexspalte löschen cut_column(-1); # laufende Nummer löschen @testliste = (@temp, @testliste); add_column("extensions"); } sub join_txt{ my $dateiname = shift; sort_datasets($#{$testliste[0]}-1); cut_column(-1); # Indexspalte löschen cut_column(-1); # laufende Nummer löschen my @temp = @testliste; @testliste = (); load_txt($dateiname); cut_column(-1); # Indexspalte löschen cut_column(-1); # laufende Nummer löschen @testliste = (@temp, @testliste); add_column("extensions"); }
Wie man sieht ist das nicht gerade DRY ;)
Aber schön übersichtlich und von der Aufteilung auf drei Funktionen her eventuell der übliche Weg, oder so wie man es als Benutzer erwarten würde ?
(Um weniger DRY zu schreiben könnte ich natürlich weitere kleine modulinterne Subroutines schreiben, aber ob das in dem Fall der richtige Weg ist...dadurch würde es dann an anderer Stelle unübersichtlich ? 'Wasserbett')

Kürzer ginge es wenn ich nur eine join Funktion hätte:
join(raw/txt/sto, @array/Dateiname)
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

sub join { my $art = shift; sort_datasets($#{$testliste[0]}-1); cut_column(-1); # Indexspalte löschen cut_column(-1); # laufende Nummer löschen if ($art eq "txt" or $art eq "sto"){ my $dateiname = shift; my @temp = @testliste; @testliste = (); load_sto($dateiname) if $art eq "sto"; load_txt($dateiname) if $art eq "txt"; cut_column(-1); # Indexspalte löschen cut_column(-1); # laufende Nummer löschen @testliste = (@temp, @testliste); } else { @testliste = (@testliste,@_) } add_column("extensions"); }
Auch wenn die Codewiederholung im ersten Beispiel extrem- und bei den folgenden Funktionen erheblich geringer ist, stellt sich die oben gestellte Frage auch hier:

Daten laden ....per @liste, txt oder sto....load_txt("dateiname") vs load("txt","dateiname")
Daten speichern ....per sto oder txt
In der Liste bewegen .....get(">") vs get_next() u.s.w.
Zählen der Datensätze per get_counter_all und get_counter_found vs get_counter("all") bzw. get_counter("found")
add_column("leer") und add_column("extensions") vs add_column("leer") und add_extensions()
("extensions" fügt jedem Datensatz eine laufende Nummer und einen Index (1) an)

Weltbewegend ist die Codewiederholung hier an dem Beispiel natürlich nicht, die Wartbarkeit leidet darunter auch nicht weil ja fast nur modulinterne Funktionen aufgerufen werden und das Ganze eh trivial ist.
Es geht mir mehr darum was vom Stil her besser ist oder der üblichere Weg ist:
Weniger 'mächtigere' Funktionen oder viele kleine Funktionen ......oder je nachdem mal so, mal so....wodurch das Ganze nicht mehr so konsistent wäre ?

thomas
- +8 replies
- rosti
  
  2014-01-19 12:50
  User since
  2011-03-19
  3470 Artikel
  BenutzerIn
  Datenhaltung raus aus dem Code, abstrahieren. Ich verwende Hashes anstelle von Arrays. Da ist z.B. sowas möglich:
  
  Code: (dl )
  
  %common = (%aus_DB, %aus_Datei);
  
  Hashes erlauben dann den direkten Zugriff auf Skalare oder weitere Referenzen über den Schlüssel, der dann auch überschrieben werden kann.
  
  Oder einfach den DAL umschalten, ist $self->{DBH} definiert, kommt die Konfiguration aus MySQL, ist $self->{DBF} definiert, kommt der Datenhash aus einem Storable-Derivat, sind beide definiert, wird alles gemerged.
  
  PS: Die Frage ist doch eher: Wie fasse ich Datenstrukturen zweckmäßig zusammen. Die Methoden/Funktionen sind nur Mittel zum Zweck.
  Last edited: 2014-01-19 13:25:18 +0100 (CET)
  - +7 replies
  - der_thomas
    
    2014-01-19 14:15
    
    User since
    2013-09-07
    158 Artikel
    BenutzerIn
    
    Wie ich schon schrieb, das was man oben sieht ist in einem Modul...das der Datenhaltung dient, das mir sozusagen die ganzen 'Innereien' erledigt.
    
    Und dieses Modul wird vom Frontend per Funktionsaufrufen gesteuert - und die Frage ist, oder war, inwieweit man da Funktionen zusammenfassen sollte oder wie man diese Funktionen also am zweckmässigsten vom Frontend aus gesehen darstellen sollte.
    
    Ob ich dass dann intern im Daten-Modul mit Hashes erledige hat mit meiner Frage, meiner Meinung nach, erstmal nichts zu tun.
    - +6 replies
    - rosti
      
      2014-01-19 14:49
      
      User since
      2011-03-19
      3470 Artikel
      BenutzerIn
      
      Quote
      Und dieses Modul wird vom Frontend per Funktionsaufrufen gesteuert - und die Frage ist, oder war, inwieweit man da Funktionen zusammenfassen sollte oder wie man diese Funktionen also am zweckmässigsten vom Frontend aus gesehen darstellen sollte.
      
      Perltie. Binde eine Datenstruktur (Array, Hash) an eine Klasse. Damit kannst Du über die gebundene Variable Methoden der Klasse aufrufen. Z.B. könnte eine Methode zum Zurückschreiben der Daten immer write() heißen, egal ob das in eine Datei geht oder in eine DB. Oder setze eine automatische Speicherung, wenn die gesetzt ist, erfolgt das Zurückschreiben automatisch im Destruktor ohne dass explizit write() aufgerufen wird.
      - +5 replies
      - der_thomas
        
        2014-01-19 19:58
        
        User since
        2013-09-07
        158 Artikel
        BenutzerIn
        
        Ich beschäftige mich seit Mitte Dezember etwas ernsthafter mit Perl und bin erstmal sehr froh das so wie es jetzt ist hinbekommen zu haben. Der Grund weswegen ich dieses Modul geschrieben habe ist eine kleine Bücherdatenbank, und die läuft auch schon und ist sozusagen testweise produktiv im Einsatz.
        
        Was OOP anbetrifft...soweit bin ich noch nicht bzw. habe ich dazu noch kein (für den Anfang möglichst deutschsprachiges) Tutorial gefunden.
        Ich weiß noch nicht mal ob ich da das komplette Array als ein Objekt oder jeden einzelnen Datensatz als Objekt implementieren sollte/müsste/könnte ;)
        
        thomas
        
        +4 replies
        
        rosti
        
        2014-01-19 22:23
        
        User since
        2011-03-19
        3470 Artikel
        BenutzerIn
        
        Ein Objekt kann auch ein Array sein, nur Mut zu OOP! Es gibt auch TIEARRAY, TIESCALAR. Gerade die tie()-Sache hat es in sich. Da hab ich auch ne Weile gebraucht, den Sinn zu verstehen. Datenzugriffe könne sogar soweit abstrahiert werden, dass bei einem
        
        Code (perl): (dl )
        
        tie @rray, 'ArrayClass';
        
        das @rray gar keine Daten enthält, die einzelnen Elemente werden erst bei einem Zugriff auf das Array aus einer Datei oder DB geladen. Der Möglichkeiten gibt es viele, hier creativ zu werden.
        
        Viel Spaß mit Perl ;)
        
        PS:
        
        Code (perl): (dl )
        
        1 2 3
        
        tie my @book, 'Prosa', genre => 'Gute Nacht Geschichten'; read $book[0]; say 'good night';
        
        Last edited: 2014-01-19 22:26:16 +0100 (CET)
        
        +2 replies
        
        Muffi
        
        2014-01-20 10:06
        
        User since
        2012-07-18
        1465 Artikel
        BenutzerIn
        
        Also mit tie würd ich sehr vorsichtig sein.
        Es gibt sehr wenig Fälle wo tie mehr nützt als verwirrt.
        1 + 1 = 10
        
        rosti
        
        2014-01-20 12:12
        
        User since
        2011-03-19
        3470 Artikel
        BenutzerIn
        
        2014-01-20T09:06:02 Muffi
        Also mit tie würd ich sehr vorsichtig sein.
        Es gibt sehr wenig Fälle wo tie mehr nützt als verwirrt.
        
        Dem stimme ich zu ;)
        Tie kann zum Performancekiller werden, weil bei jedem Zugriff auf ein gebundenens Array die Accessor-Methode FETCH() oder STORE() aufgerufen wird. Solche Flaschenhälse habe ich aber auch anderweitig gesehen, ganz ohne tie(), mit zuviel OOP-Philosphie ;)
        
        Es liegt immer am Gesamtkonzept. Genauso wie bei einem DB-Design es nicht immer sinnvoll ist, Relationen bis zur 3. Normalform zu bringen, sind zu komplexe Klassenstrukturen oft hinderlich, insbesondere dann, wenn ein neuer Kollege nicht Tage sondern Wochen braucht um dann die Erkenntnis zu gewinnen, dass der Datenaustausch zwischen den Klassen rein prozedural ist und OOP so ganz und gar nichts mehr zu tun hat.
        
        Eine Klasse alleine bewegt nichts.
        
        der_thomas
        
        2014-01-20 23:39
        
        User since
        2013-09-07
        158 Artikel
        BenutzerIn
        
        Quote
        Viel Spaß mit Perl ;)
        
        Danke, den habe ich - zumindest solange man mir meine globalen Variablen läßt ... kleiner Scherz, sorry der mußte jetzt einfach sein :-))
        
        Variablen ohne Sigils kommen mir inzwischen nackt vor und mit meinen besonderen 'Freunden', den geschweiften Klammern und Semilikons habe ich mich inzwischen auch arangiert ;) Ich entdecke jeden Tag was neues, ungewohntes, überraschendes... es wird mir also nicht langweilig :)
- +13 replies
- Raubtier
  
  2014-01-19 14:05
  
  User since
  2012-05-04
  1075 Artikel
  BenutzerIn
  
  Ich würde da wohl Funktionen schreiben, die für wirklich jeweils nur eine der Sachen, die du insgesamt machen willst, aufgerufen werden.
  
  Im Prinzip brauchst du eine Funktion, die dir übergebene Daten anhängt.
  
  Dann je eine Funktion, die die Daten aus der Textdatei bzw. von Storable liest. Diese Funktionen könnten dann die erste Funktion zum Anhängen aufrufen.
  
  Dann noch: verwende keine globalen Variablen. Alles, was irgendwie vom globalen State abhängt, ist schwierig zu testen und auch schwierig richtig zu machen. Insbesondere ist mir das bei cut_column, load_* und add_column aufgefallen. Das sollte zumindest noch die Daten mit übergeben bekommen, die es bearbeitet. Ich bin in der Regel auch ein großer Freund davon, wenn Funktion etwas zurückgeben und nicht irgendwas verändern.
  Last edited: 2014-01-19 14:08:02 +0100 (CET)
  - +12 replies
  - der_thomas
    
    2014-01-19 14:32
    
    User since
    2013-09-07
    158 Artikel
    BenutzerIn
    
    Quote
    Dann noch: verwende keine globalen Variablen....
    
    Ich weiß, man sollte das nicht machen ;)
    
    In dem Fall erkenne ich allerdings noch keine Möglichkeit wie das umzusetzen wäre, denn eine vielzahl der Funktionen wird (auch) von einem Frontend (GUI tk oder Konsole) aufgerufen....was bedeuten würde dass ich dieses Array ständig komplett wieder zurückgeben müsste. Und genau das wollte ich eigentlich vermeiden.
    Im Sinne einer Kapselung sollte dieses Array komplett nur in diesem Datenmodul sichtbar sein. Das Frontend bekommt normalerweise immer nur einen Datensatz (wie ["Hubert", "Mayer"]) zu sehen.....so zumindest meine Idee, als Laie....
    - +11 replies
    - Raubtier
      
      2014-01-19 14:41
      
      User since
      2012-05-04
      1075 Artikel
      BenutzerIn
      
      Es mag ja durchaus ok sein, wenn du genau eine interne globale Variable hast. Aber dennoch könntest du problemlos deine internen Funktionen so umbauen, dass sie diese explizit übergeben bekommen. Es gibt keine Ausrede dafür, so stark globale Variablen zu nutzen.
      
      Glaub mir, versuche mal einen Test zu schreiben. Eine Funktion, die keine globale Variablen nutzt, ist viel leichter zu testen. Du hast etwas das reingeht und etwas das rauskommt. Und das sollte immer gleich sein.
      
      Wenn du dann nach außen hin eine Funktion laden anbietest, die dann $neue_daten = datei_laden_intern($dateiname); push @globale_variable, $neue_daten oder ähnlich macht, wäre das alles kein Problem.
      
      Hast du schon einmal darüber nachgedacht, in deinem Modul objektorientiert zu arbeiten? Deine globale Variable wäre dann in dem Objekt gekapselt.
      - +10 replies
      - der_thomas
        
        2014-01-19 20:05
        
        User since
        2013-09-07
        158 Artikel
        BenutzerIn
        
        Nein, Ausreden gibts von mir keine ! Ich erkläre nur warum ich was wie gemacht habe, ist ja nicht so dass ich mir da keine Gedanken gemacht hätte ;)
        
        Mir erscheint es allerdings etwas eigenartig, wenn ein Frontend genau einen Datensatz zur Ausgabe bekommen soll - und dazu dann auch noch das komplette Array mitgeliefert bekommt, nur damit dieses dann beim Aufruf der nächsten Funktion wieder mitgegeben wird << dies alles nur um eine globale Variable zu vermeiden ?
        
        Vielleicht habe ich mich auch nicht klar genug ausgedrückt und wir reden hier, was den Sinn meines Moduls betrifft, ein wenig (sehr stark) aneinander vorbei ;)
        
        In OOP muss ich mich erst hinein-denken und arbeiten. Nur des OOP wegen jetzt auf die Schnelle eine Klasse zu bauen bringt vermutlich wenig. Einen wesentlichen Punkt von OOP, die Datenkapselung, Trennung von Frontend und Daten habe ich ja mit diesem Modul schon ereicht.
        
        +9 replies
        
        pq
        
        2014-01-20 11:10
        
        User since
        2003-08-04
        12208 Artikel
        Admin1
        
        2014-01-19T19:05:38 der_thomas
        Mir erscheint es allerdings etwas eigenartig, wenn ein Frontend genau einen Datensatz zur Ausgabe bekommen soll - und dazu dann auch noch das komplette Array mitgeliefert bekommt, nur damit dieses dann beim Aufruf der nächsten Funktion wieder mitgegeben wird << dies alles nur um eine globale Variable zu vermeiden ?
        
        du denkst offensichtlich noch nicht test-orientiert genug.
        es gibt gerechtfertigte fälle für globale variablen, aber man sollte sie vermeiden. ich kann nur immer wieder sagen, ich musste code übernehmen und pflegen, der hatte hunderte globaler variablen, und zum glück war meine aufgabe, das aufzuräumen, sonst wär ich verzweifelt.
        
        wenn dir das mit der parameter-übergabe zu umständlich vorkommt, wirst du vielleicht in OOP eine lösung finden.
        Always code as if the guy who ends up maintaining your code will be a violent psychopath who knows where you live. -- Damian Conway in "Perl Best Practices"
        lesen: Wie frage ich & perlintro brian's Leitfaden für jedes Perl-Problem
        
        Gast wer
        
        2014-01-20 12:31
        
        Kann ich nur bestätigen. Globale Variablen sind des Teufels.
        Ich habe hier kein Programm mit hunderten von globalen Variablen. Es sind nur fünf. Aber selbst das ist schon höllisch.
        Da verschwinden plötzlich Werte und tauchen wo anders wieder auf. Fehler sind nicht Reproduzierbar. Abläufe ändern sich sporadisch und nicht nachvollziehbar. Und richtig schön wird es wenn zwischendurch globale Variablen mit "local" überdeckt werden.
        Last edited: 2014-01-20 12:50:26 +0100 (CET)
        
        +7 replies
        
        der_thomas
        
        2014-01-21 00:20
        
        User since
        2013-09-07
        158 Artikel
        BenutzerIn
        
        Ja, so langsam dämmerts mir was ihr meint. Ich teste bisher die Funktionen einzeln und im Verbund nur da wo ich meine dass es Zusammenhänge geben könnte.
        Dass ich dabei natürlich schwer alle Eventualitäten austesten kann, stimmt natürlich.
        
        Was das Mitgeben meiner globalen Variablen(um diese zu vermeiden) betrifft, wäre das in meinem Fall gar nicht so umständlich aber ziemlich unnütz. Dafür ist die Struktur die ich da aufgebaut habe, in meinen Augen, ungeeignet.
        Zum Verständnis, falls die Struktur des Programms bisher missverständlich war, hier ein vereinfachtes Schaubild:
        
        Code: (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 26 27 28 29 30 31 32 33 34
        
        Frontend.pl Modul.pm *************************** ******************************** * I/O z.B. per Konsole * * Array hier global * * * * zeiger hier global * *-------------------------* *------------------------------* * * * * * lade Datei xy ----------load txt(xy)---> * Array = Datei xy #(10,20,30) * * * * zeiger = 0 * * * * * * * * * * * * * * get first (record) --------------get first--> * temp = Array[zeiger]--\ * * print temp #10 * <-------(temp)------------------------------/ * * * * * * * * * * * * * * temp = 4; put temp --------------put(temp)--> * Array[zeiger] = temp * * * * # Array[0] = 4 * * * * * * * * * * get next ----------------------get next---> * zeiger ++ * * * * temp = Array[zeiger]--\ * * print temp #20 * <-------(temp)------------------------------/ * * * * * *************************** ******************************** |Array und zeiger sind nur hier| |sicht- und veränderbar. | ---------------------> in diese Richtung wandern nur Funktionsaufrufe und ggf. veränderte Datenstätze <--------------------- in diese Richtung wandern nur Kopien einzelner Datensätze
        
        Was mir daran aber, trotz der globalen Variablen, nach wie vor sehr gut gefällt ist die Abstraktheit der Schnittstelle zwischen Frontend und Modul und dass eben das Frontend nie mit den Daten im gesammten in Berührung kommt.
        Und auch dass das Modul unverändert mit jeglicher Liste klarkommt, egal ob 2 Spalten und 500 Datensätze oder 40 Spalten und 3 Datensätze.
        Aber all das liese sich vermutlich auch in OOP umsetzen.
        
        Tja, dann werde ich mich mal an OOP herantasten, zuerst kommen aber die Hashes dran, um die ich bisher einen Bogen machte ;)
        
        thomas
        Last edited: 2014-01-21 08:26:56 +0100 (CET)
        
        rosti
        
        2014-01-21 08:00
        
        User since
        2011-03-19
        3470 Artikel
        BenutzerIn
        
        Quote
        Tja, dann werde ich mich mal an OOP herantasten, zuerst kommen aber die Hashes dran, um die ich bisher einen Bogen machte ;)
        
        Genau die wirst Du wohl Des Öfteren verwenden ;)
        Btw., Daten-Abstraktion, das Frontend muss überhaupt nicht wissen, ob die Daten aus einer DB oder aus einer Datei kommen.
        
        Viele Grüße!
        
        PS:
        Noch was zu tie(); http://rolfrost.de/tiezweck.html
        
        +5 replies
        
        Gast wer
        
        2014-01-21 16:19
        
        Objektorientiert:
        
        Code: (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 26 27
        
        Frontend.pl Modul.pm *************************** ********************************************* * I/O z.B. per Konsole * * Array Objekt variable * * * * zeiger Objektvariable * *-------------------------* *-------------------------------------------* * * * * * $obj = lade Datei xy --------Modul->load txt(xy)----> * $self=bless("Modul",{}) * * ^ * * $self->{Array} = lade Datei xy * * | * * $self->{zeiger} = 0 * * \--<--------------------------($self)-----------------/ * * * * * * * * * * * * * * $obj->get first (record) --------------get first----> * temp = $self->{Array}[$self->{zeiger}]--\ * * print temp * <-------(temp)--------------------------------------------------------/ * * * * * * * * * * * * * * temp = 4; $obj->put temp --------------put(temp)----> * Array[$self->{zeiger}] = temp * * * * # Array[0] = 4 * * * * * * * * * * $obj->get next ----------------------get next-----> * $self->{zeiger} ++ * * * * temp = $self->{Array}[$self->{zeiger}]--\ * * print temp * <-------(temp)--------------------------------------------------------/ * * * * * *************************** *********************************************
        
        Last edited: 2014-01-21 16:40:35 +0100 (CET)
        
        +4 replies
        
        der_thomas
        
        2014-01-21 20:44
        
        User since
        2013-09-07
        158 Artikel
        BenutzerIn
        
        Sehr schön, das ist genau die Vorgehensweise wie ich es in Python vor 6 Monaten gemacht habe.
        Irgendwie freut mich das ja, weil es meine damalige Vorgehensweise zu bestätigen scheint, aber ist das qualitativ wirklich besser ?
        Ich meine nein, denn der Zeiger ist in der Instanz genauso global wie in meinem Perlmodul.
        Bleibt das eigentliche Datenarray, das ist hier halt ein Objekt das von den Methoden genauso behandelt wird wie das globale Array im Perlmodul von den Funktionen.
        Die Fallgruben die man sich da ungewollterweise selber einbauen kann sind die selben.
        
        Das bezieht sich aber, damit das nicht missverstanden wird, nur auf eine OOP Umsetzung wie oben zu sehen und nicht auf OOP allgemein.
        Last edited: 2014-01-21 20:47:42 +0100 (CET)
        
        +3 replies
        
        Raubtier
        
        2014-01-22 20:36
        
        User since
        2012-05-04
        1075 Artikel
        BenutzerIn
        
        2014-01-21T19:44:20 der_thomas
        Irgendwie freut mich das ja, weil es meine damalige Vorgehensweise zu bestätigen scheint, aber ist das qualitativ wirklich besser ?
        Ich meine nein, denn der Zeiger ist in der Instanz genauso global wie in meinem Perlmodul.
        
        Ich meine ja. Denn dein Problem fängt an, wenn du mal mehrere Objekte gleichzeitig benutzen willst. In dem OOP-Fall ist ja alles in $self, also in der jeweiligen Variable gespeichert, daher ist es kein Problem, auch 2 Objekte zu erzeugen.
        
        In deinem Fall hast du das Modul aber nur einmal. D.h. wenn du versuchst, gleichzeitig 2 Instanzen vorzuhalten, wird das nicht gehen.
        
        +2 replies
        
        der_thomas
        
        2014-01-22 22:22
        
        User since
        2013-09-07
        158 Artikel
        BenutzerIn
        
        Ja, das schon....und auch die Möglichkeit der Vererbung, also spezialisierter Klassen die auf einen bestimmten Datentyp zugeschnitten sind und dementsprechende Methoden anfügen bzw. vorhandene überschreiben.
        
        thomas
        
        der_thomas
        
        2014-03-01 22:04
        
        User since
        2013-09-07
        158 Artikel
        BenutzerIn
        
        Hallo,
        
        nachdem mein hier Bisher beschriebenes Modul nun seit Wochen funktioniert, möchte ich das Ganze, nach den Denkanstößen hier, doch auch noch objektorientiert umsetzen.
        
        Nun wollte ich hier noch einmal nachfragen ob folgendes Konstrukt in euren Augen Sinn macht:
        
        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 26 27 28
        
        package Class; @liste =( ["Perl", "dyn", "Wall"], ["Java", "stat", "Gosling"], ["C#", "stat", "Hejlsb."], ["Python", "dyn", "Rossum"], ["C++", "stat", "Stroust."], ["Basic", "stat", "Kurtz"], ["Obj C", "stat", "Love"], ["Eifel", "stat", "Meyer"], ["Ruby", "dyn", "Mats"], ["PHP", "dyn", "Lerdorf"] ); my $listref = \@liste; sub new { my $classname = shift; my $self = { zeiger => 0, maxspalte => 2, #feste Anfangswerte nur hier zum Testen maxzeile => 9, #feste Anfangswerte nur hier zum Testen daten => $listeref }; return bless($self, $classname); }
        
        Die Namen wie "Class" fürs Package sind natürlich nur zum Testen, also nicht entgültig und der Array Inhalt würde natürlich auch nicht hartcodiert werden sondern aus einer Datei eingelesen bzw. per Argument vom Frontend übertragen- daher auch Zeile 16 und nicht schon ein anonymes Array in Zeile 3.
        
        Für die eigentlichen Daten verwendete ich ein Array und keinen Hash um flexibler zu sein ... bilde ich mir zumindest ein ;)
        
        thomas
        
        P.S. Es folgen noch ein paar Methoden zum Testen (im Originallistning, daher fehlt oben das 1; am Ende.
        Last edited: 2014-03-01 22:06:14 +0100 (CET)
- +2 replies
- Muffi
  
  2014-01-20 09:59
  
  User since
  2012-07-18
  1465 Artikel
  BenutzerIn
  
  Ich denke man muss da ein gutes Mittelmaß finden. Funktionen auf Gedeih und Verderb zusammenzufassen bringt auch nichts.
  Und wenn mans dann mit einigen Hacks wirklich geschafft hat alles unter einen Hut zu bringen ändert sich irgendwo eine Vorgabe und das ganze feinoptimierte Konstrukt bricht zusammen.
  Wenn man an Wartbarkeit denkt schadet es auch manchmal nicht Sachen auseinander zu halten, bevor man dann mit ungewollten Nebeneffekten kämpft wenn man was ändert.
  1 + 1 = 10
  - der_thomas
    
    2014-01-20 23:35
    
    User since
    2013-09-07
    158 Artikel
    BenutzerIn
    
    @ Muffi und Raubtier
    Dank euch beiden für die Antworten bezüglich meiner Eingangsfrage, die ist damit nun beantwortet.
    Vor allem das:
    
    Quote
    Und wenn mans dann mit einigen Hacks wirklich geschafft hat alles unter einen Hut zu bringen ändert sich irgendwo eine Vorgabe und das ganze feinoptimierte Konstrukt bricht zusammen.
    
    triffts natürlich.

View all threads created 2014-01-19 12:34.