Klassen-Attribut auch in der Base-Klassen nutzen (Allgemeines zu Perl)

[thread]21180[/thread]

Klassen-Attribut auch in der Base-Klassen nutzen

Tags: perl5 OOP Ähnliche Threads

Leser: 9

Articles: hide open all | hide show old branches

+6 replies
Hagen

2021-04-14 23:15
User since
2007-09-06
233 Artikel
BenutzerIn
Hallo,

ich würde gerne in einer Kind-Klassen ein Konfiguration definieren, auf die ich auch in der Eltern-Klassen zugreifen kann. Aber irgendwie finde ich keine schicke Lösung dafür bzw. der Zugriff funktioniert nicht.

Minimal-Code-Beispiel:
Code (perl): (dl )

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20

package DB::Service; use base DB::Base; use strict; use warnings; my %config = ( table => 'service' ); ... package DB::Base use strict; use warnings; sub load { my ($self) = @_; $self->getDataFromTable($config{table}); }
Letzendlich geht es darum, dass die Eltern-Klasse sehr allgemein gehalten ist und über "die Konfiguration" in der Kind-Klasse unterschiedlich arbeitet. D.h. es gibt z.B. wie hier die DB::Service-Klasse, die ihre Daten aus der Service-Tabelle holen soll; es gibt aber auch eine DB::Kunden-Klasse, die ihre Daten aus der Kunden-Tabelle holen soll (in meine aktuellen Fall ist die 'Konfiguration' umfangreicher).

An anderen Stellen habe ich gesehen, dass man Methoden überschreibt. D.h. in der Eltern-Klasse gibt es die Methode 'getTable', die aber leer ist; in der Kindklasse wird diese dann überschrieben, so dass sie im aktuellen Beispiel 'service' zurückgeben würde.

Geht das auch kürzer und/oder 'eleganter'?

Bisherige Recherchen waren leider erfolglos.

Gruß

Hagen
Gruß
Hagen
- Linuxer
  
  2021-04-15 00:34
  User since
  2006-01-27
  3890 Artikel
  HausmeisterIn
  Ich weiß nicht, ob ich Deinen Ansatz richtig verstehe...
  
  Momentan würde ich an folgendes denken:
  
  eine DB::Base Klasse, die die Grundfunktionen definiert (aber ohne eine new()-Methode)
  eine DB::Service Klasse, die die Tabelle für Service definiert und eine new()-Methode, die diese Tabelle einbindet
  eine DB::Customer Klasse, die die Tabelle für Customer definiert und eine new()-Methode, die diese Tabelle einbindet
  
  Z.B. Beispiel:
  
  more (12.5kb)
  
  Alternativ könnte man auch den Konstruktor in die DB::Base Klasse verlagern und in den Klassen DB::Service und DB::Customer nur die jeweils relevanten Methoden definieren und die gewünschte Tabelle bei der Objekt-Konstruktion übergeben.
  
  more (9.8kb)
  
  Details müssten noch weiter ausgearbeitet werden (z.B. "echte" Tabelle statt Skalar).
  Last edited: 2021-04-15 01:53:30 +0200 (CEST)
  meine Beiträge: I.d.R. alle Angaben ohne Gewähr und auf Linux abgestimmt!
  Die Sprache heisst Perl, nicht PERL. - Bitte Crossposts als solche kenntlich machen!
- +4 replies
- haj
  
  2021-04-15 09:49
  
  User since
  2015-01-07
  555 Artikel
  BenutzerIn
  
  2021-04-14T21:15:55 Hagen
  ich würde gerne in einer Kind-Klassen ein Konfiguration definieren, auf die ich auch in der Eltern-Klassen zugreifen kann. Aber irgendwie finde ich keine schicke Lösung dafür bzw. der Zugriff funktioniert nicht.
  
  Der Ansatz ist etwas bergauf gedacht: Eine Eltern-Klasse sollte nicht wissen müssen, ob Kind-Klassen überhaupt existieren und kann daher nicht so einfach auf Daten der Kind-Klasse zugreifen. Das dürfte auch erklären, warum eine Recherche hier nicht zum direkten Erfolg führt.
  
  2021-04-14T21:15:55 Hagen
  An anderen Stellen habe ich gesehen, dass man Methoden überschreibt. D.h. in der Eltern-Klasse gibt es die Methode 'getTable', die aber leer ist; in der Kindklasse wird diese dann überschrieben, so dass sie im aktuellen Beispiel 'service' zurückgeben würde.
  
  Das ist eine übliche Technik für diese Aufgabe. Du willst mit einer Methode aus der Eltern-Klasse auf Klassendaten unterschiedlicher Kinder zugreifen und musst daher, je nach dem Typ eines Objekts, in den Gültigkeitsbereich unterschiedlicher Klassen reingreifen.
  
  Die Methode getTable wird in der Eltern-Klasse dann oft so implementiert, dass sie nicht leer ist, sondern lautstark stirbt, um klarzumachen, dass Kind-Klassen hier etwas zu tun gehabt hätten.
  
  Bei den vom Linuxer beschriebenen Techniken wird die richtige Konfiguration den einzelnen Objekten schon bei deren Erstellung untergeschoben. Das gefällt mir gut, weil ich in Deinem Beispiel davon ausgehe, dass jedes Objekt während seiner Lebensdauer die Konfiguration irgendwann einmal brauchen wird.
  - +3 replies
  - Hagen
    
    2021-04-16 21:14
    User since
    2007-09-06
    233 Artikel
    BenutzerIn
    
    2021-04-15T07:49:36 haj
    Der Ansatz ist etwas bergauf gedacht: Eine Eltern-Klasse sollte nicht wissen müssen, ob Kind-Klassen überhaupt existieren und kann daher nicht so einfach auf Daten der Kind-Klasse zugreifen.
    
    Das hatte ich befürchtet bzw. macht auch Sinn. Ich hatte u.a. gehofft, dass man Attribute ähnlich wie Methoden überschreiben könnte.
    
    2021-04-15T07:49:36 haj
    Die Methode getTable wird in der Eltern-Klasse dann oft so implementiert, dass sie nicht leer ist, sondern lautstark stirbt, um klarzumachen, dass Kind-Klassen hier etwas zu tun gehabt hätten.
    
    Ja, das habe ich in anderer Stelle gemacht bzw. auch häufiger bei anderen Sprachen gesehen.
    
    Was mich stört ist der dadurch 'unnötig' erzeugte Programmcode. Ist es nur ein Konfigurations-Wert, dann geht das noch. Sind es aber mehrere und wenn es auch mehrere Kind-Klassen gibt sind es schon viele zusätzliche Funktionen, die sich nur minimal unterscheiden.
    
    Angefangen hatte ich wie Linuxer in seinem Beispiel, alle Konfigurations-Werte dem Konstruktor als Parameter mitzugeben.
    
    Code (perl): (dl )
    
    my $customer = DB::Customer->new('customer');
    
    Dann sind es aber mit der Zeit immer mehr gleiche Paremeter geworden
    
    Code (perl): (dl )
    
    1 2 3 4
    
    my $customer1 = DB::Helper->new('id customer 1', 'customer', 'euro', '...', '...', '...'); my $customer2 = DB::Helper->new('id customer 2', 'customer', 'euro', '...', '...', '...'); my $customer3 = DB::Helper->new('id customer 3', 'customer', 'euro', '...', '...', '...'); my $customer4 = DB::Helper->new('id customer 1', 'customer', 'euro', '...', '...', '...');
    
    Weshalb ich dann den Helper zur Eltern-Klasse gemacht habe und in der Klasse Customer versucht habe 'irgendwie' alles zu konfigurieren.
    
    Aktuelle Lösung ist, dass ich die Werte jetzt im Konstruktor ergänze
    
    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 44 45 46 47 48 49
    
    #! /usr/bin/env perl use strict; use warnings; package DB::Base { sub new { my ( $class, $name, $options ) = @_; my $self = {}; bless( $self, $class ); $self->{name} = $name; $self->{options} = $options || {}; return $self; } sub option { my ( $self, $key ) = @_; die('missing key') unless ($key); die( 'missing option `' . $key . '`' ) unless ( defined $self->{options}{$key} ); return $self->{options}{$key}; } }; package DB::Customer { use base "DB::Base"; sub new { my ( $class, @args ) = @_; return $class->SUPER::new( @args, { type => 'Customer', currency => 'Euro', ... } ); } }; package main; my $customer1 = DB::Customer->new('id_customer 1'); __END__;
    
    Danke für eure Anregungen!
    Gruß
    Hagen
    - hlubenow
      
      2021-04-17 18:03
      
      User since
      2009-02-22
      875 Artikel
      BenutzerIn
      
      Vielleicht liegt die Schwierigkeit gerade darin (bin aber nicht sicher, ob das hier wirklich das Problem ist):
      
      Man unterscheidet in der OOP eine "has a"-Beziehung von einer "is a" Beziehung (Beleg, dort anhand von Java).
      Das erste besagt, daß es übergeordnete Klassen gibt, in denen untergeordnete Klassen "Member" sind. Hier "hat" die übergeordnete Klasse die untergeordnete und kann darin Methoden aufrufen, die z.B. Werte innerhalb der untergeordneten Klasse verändern. Das wäre aber keine Vererbung. Z.B. in einem Spiel könnte man eine Klasse "Player" haben, und darin ein Objekt der Klasse "Car". "Player" und "Car" stellen verschiedene Dinge dar, und "Player" "has a" "car". (Wobei "car" ein Objekt der Klasse "Car" ist.)
      
      Vererbung wäre das zweite ("is a"). Das ist das, was Linuxer schon beschrieben hatte. Man könnte z.B. eine Basis-Klasse "Fruit" haben, von der dann Klassen "Apple" und "Banana" Methoden und Attribute erben. "Apple" "is a" "Fruit". Hier können in "Apple" die generellen Attribute und Methoden von "Fruit" überschrieben werden. Die allgemeinen von "Fruit", die auch für "Apple" gelten, werden übernommen (geerbt).
      
      Hatte ich (kurz) auch auf meiner Seite beschrieben.
      
      Jetzt ist die Frage, was Du willst. Wolltest Du Vererbung, oder wolltest Du einfach eine Klassenhierarchie?
      
      In einer Klassenhierarchie könnte man z.B. die Attribute nur einmal an die übergeordnete Klasse übergeben, und von dort an die untergeordneten Klassen verteilen, je nachdem, was dort benötigt wird.
      Auch die einzelnen Methoden in den untergeordneten Klassen können ja einzelne Argumente annehmen.
      Last edited: 2021-04-17 18:35:24 +0200 (CEST)
    - haj
      
      2021-04-17 19:14
      
      User since
      2015-01-07
      555 Artikel
      BenutzerIn
      
      2021-04-16T19:14:39 Hagen
      ... Ich hatte u.a. gehofft, dass man Attribute ähnlich wie Methoden überschreiben könnte.
      
      Na jaaa, es ist Perl, und da kann die Grenze zwischen Methoden und Attributen einigermaßen fließend sein.
      
      Wenn Dich unnötig erzeugter Code stört: Du brauchst die "leere" Methode in der Eltern-Klasse nicht zu definieren. Das würde dann ein statischer Code-Checker anmeckern... aber die gibt's eh nicht für Perl.
      
      Für solche Klassen, wie Du sie hier beschreibst, bringen die Objekt-Frameworks wie Moo übrigens einiges an Ersparnis bei der Schreibarbeit. Das sähe dann so aus:
      
      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
      
      #! /usr/bin/env perl use 5.020; use strict; use warnings; package DB::Base { use Moo; has name => (is => 'ro'); sub option { my ( $self, $key ) = @_; die('missing key') unless ($key); die( 'missing option `' . $key . '`' ) unless $self->can($key); return $self->$key; } } package DB::Customer { use Moo; extends 'DB::Base'; has type => (is => 'ro', default => 'customer'); has currency => (is => 'ro', default => 'Euro'); ...; } package main; my $customer1 = DB::Customer->new(name => 'id_customer 1'); __END__;
      
      Eine offensichtliche Änderung gegenüber Deiner Implementierung ist, dass der Name nicht als Positionsparameter, sondern als Key/Value-Paar an new übergeben wird. Auch das kann man noch angleichen mit BUILDARGS, das mache ich aber nur, wenn ich den Caller-Code wirklich nicht anfassen will (oder kann).

View all threads created 2021-04-14 23:15.