nicht angemeldet
Wie löst du bei dieser Vorgehensweise Anforderungen, dass die Requests jeweils ihre eigene Datenhaltung verwenden sollen, weil sie zu unterschiedlichen Servern gehen, und in dieser Datenhaltung sich bereits Cookies aus früheren Requests befinden?
Gar nicht. Diese Anforderung löst allein die Instanz der Cookie Klasse. Siehe also dort.
Wie löst du damit Anforderungen, dass der eine gern in Dateien, der andere aber gern in einem Shared Memory und der dritte eine Datenbank und ein vierter einer die derzeit noch unbekannte Art und Weise als Ablage der Cookie-Daten verwenden möchte?
Das auch.
Vererbung erhöht die Verflechtung und die Abhängigkeiten untereinander.
Richtig. Speziell in diesem Fall "Cookie" ist Vererbung nicht angbracht.
ndere empfinden Dependency Injection sehr wohl als zweckmäßig, weil durch die erzwungene Übergabe, ohne die die Instanz oder Methode/Funktion nicht arbeiten kann, klar hervorgeht, was genau zur Ausführung benötigt wird und was man als Voraussetzung schaffen muss. Zudem erhöht das die Wiederverwendbarkeit, weil man seiner Kreativität freien Lauf lassen kann, welche konkrete Implementierung man da übergibt.
Was ich beschrieben habe ist Dependency Injection. Nur die Umsetzung in HTTP::Tiny ist unzweckmäßig weil eine Übergabe an den Konstruktor erfolgt. Das heißt nämlich, daß die Abhängigkeit außerhalb der Klasse hergestellt wird. Und das ist schlecht. Wies besser geht schrieb ich auch.
SSL_options — A hashref of SSL_* — options to pass through to IO::Socket::SSL
Hier jedoch ist Vererbung angebracht.
MfG
Rolf B