Klasse aus Datenbank füllen, danach die Klasse verarbeiten

[dedlfix]

Tach!

Wofür hältst du dich eigentlich, dass du meinst den Verwender vor etwas beschützen zu müssen? Meinst du die Verwender sind nicht gut genug im Programmieren und Code-Verstehen, die potentiellen Auswirkungen zu erkennen?

Für einen verantwortungsbewussten Menschen. Wenn ich mit dem Wagen liegen bleibe, stelle ich auch ein Warndreieck auf. Wenn ich ein Auto baue, baue ich Sicherheitsgurte und Airbags ein.

Beim Auto gab es sehr viele Erfahrungswerte, die zu diesen Sicherheitsvorschriften geführt haben. Wenn ich allein was programmiere, gibt es nur meine Erfahrung. Das Warndreieck schützt auch mein abgestelltes Auto, was man aber beim Programmieren nicht braucht, wenn jemand eine Kopie meines Codes bei sich laufen lässt. Davon bin ich nicht betroffen. Lass mal den Auto-Vergleich weg, der hilft nicht, weil das ein ganz anderes Metier ist.

Warum willst du sie davon abhalten, dass sie sich ins Knie schießen, wenn sie es denn unbedingt wollen?

Weil ich nicht glaube, dass sich jemand wirklich ins Knie schießen will. Ich bin nicht der Typ, der jemandem zum Fischen eine Schusswaffe in die Hand drückt, ich drücke ihm eine Angel in die Hand.

Na und, wenn er denn unbedingt Dynamitfischen will? Die Frage ist, ob du den Verwender unerfahren einschätzt und ihn deshalb schützen möchtest. Wenn du ihn ebenbürtig ansiehst, müsste doch ein Hinweis statt einer Absperrung reichen.

Ich sehe das umgekehrt: Wenn ich eine Klasse für Vererbung öffne, dann füge ich der Schnittstelle eine gehörige Portion Komplexität hinzu, sie gewinnt aber nicht an Ausdrucksstärke.

Etwas, das nicht vorhanden ist, fügt Komplexität hinzu, nur weil ich eine Verhinderung weglasse? Ob jemand da was komplexes draus macht oder nicht, ist doch sein Problem.

Nur durch das Zulassen von Vererbung werden ja nicht auf magische Weise neue Anwendungsfälle abgedeckt.

Das nicht, aber wenn es welche gibt, die du dir nur nicht vorstellen kannst, hast du sie zumindest mal aktiv verhindert.

Wenn ich also eine Klasse schon öffne, und die gesteigerte Komplexität in Kauf nehme, dann sollte ich auch einen konkreten Anwendungsfall damit abdecken wollen. Anderenfalls, YAGNI.

YAGNI heißt für mich, dass man etwas nicht einzubauen braucht, für das man noch keine Verwendung absehen kann. Ich sehe darin nicht, dass man derzeit unbekannte Anwendungsfälle aktiv verhindern muss.

Vor langer Zeit hab ich mal eine Änderung für ein PHP-Framework vorgeschlagen, weil ich da für mich einen Anwendungsfall gesehen habe, der sich mit den vorgegebenen Komponenten nicht realieren ließ. Begründet wurde die Ablehnung mit der 80/20-Regel. Für 80% der vermuteten Anwendungsfälle war Funktionalität da, die anderen 20% hat man verständlicherweise nicht einbauen wollen. Das wäre für die meisten nur Ballast. Aber muss man denn dann die Komponente so bauen, dass die unberücksichtigten 20% sich gar nicht mehr realisieren lassen? Ich wollte ja keine Funktionalität hinzugefügt haben, sondern lediglich in der Lage sein, etwas für einen Spezialfall erweitern zu können. Es musste dazu lediglich irgendeine Kleinigkeit geändert werden, sowas wie private gegen protected zu tauschen.

dedlfix.