Solche Doppelimplementationen von Interfaces kann man dann wiederum mit einer Delegation auf eine andere implementierende Klasse auflösen (siehe reserviertes Wort implements).
Zugegeben: bei meiner Suche nach Lösungen bin ich ja, wie gesagt, auch schon bei den Interfaces gelandet. Aber irgendwie war für mich die
OH-Seite dazu wenig verständlich. Hab dann einfach bei Delphi-Treff das
Tutorial zu Interfaces angeschaut. Hättest du eventuell ein kleines Beispiel, wie ich mir das vorstellen kann? =)
BTW, könnte es sein, daß du in deinen abgeleiteten Klassen das override unterschlagen hast?
Öhm ... kööönnte wohl sein.
War wohl doch etwas
zu pseudo, der Code.
Ein- und Ausgabe von und nach irgendwohin tackere ich mir selbst auch oft an Klassen, die es eigentlich nicht haben sollten. Ich will dich davor bewahren, so zu enden wie ich:
Es ist, wie der Name schon sagt, eine Liste. Kein Webserver-Response-Ausleser. Irgendwann hast du einen Webserver, der dir die Daten anders formatiert. Dann musst du deine Liste von Arbeitnehmern anpassen, nur weil sich ein Webserver geändert hat?
Ich gebe zu ... das ist durchaus plausibel und nachvollziehbar. =)
Grade wenn man einmal damit angefangen hat verleitet es immer weiter, die Klasse mit Dingen aufzublähen die sie nicht haben sollte. Irgendwann kommt eine Methode massenentlassung()
welche anhand von irgendwelchen Kriterien Arbeitnehmer auswählt und sie entfernt. Sie stecken zwar in der Liste, aber die Liste selbst hat auch nicht die Filterung zu treffen, wer entfernt wird. Das nur als Beispiel. Schuster, bleib bei deinen Listen (höhö).
Sag das nicht zu laut – so eine Funktion würde unser Betrieb sicher gern mal implementiert sehen.
Günther hat am Samstag aufgepasst
Gabs hier im Forum was aufzupassen? =) Da würde ichs mir gern mal durchlesen, vielleicht ist ja auch für mich was nützliches bei.
