hi T-Rex,
Für mich sind Eigenschaften jedoch etwas privates. Methoden dagegen sind Schnittstellen. Deshalb möchte ich nur über Schnittstellen kommunizieren.
Jow!!!! Das unterstreiche ich ganz dick! Der Grund: Wenn erforderlich (oft erlebt) kann das Objekt komplett umgebaut werden, wobei Attribute intern eine andere Referenz oder auch einen anderen Namen bekommen. Die Methoden jedoch bleiben namentlich als Schnittstellt nach draußen, da ist also nichts zu ändern.
Genauso verhält es sich mit privaten Methoden, Perl ist da tolerant, theoretisch besteht die Möglichkeit, private Methoden auch public zu nutzen, aber: Der Autor der Klasse hat private Methods als _solche gekennzeichnet und darf die intern ändern oder gar wegfallen lassen. Wer also im Public-Bereich (main) eine private Methode nutzt, ist selber schuld.
Außerdem hab ich da mal einen Artikel über "method chain" gelesen der mich aufhorchen hat lassen.
Nicht machen. Scroll mal nach oben... im Prinzip werden Interna damit nach draußen gereicht und das ist schlecht. Ähnlich schlechter Stil ist, wenn im Konstruktor auf Attribute zugegriffen wird, die vorher, z.B. durch Aufruf einer Klassenmethode initiiert werden.
Wenn ich es vermeiden kann, werden auch Public-Methoden die Attribute möglichst nicht verändern, dafür gibt es Rückgabewerte der Methoden, die es zu nutzen gilt. Es lässt sich jedoch nicht immer vermeiden, innerhalb einer Methode mal ein Attribut hinzuzufügen, beispielsweise ein Objekt einer völlig fremden Klasse als eigenes Attribut:
# Public Method
sub orders{
my $self = shift; # ich bin in meiner Klasse...
$self->{cart} = Cart::Orders->new; # Warenkorb::Bestellung, andere Klasse
my $ords = $self->{cart}->showorders(\&cbo) or $self->errpush($@);
return $ords; # Anzahl der Bestellungen
# angezeigt werden die Bestellungen über die Callbackfunktion &cbo
}
Callbackfunktionen sind ein Thema für sich, in meinem Fall übernimmt die Callbackfunktion die HTML-Ausgabe, CB-Funktionen können aber auch PDFs erstellen oder gleich auf STDOUT schreiben...
Hotti