Schönes Perl - OOP, getter, setter (gelöst) (Allgemeines zu Perl)

[thread]19009[/thread]

Schönes Perl - OOP, getter, setter [gelöst]

Tags: perl5 Ähnliche Threads

Leser: 21

Articles: hide open all | hide show old branches

+11 replies
styx-cc

2014-04-04 18:11
User since
2006-05-20
533 Artikel
BenutzerIn
Hi, wie notiere ich folgendes am "schönsten"?

Es werden Daten in JSON abgeholt und sollen anschließend geparsed werden
und in $self->{'markets'}; abgespeichert werden, was den Code unschön werden lässt, ist dass ich das Parsing der Übersicht wegen, in einer weiteren Funktion vornehmen möchte ( parse_markets() )
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

sub markets { my $self = shift; if (@_) { $page = $self->handle->get('https://www.example.com'); if ($page->is_success) { $self->{'markets_json'} = $page->content; #JSON } else { croak "Can't get markets: ". $page->status_line(); } $self->parse_markets(); } else { return $self->{'markets'}; } } sub parse_markets { my $self = shift; }
Wie mache ich das jetzt am besten?

Hier wuerde ich $self->{'markets'} in einem Setter setzen
der anders heißt als die Eigenschaft, das gefällt mir nicht.
Code: (dl )

1 2 3 4 5

sub parse_markets { my $self = shift; #parsing hier so $self->{'markets'} = $parsing_ergebnis; }
Hier wuerde ich imo mit OOP brechen, das gefaellt mir auch nicht:
Code: (dl )

1 2 3 4 5 6 7 8 9 10 11 12

sub markets { $self = shift; [...] $self->{'markets'} = parse_markets(\$self->{'markets_json'}); [...] } sub parse_markets { my $markets_json = shift; #parsing hier return \$parsing_ergebnis; }
Gruß
Pörl.
- +2 replies
- moritz
  
  2014-04-05 13:40
  User since
  2007-05-11
  923 Artikel
  HausmeisterIn
  2014-04-04T16:11:09 styx-cc
  Hier wuerde ich $self->{'markets'} in einem Setter setzen
  der anders heißt als die Eigenschaft, das gefällt mir nicht.
  
  Und das ist dein Problem. Wenn du immer nur Attribute in gleichnamigen Settern setzt, machst du keine Kapselung, und auch kein richtiges OO.
  
  Attribute sind Implementierungsdetails, und gehen den Nutzer nichts an. Der Nutzer kommuniziert nur mit Methoden mit der Klasse. Wenn du dich darauf beschränkst, dass es ein 1:1-Mapping zwischen Methoden und Attributen gibt, geht dir 90% der Mächtigkeit von OO verloren.
  
  Ich kenne jetzt den Context deines Codeschnippsels nicht, aber als User würde ich erwarten, dass es eine Methode gibt, die mir die Daten liefert, die ich haben möchte.
  
  Dass diese Methode intern eventuell ein oder mehrere Attribute benutzt, um an die Information zu kommen, ist mir egal.
  
  Es könnte also vielleicht so aussehen:
  
  Code (perl): (dl )
  
  1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19
  
  sub markets { my $self = shift; $self->_fetch_markets(); $self->_parse_markets(); return $self->{markets}; } sub _fetch_markets { my $self = shift; return if $self->{markets_raw}; # code hier, um $self->{markets_raw} zu befüllen ... } sub _parse_markets { my $self = shift; return if $self->{markets}; $self->{markets} = decode_json $self->{markets_raw}; }
  
  Perl 6 - Perls Zukunft
  - styx-cc
    
    2014-04-05 13:58
    
    User since
    2006-05-20
    533 Artikel
    BenutzerIn
    
    Schöne Inspiration, so werde ich das übernehmen und fortsetzen. Danke.
    Pörl.
- +8 replies
- rosti
  
  2014-05-10 13:49
  User since
  2011-03-19
  3472 Artikel
  BenutzerIn
  Es ist nicht so trivial, wie das manche Tutorials vermitteln mit den Gettern. Schaffe in Deinen Klassen/Modulen Klarheit, ob bei einem Getter auch Argumente erlaubt sind oder nicht. Sind Argumente erlaubt, dürfen die nicht die Instanz verändern, denn das ist Sache eines Setters.
  
  Es ist unerheblich, ob ein Getter intern direkt auf _ein_ privats Attribut zugreift, oder den return-Value unter Zuhilfenahme weiterer privater Attribute kalkuliert. Genau aus diesem Grund leitet sich die Empfehlung ab, dass eine Anwendung nicht selbst direkt auf _ein_ Attribut zugreifen soll, denn es könnte Abhängigkeiten geben, die nur das Modul und der Getter kennt. So ist ein Getter die Schnittstelle nach draußen und so definiert, dass etwaige Abhängigkeiten in den return-Value eingehen.
  
  Getter mit/ohne Argumente
  ===========================
  
  Beispiel:
  
  Code (perl): (dl )
  
  1 2 3 4
  
  my $sca = Scaliger->new(); # instance 4 today $sca->wochentag; # Samstag $sca->wochentag( date => '4.10.1582'); # Donnerstag $sca->wochentag; # Samstag
  
  Ein komfortabler Getter, der mal eben einen anderen Wert berechnet, ohne dass die Instanz verändert wird. Intern wird ein clone erzeugt und dessen Lebensdauer begrenzt sich auf die Methode.
  
  Setter
  ===========
  
  Eine andere Methode jedoch:
  
  Code (perl): (dl )
  
  1 2 3 4 5
  
  $sca->wochentag; # Samstag $sca->add(1); $sca->wochentag; # Sonntag $sca++; # use overload "++" $sca->wochentag; # Montag
  
  Methode add() ist ein Setter, denn es wird die Instanz verändert, alle internen Attribute werden neu kalkuliert. Ausgewählte Setter können Operatoren überlagern, im Beispiel zeigt overload "++" auf add(1).
  
  At least: Es spricht nichts dagegen, einen Getter so zu benennen, wie ein Attribut namentlich lautet. Ein Setter jedoch, setzt nicht irgendein Attribut schlechthin, sondern verändert die Instanz! Getter-Namen like setAttributeName() sind irreführend, weil ein Setter nicht nur _ein_ Attribut ändert.
  - +7 replies
  - Muffi
    
    2014-05-10 14:16
    
    User since
    2012-07-18
    1465 Artikel
    BenutzerIn
    
    Obwohl ich $sca->wochentag( date => '4.10.1582'); auf den ersten Blick als übertriebene Objektorientitis sehe. Das ist einfach eine stink normale Funktion und keine Methode.
    Last edited: 2014-05-10 14:20:07 +0200 (CEST)
    1 + 1 = 10
    - +6 replies
    - der_thomas
      
      2014-05-10 23:17
      
      User since
      2013-09-07
      158 Artikel
      BenutzerIn
      
      Ich dachte bisher immer dass man jede Funktion die auf (gegen) ein Objekt angewendet wird als Methode bezeichnet ?
      
      thomas
      - +5 replies
      - Muffi
        
        2014-05-10 23:54
        
        User since
        2012-07-18
        1465 Artikel
        BenutzerIn
        
        Richtig. Nur in dem Fall ist das Objekt völlig überflüssig und schlimmer noch: Es überschreibt sogar noch alles, was das Objekt ausmacht.
        1 + 1 = 10
        
        +4 replies
        
        rosti
        
        2014-05-11 07:26
        
        User since
        2011-03-19
        3472 Artikel
        BenutzerIn
        
        2014-05-10T21:54:15 Muffi
        Richtig. Nur in dem Fall ist das Objekt völlig überflüssig und schlimmer noch: Es überschreibt sogar noch alles, was das Objekt ausmacht.
        
        Das Objekt überschreibt gar nichts sondern die Methode überschreibt. Das Objekt ist nicht überflüssig, sondern erforderlich, weil die Methode nur funktioniert, wenn sie über die Instanz aufgerufen wird und nicht anderswie. Es wäre schlimm, wenn eben das nicht so wäre. Es wäre noch schlimmer, wenn eine beliebige Funktion einer anderen Package ein Attribut ändert, dann ist das Objekt nicht mehr zu gebrauchen.
        
        Nicht einmal eine Klassenmethode (wird über den Namen der Klasse aufgerufen), darf Attribute ändern, sie kann es gar nicht, weil sie gar keine Instanzen kennt. Einzig der Konstruktor als Klassenmethode darf Attribute setzen, weil er eine Instanz erzeugt und wie die Attribute untereinander zusammenhängen, das weiß nur die Klasse selbst und auch ein Getter muss das wissen, sonst macht er die Instanz kaputt.
        
        Stell Dir vor, Du hast ein Objekt mit den Attributen {date => '11.5.2014', jd => 2456789} und irgendeine Funktion ändert das Datum, so wird ein später über jd berechneter Wochentag nicht mehr zum Datum passen, auch wenn die Berechnung des Wochentages eine stinknormale Modulo-7-Division ist.
        
        PS: Letztes Jahr hat mir sogar ein gestandener PHP-Programmierer gesagt, dass er einen Setter nicht setAnyAttr() nennen würde, weil ein Setter genau wissen muss was er tut, und so kann er auch gleich einen aussagekräftigen Namen bekommen.
        Last edited: 2014-05-11 08:31:29 +0200 (CEST)
        
        +3 replies
        
        Muffi
        
        2014-05-11 10:33
        
        User since
        2012-07-18
        1465 Artikel
        BenutzerIn
        
        Die Funktin würd ich einfach so schreiben.
        
        Code (perl): (dl )
        
        Scaliger::wochentag('4.10.1582')
        
        Es bringt keinen Mehrwert hier OO zu verwenden.
        
        Und mit dem "Es überschreibt sogar noch alles" meinte ich, dass das was das Objekt ausmacht ja wohl nur ein intern gespeichertes Datum ist und das
        wird beim Methodenaufruf auch noch umgesetzt.
        Ich find sowas nur verwirrend. Man fragt sich beim Aufruf, für was da ein Objekt gebaut werden muss, wenn eh nichts davon gebraucht wird.
        1 + 1 = 10
        
        rosti
        
        2014-05-11 11:44
        
        User since
        2011-03-19
        3472 Artikel
        BenutzerIn
        
        2014-05-11T08:33:56 Muffi
        Die Funktin würd ich einfach so schreiben.
        
        Code (perl): (dl )
        
        Scaliger::wochentag('4.10.1582')
        
        Es bringt keinen Mehrwert hier OO zu verwenden.
        
        Und mit dem "Es überschreibt sogar noch alles" meinte ich, dass das was das Objekt ausmacht ja wohl nur ein intern gespeichertes Datum ist und das
        wird beim Methodenaufruf auch noch umgesetzt.
        Ich find sowas nur verwirrend. Man fragt sich beim Aufruf, für was da ein Objekt gebaut werden muss, wenn eh nichts davon gebraucht wird.
        
        Ja, ich verstehe schon was Du meinst, ist auch richtig und funktioniert. Bis auf den Mehrwert: Den gibts wirklich ;)
        
        Ich hole mal ein bischen weiter aus mit einem anderen Beispiel:
        
        Code (perl): (dl )
        
        1 2
        
        my $userobject = tie my %user, 'MySQL::User', ( userid => 1234 ) or die $@;
        
        Wegen einer sauberen Trennung der Fehlerbehandlung bez. Anwendungs- oder Eingabefehler wird der Konstruktor an dieser Stelle NICHT die userid validieren, so kann in $@ nur der Text für eine Exception stehen, die geworfen wird, wenn der Layer 'MySQL' nicht verfügbar ist (keine Verbingung zu MySQL).
        
        So stehen in %user zunächst gar keine Daten und die Instanz $userobject hat nur das Attribut userid. Nun kommt der Getter ins Spiel und der hat den Namen FETCH.
        
        Code (perl): (dl )
        
        my $vname = $user{vname};
        
        FETCH wird nun aufgerufen aufgrund der Bindung tie(), FETCH wird mit dem privaten Attribut userid über den Layer nach den Daten greifen und jetzt kommt der springende Punkt, auf den ich hinauswill:
        
        1) Es wird nur vname aus der DB gelesen,
        2) Es werden alle Attribute des Users, vname, name, plz, ort, str usw. auf einmal geholt.
        
        Klarer Fall, bei (1) wird jedesmal eine Abfrage nach MySQL gesendet. Auch wenn die Session bereits besteht und ein prepared Statement verwendet wird, kostet das Zeit.
        
        Im Fall (2) erfolgt die Abfrage nur beim Erstenmal. Jedes weitere FETCH
        
        Code (perl): (dl )
        
        my $ort = $user{ort};
        
        kann auf Attribute zurückgreifen, die bereits in der Instanz vorliegen. Die Validierung, betreff einer sauberen Trennung der Fehlerbehandlung, erfolgt ebenfalls beim Aufruf des Getters FETCH: Wenn die userid nicht valide ist, kann es sich nur um einen Eingabefehler handeln (der Programmierer wendet die Klasse ansonsten richtig an).
        
        Mehrwert also: Alle Daten, die organisatorisch zusammengehören, liegen als Attribute im Objekt, in der Instanz der Klasse und es kann performant darauf zzugegriffen werden.
        
        Wenns ein bischen mehr Mehrwert sein darf ;)
        
        Code (perl): (dl )
        
        1 2
        
        $userobject->validate(userid => param('userid') ) or die $@; # netter Versuch
        
        Es wird keine neue Instanz erstellt, denn ein weiteres Attribut der bereits vorliegenden Instanz ist eine standhafte DB-Verbindung, die wir so nicht neu aufbauen müssen. Die Methode validate() wird userid an den Getter named FETCH durchreichen, fertig ;)
        
        validate() ist ein Setter, alle Getter heißen FETCH. Ich denke, die Philosophie der Getter und Setter wird verständlicher, wenn Du mal eine eigene Tie-Klasse schreibst ;)
        
        Tags: Performance, Code-Redundanzen, wiederverwertbarer Code, Datenabstraktion.
        Last edited: 2014-05-11 14:34:46 +0200 (CEST)
        
        rosti
        
        2014-05-11 20:59
        
        User since
        2011-03-19
        3472 Artikel
        BenutzerIn
        
        Muttertag, schönes Beispiel, schönes Perl:
        
        Code (perl): (dl )
        
        1 2 3 4 5
        
        my $sca = Scaliger->new( date => '1.5.2014') or die $@; # wd: Wochentag numerisch, jd: Scaliger-Tag (julianischer Tag) my $jd_mother = 14 - $sca->wd + $sca->jd; # der 2. Sonntag im Mai # passt ;) say $sca->gregdate( jd => $jd_mother ), " ", $sca->wochentag( jd => $jd_mother );
        
        Schönen Abend ;)
        
        PS: Geht aber auch einfacher, 15 - Wochentag; fertig ;)
        Last edited: 2014-05-12 01:16:16 +0200 (CEST)

View all threads created 2014-04-04 18:11.