Eigenschaften von Objekten, private, nichtprivate, schreibgeschützte (Allgemeines zu Perl)

[thread]21672[/thread]

Eigenschaften von Objekten, private, nichtprivate, schreibgeschützte

Tags: perl5 Ähnliche Threads

Leser: 7

Articles: hide open all | hide show old branches

+24 replies
rosti

2025-05-27 10:17

User since
2011-03-19
3651 Artikel
BenutzerIn

Also, wenn ich in meiner Subklasse eine bestimmte Eigenschaft brauche, dann schaue ich in die Instanz ob es die namentlich bereits gibt und gebe meiner Eigenschaft ggf. einen anderen Namen. Es sei denn diese bereits vohandene Eigenschaft ist in meiner Subklasse benutzbar, d.h., daß sie auch beschrieben werden darf.

Diese Vorgehensweise, die sich in meiner Praxis bestens bewährt, setzt natürlich voraus, daß man der Instanz überhaupt Eigenschaften hinzufügen darf.

Ist das Pfui?
http://blog.rolfrost.de/

The art of steam.
- +18 replies
- lichtkind
  
  2025-05-31 20:13
  
  User since
  2004-03-22
  5726 Artikel
  ModeratorIn + EditorIn
  
  Ich vermute du meinst (bitte mehr kontext und standardvokabular verwenden): subklassen dürfen attribute anders verwenden als die eltern. Das verstöst auf jeden fall gegen Liskov und auch gegen meine selbstaufgestellte Regel für maximal Klarheit im Code. Aber ich bin auch gegen Vererbung generell.
  mein zeug:
  
  Es beginnt immer mit einer Entscheidung.
  - +12 replies
  - rosti
    
    2025-06-01 14:47
    
    User since
    2011-03-19
    3651 Artikel
    BenutzerIn
    
    Quote
    subklassen dürfen attribute anders verwenden als die eltern
    
    Nein das meinte ich nicht, sondern das Gegenteil. Nämlich den Fall, daß die Subklasse eine Eigenschaft braucht die die Elternklasse nicht definiert.
    
    Und von daher in der Subklasse der Instanz eine neue Eigenschaft hinzugefügt werden darf (oder mehrere Eigenschaften).
    
    Wobei mit dieser Subklasse keine weiteren Vererbungen stattfinden.
    http://blog.rolfrost.de/
    
    The art of steam.
    - +11 replies
    - lichtkind
      
      2025-06-03 16:36
      
      User since
      2004-03-22
      5726 Artikel
      ModeratorIn + EditorIn
      
      Das ist aber normale OO das subklassen zusätzliche Attribute haben, da glaub ich fast was nicht verstanden zu haben weil ich seh da kein Problem udn auch keine Frage.
      mein zeug:
      
      Es beginnt immer mit einer Entscheidung.
      - +10 replies
      - rosti
        
        2025-06-03 19:10
        
        User since
        2011-03-19
        3651 Artikel
        BenutzerIn
        
        Quote
        Das ist aber normale OO das subklassen zusätzliche Attribute haben
        
        Ja. Nur läuft das in meinem FW so, daß die Subklassen-Instanz in der main erstellt wird und zu diesem Zeitpunkt noch gar nicht feststeht, welche zusätzlichen Attribute benötigt werden. D.h., daß das erst in der Subklasse entschieden wird, also zur Laufzeit.
        
        mfg
        
        Die Eigentliche Frage ist, ob es gegen irgendwelche Prinzipien der OOP verstößt, wenn zur Laufzeit Attribute hinzukommen, Beispiel:
        
        Code (perl): (dl )
        
        1 2 3 4 5
        
        # Methode der Subklasse sub init{ my $self = shift; $self->{DBH} = $self->dbh(); }
        
        .
        Last edited: 2025-06-04 10:48:09 +0200 (CEST)
        http://blog.rolfrost.de/
        
        The art of steam.
        
        +9 replies
        
        lichtkind
        
        2025-06-04 18:39
        
        User since
        2004-03-22
        5726 Artikel
        ModeratorIn + EditorIn
        
        Ich hab damit wenig Probleme da zb viele Attribute in Math::Matrix bei mir mit "is lazy" markiert sind, also erst berechnet werden wenn sie wirklich benötigt werden, ganz einfach weil die berechnung nicht trivial sind und meist nicht benötigt werden. Und ich seh praktisch den Unterschied nicht zu dem was du vorschlägst.
        Ich teile deinen Impuls diese Komplexität mit den verschiedenen new Methoden (in elter und subklasse) vermeiden zu wollen aber das ist halt der Preis wenn man sich für Vererbung entscheided, was ich halt meist nicht tue.
        Last edited: 2025-06-05 18:05:19 +0200 (CEST)
        mein zeug:
        
        Es beginnt immer mit einer Entscheidung.
        
        +5 replies
        
        rosti
        
        2025-06-04 19:18
        
        User since
        2011-03-19
        3651 Artikel
        BenutzerIn
        
        Danke lieber Freund ;)
        
        Aber Du machst mich neugierig was den Verzicht einer Vererbung betrifft. Denn in meinem FW werden tatsächlich nur 2 Methoden vererbt: AUTOLOAD und new
        
        Aber wenn ich die nicht erben würde müsste ich diese Methoden in jeder Subklasse definieren. Da hätte ich jede Menge redundanten Code.
        Last edited: 2025-06-04 19:47:06 +0200 (CEST)
        http://blog.rolfrost.de/
        
        The art of steam.
        
        +4 replies
        
        lichtkind
        
        2025-06-05 18:04
        
        User since
        2004-03-22
        5726 Artikel
        ModeratorIn + EditorIn
        
        Du definierst sie nicht überall sondern benutzt es. Es braucht eine weile umzudenken weil Klassen bei OO per komposition ganz anders aufgebaut und konzipiert werden. Ich versuch es mal so zu erklären. Jede Klasse und jede API sollte überschaubar sein. Und eventuelle Komplexität wird in Attributen versteckt oder deren Attribute. So kannst du auch bestimmte Klassen an mehreren Stellen wiederverwenden ohne die Klassenhierarchie zu brechen.
        
        Ein weitere Möglichkeit ist es auch Objekte als Argumente zu übergeben. Die Methode implementiert einen Algorithmus und die detail der datenstruktur beleiben gekapselt und der Algorithmus funktioniert strukturagnostisch. Wie gesagt er benötigt mehr planung aber der code liest sich dann wie ein Abzählreim.
        Last edited: 2025-06-05 23:01:26 +0200 (CEST)
        mein zeug:
        
        Es beginnt immer mit einer Entscheidung.
        
        rosti
        
        2025-06-05 18:58
        
        User since
        2011-03-19
        3651 Artikel
        BenutzerIn
        
        Quote
        So kannst du auch bestimmte klassen an mehreren Stellen wiederverwenden ohne die Klassenhierarchie zu brechen.
        
        Ja natürlich. Hunderte verschiedene HTML-Einzelseiten meines Blog werden über ein und dieselbe Subklasse als Response ausgeliefert. Lediglich die Eigenschaften wie title, body und descr sind unterschiedlich. Und per Eigenschaft interface=forum bspw. kann ich an jede dieser Seiten ein Forum unten dran hängen.
        
        Quote
        Ein weitere Möglichkeit ist es auch objekte als argumente zu übergeben.
        
        Ja klar. Implizit wird ja bei jedem Methodenaufruf $self->control() das Objekt übergeben. Und da in dieser Methode stets ein CGI-Objekt gebraucht wird, wird es bereits dem Konstruktor der Basisklasse übergeben:
        
        Code (perl): (dl )
        
        1 2 3 4
        
        my $ro = $class->new( BIN => $routes, # alle Eigenschaften der Response-Seiten im wahlfreien Zugriff URL => $url, # der requestete URL like /index.html CGI => xCGi->new(), # Instanz meiner CGI-Klasse
        
        Wenn ich jedoch erst beim Entwurf einer Subklasse sehe, daß ich in jeder Methode dieser Subklasse eine Datenbankverbindung brauche, erstelle ich dieses DBH in der init-Methode, das ist die Methode die über das FW als Erste aufgerufen wird. Somit implementiert mein FW auch ein Interface und versucht, in jeder Subklasse die 4 Methoden init, browse, control und trailer nacheinander aufzurufen. Was das Entwickeln weiterer Subklassen extrem vereinfacht, insbesondere auch dadurch daß nicht grundsätzlich alle 4 Methoden vorhanden sein müssen.
        
        Ein weiteres Muster sollte jeder Entwickler kennen: Delegation. Damit mache ich die Methode einer fremdem Klasse zu einer Methode meiner eigenen Klasse:
        
        Code (perl): (dl )
        
        1 2 3 4 5 6 7 8
        
        sub param{ my $self = shift; return $self->{CGI}->param(@_); } sub xr{ my $self = shift; return XR::xr(@_); }
        
        Lazy Delegation schließlich, lädt fremde Klassen/Instanzen über eine eigene Methode nach:
        
        Code (perl): (dl )
        
        1 2 3 4 5 6 7 8 9 10 11
        
        use strict; use warnings; use TemplateSplitter; sub template{ my $self = shift; my $name = shift || 'default'; my $t = TemplateSplitter->new( $self->{BODY} ); $self->{BODY} = $t->{$name}; $self->{BODY} .= $t->{$_} for @_; }
        
        Last edited: 2025-06-05 19:54:24 +0200 (CEST)
        http://blog.rolfrost.de/
        
        The art of steam.
        
        +2 replies
        
        rosti
        
        2025-06-06 08:37
        
        User since
        2011-03-19
        3651 Artikel
        BenutzerIn
        
        Quote
        Es braucht eine weile umzudenken weil Klassen bei OO per komposition ganz anders aufgebaut und konzipiert werden. Ich versuch es mal so zu erklären. Jede Klasse und jede API sollte überschaubar sein. Und eventuelle Komplexität wird in Attributen versteckt oder deren Attribute.
        
        Genau nach diesem Prinzip der Vielgestaligkeit (Polymorphie) habe ich mein Framework entwickelt. Das ist ja auch die Frage um was es hier eigentlich geht: Die Zweckdienliche Nutzung der Eigenschaften von Instanzen. Das heißt, daß Eigenschaften keine festen Größen sind und daß man nur der Eigenschaften wegen gar keine Vererbung braucht. Update: Eigenschaften zu vererben ist unsinnig. Weil Eigenschaften Sache der Sub- bzw. Anwenderklasse sind.
        
        Ebenso liegt die Polymorphie auch in den verfügbaren Methoden. In meinem FW habe ich einen Pool an über 100 Methoden die klassenübergreifend genutzt werden. AUTOLOAD sorgt dafür, daß diese Methoden nur kompiliert werden wenn sie gebraucht werden, dafür werden sie aus dem Dateisystem geladen, sind also in der Basisklasse gar nicht definiert.
        
        Und obwohl manche dieser Methoden auf bestimmte Eigenschaften der Instanz zugreifen, sind sie klassenübergreifend nutzbar. Nämlich dann wenn Instanzen verschiedener Klassen namentlich dieselben Attribute haben.
        Last edited: 2025-06-06 17:07:29 +0200 (CEST)
        http://blog.rolfrost.de/
        
        The art of steam.
        
        rosti
        
        2025-06-07 10:38
        
        User since
        2011-03-19
        3651 Artikel
        BenutzerIn
        
        Quote
        Update: Eigenschaften zu vererben ist unsinnig. Weil Eigenschaften Sache der Sub- bzw. Anwenderklasse sind.
        
        Ein hinkender Vergleich:
        Spezie Mensch erbt ja im Grunde genommen nicht eine einzige Eigenschaft von seinen Eltern. Denn die Methode fortpflanzen vereinigt männliche mit weiblichen Chromosomen was dazu führt, daß neue Eigenschaften entstehen.
        
        Polymorphie: Die Methode fortpflanzen wird von allen Lebewesen benutzt die sich geschlechtlich vermehren. Dabei wird das Ergebnis nur von den mitgebrachten Eigenschaften bestimmt.
        http://blog.rolfrost.de/
        
        The art of steam.
        
        +3 replies
        
        rosti
        
        2025-06-05 10:22
        
        User since
        2011-03-19
        3651 Artikel
        BenutzerIn
        
        Lazy ist der richtige Begriff. Solche u.a Schlüssel machen schon einen Sinn des lesbaren Codes wegen. Denn stets ist der erste Blick in einen fremden Code dem Konstruktor gewidmet.
        
        So ist man dann gegen Überraschungen gefeit, wenn in den abgeleiteten Klassen plötzlich irgendwelche Eigenschaften auftauchen die in der Basisklasse gar nicht definiert sind.
        In meinem FW ist dafür die Methode init zuständig.
        http://blog.rolfrost.de/
        
        The art of steam.
        
        +2 replies
        
        lichtkind
        
        2025-06-05 17:56
        
        User since
        2004-03-22
        5726 Artikel
        ModeratorIn + EditorIn
        
        is lazy ist der raku syntax, keine ahnung ob es auch das in moose gibt
        mein zeug:
        
        Es beginnt immer mit einer Entscheidung.
        
        rosti
        
        2025-06-05 19:03
        
        User since
        2011-03-19
        3651 Artikel
        BenutzerIn
        
        2025-06-05T15:56:23 lichtkind
        is lazy ist der raku syntax, keine ahnung ob es auch das in moose gibt
        
        Das weiß ich auch nicht weil ich Moose nicht benutze. Was mich jedoch nicht daran hindert, gegen etwaige Vergesslichkeiten einen Kommentar neben dem Code anzulegen ;)
        http://blog.rolfrost.de/
        
        The art of steam.
  - rosti
    
    2025-06-01 15:41
    
    User since
    2011-03-19
    3651 Artikel
    BenutzerIn
    
    Um mal etwas konkreter zu werden. Mein Web-App-Framework ist über Jahre gewachsen. Weder ich noch irgendjemand kann vorhersagen, welche Anwendungen (Subklassen) zukünftig zu entwickeln sind. Nehmen wir bspw. den Datenaustausch über mehrere Methoden. Idealerweise kriegt die Instanz eine Referenz auf die Daten, also eine Eigenschaft und so stehen die Daten in JEDER Methode zur Verfügung.
    
    Sicher kann man das auch über eine globale Variable lösen, aber schön ist das nicht und schon gar nicht im Sinne einer OOP.
    
    Und sicher könnte man in solchen Fällen auch die Basisklasse ändern, muss dann aber damit rechnen daß es an einer anderen Stelle (andere Subklasse) knallt.
    
    Wie macht Ihr denn das? Ist ja nicht unbedingt ein Perl-Problem.
    Last edited: 2025-06-01 15:50:56 +0200 (CEST)
    http://blog.rolfrost.de/
    
    The art of steam.
  - rosti
    
    2025-06-01 16:37
    
    User since
    2011-03-19
    3651 Artikel
    BenutzerIn
    
    Und noch ein Beispiel:
    Dateizugriff atomar. D.h. daß das Dateihandle mit der Instanzerstellung der Subklasse einen Lock bekommt der erst im Destroy wieder gelöst wird. Idealerweise wird hierzu das Handle in einer Eigenschaft der Subklasseninstanz abgelegt. Nicht im Sinne einer OOP ist es, das Handle als Klassenvariable anzulegen.
    
    Datenbankzugriff: Hier kommt uns die DBI-Klasse soweit entgegen, als es das Datenbank-Handle (DBH) cachen kann womit man über mehrere Methoden der eigenen Subklasse stets dasselbe DBH einer einmal hergestellten Verbindung bekommt, also die Verbindung nicht jedesmal neu erstellt wird. Auf diese Art und Weise kann man auf eine DBH-Eigenschaft in der Subklasseninstanz verzichten.
    http://blog.rolfrost.de/
    
    The art of steam.
  - rosti
    
    2025-06-06 12:57
    User since
    2011-03-19
    3651 Artikel
    BenutzerIn
    
    Quote
    subklassen dürfen attribute anders verwenden als die eltern. Das verstöst auf jeden fall gegen Liskov und auch gegen meine selbstaufgestellte Regel für maximal Klarheit im Code.
    
    Finde ich nicht. Vielmehr finde ich (mittlerweile * s.u.), daß die Elterklasse gar keine Attribute braucht und nur Methoden definiert.
    
    Betrachten wir folgende new der Basisklasse meines FW:
    
    Code (perl): (dl )
    
    1 2 3 4 5
    
    sub new{ my $class = shift; my %self = @_; return bless \%self, $class; }
    
    Dieser Konstruktor ist universell. Beim Aufruf kann man beliebige Eigenschaften einbauen, also die auf die abgeleitete Klasse zugeschnittenen Eigenschaften. Und diese Vorgehensweise ist nicht einmal von mir, sämtliche Tie::Std-Klassen, insbesondere Tie::StdHash funktionieren nach diesem Grundsatz.
    
    * Das hat die Revision meiner Klassenentwürfe ergeben: Ich habe tatsächlich nicht eine Klasse die Eigenschaften vererbt.
    Last edited: 2025-06-07 17:30:44 +0200 (CEST)
    http://blog.rolfrost.de/
    
    The art of steam.
  - rosti
    
    2025-06-10 09:13
    
    User since
    2011-03-19
    3651 Artikel
    BenutzerIn
    
    Liskov besagt, dass ein Programm, das Objekte einer Basisklasse T verwendet, auch mit Objekten der davon abgeleiteten Klasse S korrekt funktionieren muss, ohne dabei das Programm zu verändern.
    
    Wow! Da gehe ich mit meinem FW sogar noch einen Schritt weiter: Mein main-Programm funktioniert mit ALLEN Objekten die über eine beliebige Subklasse erstellt werden ohne die main ändern zu müssen.
    
    Anders ausgedrückt: Alle in meinem FW erstellten Subklassen nutzen einunddasselbe Programm. Was ja auch der Sinn eines Frameworks ist
    
    .
    Last edited: 2025-06-10 09:23:16 +0200 (CEST)
    http://blog.rolfrost.de/
    
    The art of steam.
  - rosti
    
    2025-06-10 18:08
    
    User since
    2011-03-19
    3651 Artikel
    BenutzerIn
    
    Liskov besagt,
    Quote
    dass ein Programm, das Objekte einer Basisklasse T verwendet, auch mit Objekten der davon abgeleiteten Klasse S korrekt funktionieren muss, ohne dabei das Programm zu verändern.
    
    Das mit den OOP-Theorems ist natürlich so eine Sache. Es kann nämlich sein, daß die Basisklasse eine abstrakte Klasse und von daher gar nicht instanziierbar ist. Ansonsten ist die Formulierung "korrekt funktionieren" ziemlich dumm.
    
    Update: Denn korrekt funktionieren heißt bspw. daß ein Parameter ?show=123 die Nachricht mit der Nummer 123 im Browser ausgibt, weil die Instanz der Klasse Forum dazu in der Lage ist, die Instanz der Basisklasse hingegen nicht.
    Last edited: 2025-06-10 22:06:13 +0200 (CEST)
    http://blog.rolfrost.de/
    
    The art of steam.
- +5 replies
- hlubenow
  
  2025-06-09 03:06
  
  User since
  2009-02-22
  885 Artikel
  BenutzerIn
  
  2025-05-27T08:17:52 rosti
  Also, wenn ich in meiner Subklasse eine bestimmte Eigenschaft brauche, dann schaue ich in die Instanz ob es die namentlich bereits gibt
  
  Den Satz verstehe ich schon nicht: Instanzen einer Klasse sind Objekte. Denn Objekte werden "instantiiert". Man kann beliebig viele Objekte einer Klasse instantiieren. In welche "Instanz" schaust Du also, wenn Du ggf. zahlreiche Objekte der Klasse hast?
  Und wie schaut man in ein Objekt?
  
  Mir scheint, Du machst die Dinge unnötig kompliziert. Verwende die "new()"-Funktion (die mit dem "bless()") am besten immer in derselben Weise (nämlich so, wie ich das mal auf meiner Seite gezeigt hatte), und kümmere Dich dann nicht weiter um ihren Inhalt, sondern um "higher level"-Dinge wie die Modellierung der Klassen.
  
  Aber wie Du schon sagtest: Du hast seit ewigen Zeiten ein Framework am Laufen, und darin wird sich wahrscheinlich wohl auch nichts mehr ändern.
  - rosti
    
    2025-06-09 09:05
    
    User since
    2011-03-19
    3651 Artikel
    BenutzerIn
    
    Natürlich sind Klasseninstanzen Objekte. Wenn ich Objekt meiner Scaligerklasse erstelle, $sca = Scaliger->new; hat dieses Objekt Eigenschaften wie z.B. day, month, year.
    
    Und wenn ich diese Eigenschaften willkürlich ändere, muss ich damit rechnen daß dieses Objekt nicht mehr das macht was es soll. Wenn ich also neue Eigenschaften hinzufüge, muss ich gucken, daß es da keine Konflikte gibt.
    
    PS:
    Quote
    Und wie schaut man in ein Objekt?
    
    Code gucken, Kommentare lesen, Data::Dumper;
    Last edited: 2025-06-09 11:09:24 +0200 (CEST)
    http://blog.rolfrost.de/
    
    The art of steam.
  - +3 replies
  - rosti
    
    2025-06-09 13:57
    User since
    2011-03-19
    3651 Artikel
    BenutzerIn
    
    Quote
    Aber wie Du schon sagtest: Du hast seit ewigen Zeiten ein Framework am Laufen, und darin wird sich wahrscheinlich wohl auch nichts mehr ändern.
    
    Doch, doch. Da kommt immer mal wieder was Neues hinzu. Und auch neue Klassen und Ideen. Zum Beispiel die Idee, anstelle mehrerer Dateien für Templates nur eine Datei zu erstellen und zwar so, daß man daraus mit einer einzigen Methode das passende Template rausfischt.
    
    Der Code sieht am Ende dann beispielsweise so aus:
    
    Code (perl): (dl )
    
    1 2 3 4 5 6 7 8 9
    
    sub control{ my $self = shift; if( $self->param('month') ){ $self->template('month'); } elsif( $self->param('year') ){ $self->template('year'); } }
    
    Und schwubbs wird das richtige Template in den Browser gerendert. Wobei $self als Instanz der für die Response zuständigen Subklasse eine neue Eigenschaft TemplateSplitter bekommt damit die Methode $self->template mehr als einmal aufgerufen werden kann. Denn diese Eigenschaft, die wiederum eine Klasseninstanz (Klasse: TemplateSplitter) ist, also ein Objekt, sind die verfügbaren Templates gespeichert.
    
    Das ganze high-level-Dingens, also meine (extrem flache) Klassenhierachie ist so beschaffen, daß die template-Methode jeder Subklassen-Instanz zur Verfügung steht und die an den URL gebundene Subklasse die dem Verwendungszweck entsprechenden Templates zur Verfügung stellt und eben nur diese.
    http://blog.rolfrost.de/
    
    The art of steam.
    - +2 replies
    - hlubenow
      
      2025-06-10 00:50
      
      User since
      2009-02-22
      885 Artikel
      BenutzerIn
      
      Na ja, kann schon sein, daß das geht. :)
      - rosti
        
        2025-06-10 08:31
        
        User since
        2011-03-19
        3651 Artikel
        BenutzerIn
        
        Genau. Der Umgang mit Eigenschaften ist kein Anderer als der Umgang mit herkömmlichen Variablen. Wenn ich eine neue Variable definiere muß ich auch gucken ob es die schon gibt. Sonst knallts.
        http://blog.rolfrost.de/
        
        The art of steam.

View all threads created 2025-05-27 10:17.