marcusson

Du weißt doch: Namen sind Schall und Rauch
Das ist genauso wie die Frage, "wie nennt man die Implementierung eines Softwarkonzepts auf Grundlage eines Frameworks?"

A) Klasse b) Komponente c) Plugin d) Erweiterung e) Implementierung f) Application e) derived application/software g) ... *g*

Über Benennungen lässt sich trefflich streiten -> eine schöne Aufgabe für Theoretiker.

Mister Ad

Zergling-new

Sogesehen könnte ich meine Datenbankklasse auch DieterBohlen nennen

marcusson

Stimmt genau. Aber da würdest du wahrscheinlich Ärger mit seinem Management kriegen

Basti

Ich denke, da gibt es halt zwei Möglichkeiten: Entweder du setzt eben eine Fassade auf um das fehlende Interface zu kompensieren oder du Entwirfst einfach mit Interface und lässt das hinterher dann weg. Wie gesagt sind hier die UnitTests der Punkt, den die Klassen passieren müssen und in denen eine falsche Schnittstelle aufgedeckt wird, auch wenn es keinen Compiler gibt, der diese prüfen könnte.

Absolut! Ich will ja auch garnicht den Vorteil von Interfaces in Frage stellen.

Naja, ich hoffe doch, dass bei der Software, die ich verwende das Prüfen der Implementierung nicht dem Compiler überlassen wird. Um Tests kannst du dich wie gesagt auch nicht mit einer Interface-Klasse herum drücken!

Nochmal: Testen!

Einerseits ist es natürlich albern, sich stundenlang hinzusetzen und sich den Kopf darüber zu zerbrechen ob das nun so oder so heißen müsste der ob ev. keiner der vorhandenen Begriffe so richtig passt. Andererseits sind ja Paterns benannte Lösungen für immer wiederkehrende Probleme. Und somit auch eine Vereinbarung, mit der Kommunikation erleichtert wird. Wenn hier jemand schreibt: Setzt das doch als Singleton um, dann ist klar, was gemeint ist und das Konstrukt muss nicht weiter erläutert werden.

Unser Rumgeeier hier rührt ja wohl nur daher, dass wir nicht wirklich fit in Sachen Patterns sind.

Basti

marcusson

Naja, wenn man ein Pattern benennen könnte, das genau passt, dann wäre die Sache natürlich einfacher.

Testen... nun ja: das ist natürlich wichtig. Aber das erinnert mich auch immer an die Ausage von meinem Prof im ersten Semester: "Testen belegt immer nur die Anwesenheit von Fehlern. Es kann niemals deren Abwesenheit beweisen".

Und mit dem Beweisen eines Codes ist das so eine Sache. Ich weiß zwar wie das geht, aber ich möchte es nicht machen müssen, weil es einfach nur katastrophal aufwendig ist.

Ergo: Vorsorge und Prüfung sind IMHO gleich wichtig.