OOP: Instanz ja oder nein (Allgemeines zu Perl)

[thread]17969[/thread]

OOP: Instanz ja oder nein

Tags: perl5 OOP object instance Ähnliche Threads

Leser: 22

Articles: hide open all | hide show old branches

+11 replies
rosti

2012-12-07 10:37
User since
2011-03-19
3470 Artikel
BenutzerIn
Hi,

vor einiger Zeit hatte ich eine Diskussion mit PHP-Entwicklern, es ging um die Frage, ob die Methode zur Erzeugung einer Instanz (in Perl ist das der Konstruktor) in JEDEM Fall eine Instanz zurückgeben soll, auch dann, wenn dem 'Erzeuger' übergebene Parameter nicht passen oder aufgrund höhererer Gewalt (z.B. 'Stecker ist raus') in der Klasse eine Exception auftritt.

In Perl sieht das oftmals so aus:
Code: (dl )

my $instance = Class->new(%args) or die $@; # z.B. in main, Zeile 815
und so halte ich das auch bei meinen eigenen Entwicklungen. Nicht umsonst gibt es Carp.pm und der Anwender kriegt über $@ einen Hinweis, dass in Zeile 815 (s. Beispiel obenstehend) was schiefgegangen ist.

Bei den PHP-Entwicklern regt sich da ein heftiger Protest, die sind der Meinung, dass in JEDEM Fall eine Instanz erzeugt werden muss und etwaige Fehler oder Exceptions sind über die Instanz dann abzufragen.

Zugegeben, für ein paar meiner Klassen habe ich das früher auch so gehandhabt, heißt, dass es auf den konkreten Fall ankommt und darüber würde ich kein Dogma erheben.

Wie seht Ihr das???
- +2 replies
- Muffi
  
  2012-12-07 10:49
  User since
  2012-07-18
  1465 Artikel
  BenutzerIn
  Was meine Meinung von PHP-Entwicklern nicht grad positiv beeinflusst.
  
  Eine Exception ist etwas, was eine Ausnahmebehandlung auslöst. Und zwar SOFORT und nicht erst irgendwann, wenn irgendwer eine Variable abfrägt oder auch nicht.
  Tuts das nicht, ist es nichts, was bei halbwegs moderner Programmierung Exception genannt wird.
  
  Wenn das geklärt ist gibts eigentlich nur 2 Möglichkeiten.
  a) Der Konstruktor darf eine Exception auslösen
  b) Der Konstruktor darf keine Exception auslösen.
  
  Fall b ist auf jeden Fall für alle Sprachen sinnvoll, die keinen Garbagecollektor haben. Also statt
  
  Code: (dl )
  
  instanz = Irgendwas.new(viel_sums)
  
  schreibt man da gern
  
  Code: (dl )
  
  1 2 3 4 5 6 7
  
  instanz = Irgendwas.new try { instanz.init(viel_sums) } finally { instanz.free }
  
  Für Sprachen, die ihr Zeug selbst aufräumen nehm ich persönlich lieber a
  1 + 1 = 10
  - rosti
    
    2012-12-07 10:55
    
    User since
    2011-03-19
    3470 Artikel
    BenutzerIn
    
    Erstklassige Erklärung, danke Dir!!!
    
    Ja, manchmal möchte ich auch einen riesigen Trichter nehmen und tonnenweise a's in die Horden der PHP-Entwickler hineinfüllen ;)
    
    Quote
    ..Exception...Und zwar SOFORT und nicht erst irgendwann, wenn irgendwer eine Variable abfrägt..
    
    Genau!!
    
    --Rosti
- Muffi
  
  2012-12-07 11:07
  User since
  2012-07-18
  1465 Artikel
  BenutzerIn
  Achja, dann noch die Frage, ob ein Konstruktor unbedingt ein Objekt zurückgeben muss. Was ja erstmal völlig unabhängig von Exceptions ist.
  
  Da auch wieder: Bei Sprachen ohne Garbagecollektor würd ich sowas vorraussetzen. Man wird sonst kirre beim Aufräumen.
  
  Ansonsten ist für mich undef ein gültiger Wert, der auch benutzt werden kann, wenns sinnvoll ist oder Sachen dadurch einfacher werden.
  
  Code: (dl )
  
  1 2 3
  
  my $obj = Class->laden_aus_db($id); if ($obj) ...
  
  sieht meiner Meinung nach schöner aus als
  
  Code: (dl )
  
  1 2 3
  
  my $obj = Class->laden_aus_db($id); if ($obj->bist_du_auch_wirklich_in_der_db) ...
  
  Vorallem kannst du die Uhr stellen bis einer den Methodenaufruf vergisst und nur auf if $obj testet.
  1 + 1 = 10
- +3 replies
- GwenDragon
  
  2012-12-07 11:11
  
  User since
  2005-01-17
  14746 Artikel
  Admin1
  
  Ich verwende bei fehlerhaftem Aufruf ein undef als return-Wert, meinetwegen noch als Liste mit weiterem Fehlerocde-/-meldung.
  
  Wieso muss ein Konstruktor bei Fehlern eine gültige Instanz zurück geben? Ist das bei Programmierung/OOP so üblich oder nur für PHP-Leute?
  die Drachin Gwen
  
  Meine Perl-Artikel · perldev – verschiedene Perl-Versionen unter Windows starten
  - rosti
    
    2012-12-07 11:36
    User since
    2011-03-19
    3470 Artikel
    BenutzerIn
    
    2012-12-07T10:11:49 GwenDragon
    Ich verwende bei fehlerhaftem Aufruf ein undef als return-Wert, meinetwegen noch als Liste mit weiterem Fehlerocde-/-meldung.
    
    Wieso muss ein Konstruktor bei Fehlern eine gültige Instanz zurück geben? Ist das bei Programmierung/OOP so üblich oder nur für PHP-Leute?
    
    Bei PHP-Leuts wird getrennt zwischen
    - Objekterstellung, das ist _immer_ new
    und
    - Konstruktor (der initialisiert die Instanz)
    
    D.h.,
    - PHP::new() liefert _immer_ eine Instanz
    - der Konstruktor gibt gar nichts zurück
    
    PHP-People behaupten, dass das in anderen oo-Sprachen auch so sei.
    
    Was Muffi über die Müllabfuhr schreibt, ist gut zu wissen.
    
    Und weil Perl so schön ist, was das Werfen von Exceptions betrifft:
    
    Code (perl): (dl )
    
    1 2 3 4 5 6 7 8 9 10
    
    sub new{ my $self = bless{}, shift; # sorry, I'm hurry return eval{ # von hier # stehen alle Initialisierungen, die eine # Exception werfen können # bis hier $self; # das geht return, wenn bis hier alles gutgegangen ist }; }
  - topeg
    
    2012-12-07 11:46
    
    User since
    2006-07-10
    2611 Artikel
    BenutzerIn
    
    Java hält das auch so. Wenn keine Exception geworfen wird, kommt immer ein Objekt zurück. Das liegt daran, das die Objekterzeugung nicht in den Händen des Programmierers liegt. Das gilt für viele objektorientierte Sprachen. In "new" ist das Objekt schon erzeugt und muss nur noch Initialisiert werden. Da man das nicht unterbrechen kann muss man eine Unterbrechung durch eine Exception erzeugen. Aus meiner Sicht ist es ein Workaround das zu einer Philosophie gemacht wurde. Nachteil ist halt, das es nicht ignoriert werden kann. Das erzeugt zwangsläufig eines an Code der sonst nicht gebraucht würde.
- +3 replies
- topeg
  
  2012-12-07 11:38
  
  User since
  2006-07-10
  2611 Artikel
  BenutzerIn
  
  Ich persönlich gebe undef zurück wenn aus einem Grund etwas bei der Objekterzeugung nicht passt.
  
  Ähnlich halte ich es auch Methoden. Viel geben "true", "false" oder "undef" bzw. "Wert" oder "undef" zurück. Bei einem Fehler in der Methode gibt es ein "undef". Ausnahmen sind Getter und Setter. Das lässt sich leicht ignorieren, wenn es einen nicht interssiert, man kann es auch problemlos abfangen. Mit $obj->error() oder Class->error() bekommt man das heraus was schief gelaufen ist. Ob man dafür $@ nutzen soll weiß ich nicht. Ich bringe das immer nur mit die und eval{...} in Verbindung.
  
  Exception (die bzw. eval{...}) dagegen mag ich nicht so gerne. Sie stören den Programmablauf, da man sie nicht ignorieren kann. Ich benutze sie nur wenn ein Fehler den Programmablauf absolut behindert und einfach nicht ignoriert werden darf. Z.B. Wenn eine wichtige Datei nicht geladen werden kann, oder eine essentielle Initialisierung fehlschlägt. Meist handelt es sich um externe Bibliotheken, oder Programme, auf die ich keinen weitreichenden Einfluss habe.
  - +2 replies
  - rosti
    
    2012-12-07 11:49
    User since
    2011-03-19
    3470 Artikel
    BenutzerIn
    
    hi Tobias, gerne mache ich Dir das schmackhaft ;)
    
    eval BLOCK hat einen return-Value, das ist die letzte Zeile im BLOCK und das ist der Knackpunkt, Code mit Exceptions zu vereinfachen. Vorausgesetzt, Du freundest Dich mit der Globalen Variablen $@ an ;)
    
    Damit kannst Du jede Methode, auch die Getter und Setter so schreiben:
    
    Code (perl): (dl )
    
    1 2 3 4 5 6 7
    
    sub foo{ my $self = shift; return eval{ # wtf 1; }; }
    
    Edit: Wenn 'wtf' eine Ex wirft, gibt foo{} automatisch ein undef zurück, ansonsten wird die letzte Zeile des eval{}-Block zurückgegeben.
    
    Dann wäre nochwas gut zu wissen: Jeder eval-call setzt $@ auf ''; d.h., bei verschachtelten 'try/catch' Konstrukten ist $@ ggf. an einen guten Platz zu sichern.
    
    --Rosti
    Last edited: 2012-12-07 12:18:41 +0100 (CET)
    - topeg
      
      2012-12-07 12:16
      
      User since
      2006-07-10
      2611 Artikel
      BenutzerIn
      
      Warum sollte ich in meinen Methoden mit die hantieren und alles in eval packen, wenn ich auch einfach in $self->{error} eine Meldung setzen und undef leifern kann. Dazu habe ich eine Methode error{ref($_[0])?$_[0]->{error}:$error} habe. eval ist nur ein weiter (langsamer) Schritt den ich einschiebe, aber nicht brauche.
      
      Wenn ich fremde Sachen benutze und nicht weiß was darin passiert nutze ich eval wenn ich nicht will, dass das Programm unterbrochen wird.
      
      Edit:
      
      ich habe häufig kombinierte Getter/Setter und undef als eingetragenen Wert:
      
      Code (perl): (dl )
      
      1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21
      
      my $error=''; sub _val { my $self=shift; my $key=shift; if(@_) { $self->_error(); my $val=shift; unless($self->{sonstwo}->set($key => $val)) { $self->_error("Can't set $key => $val"); } } return $self->{sonstwo}->get($key); } sub ein_wert { shift->_val('ein_wert', @_); } sub noch_ein_wert { shift->_val('noch_ein_wert', @_); } sub _error { shift->{error}=shift//''; } sub error{ref($_[0])?$_[0]->{error}:$error}
      
      Da muss man, wenn es interessiert, if($obj->error()){...}, machen.
      Last edited: 2012-12-07 12:30:12 +0100 (CET)
- Raubtier
  
  2012-12-07 11:42
  
  User since
  2012-05-04
  1075 Artikel
  BenutzerIn
  
  Hallo,
  
  ich bevorzuge es ebenfalls, ein unwahres Ergebnis zurückzuliefern. Wenn etwas nicht funktioniert hat, dann will man das doch meistens sofort wissen. Interessant wird die Sache, wenn man zum Beispiel in C++ direkt eine lokale Instanz erzeugt statt mit new einen Konstruktor zu rufen und dann den Pointer zu bekommen. Dann ist es ja nicht möglich, nullptr zurückzugeben. In diesem Fall kann man dann entweder Exceptions nutzen oder man erzeugt ein Zombie-Objekt.
  
  In Perl würde ich aber in der Regel das new einfach ein "return;" machen lassen.
  
  Edit: bekommt man es irgendwie hin, dass der Browser nicht zwischen C und ++ einen Zeilenumbruch macht?
  Last edited: 2012-12-07 11:46:43 +0100 (CET)

View all threads created 2012-12-07 10:37.