Man sollte seinen Programmablauf nicht von Inhalten auf der Oberfläche abhängig machen sondern immer von den extra gehaltenen Daten, aus denen die Oberfläche befüllt wird. Die Trennung Oberfläche und Daten ist wichtig und es ist ein Graus, wenn jemand anfängt so etwas zu programmieren. Schon alleine die Codeänderungen, wenn er anstatt dem "-" ein "Minus" reinschreibt und bei "*" ein "Multiplizieren". Schon fängt man an und ändert Code, der schon mal komplett fertig war. Oberflächen immer aus dem Spiel lassen. Anderes gutes Beispiel ist immernoch: funktioniert das Programm noch, wenn es übersetzt wurde? Wenn man so programmiert nicht.
Der gezeigte und genutzte Weg über den Instanzenvergleich ist schon ein gut gehbarer. Der Weg über den Tag ist auch ein Weg, der mir persönlich aber nicht so gefällt, weil man sich damit selbst die Möglichkeiten verbaut. Was ist, wenn es eine ähnliche Funktionalität mit einer andere Gruppe Elemente auf der Oberfläche benötigt wird? Keine eindeutigen Tags und wenn dann noch die Anwendung random features erzeugt, dann landet das falsche Elemente mit dem falschen Tag in der falschen Behandlungsroutine und die löst anhand des Tags was falsches aus. Anderes Gegenargument für Tags: Es ist schwer nachvollziehbar. Es ist für jeden anderen Kollegen, der an den Code ran muss ein riesiger Aufwand über den
OI die Tag Verteilung zu ermitteln und auch den entsprechenden Ablauf. Den Code anzuschauen bringt rein gar nichts sondern man muss erst alles im Detail untersuchen. Dies erhöht die Wartbarkeit und die Lesbarkeit in's negativ unermeßliche.
Daher: bester Ansatz immernoch der Instanzenvergleich. Man sieht welche Funktion bei welchen Element ausgelöst wird, der Code "dokumentiert" sich durch den benannten (!) Elementenamen fast komplett selbst und es kann ohne Probleme übersetzt werden, etc.