Re: Grundsatzfrage zum Klassen-Design

• Previous message: Rainer Müller: "Re: ProgressBar aus- bzw. einblenden"
• In reply to: Immo Landwerth: "Re: Grundsatzfrage zum Klassen-Design"
• Messages sorted by: [ date ] [ thread ]

Date: Sat, 31 Jul 2004 07:53:31 +0200

Immo Landwerth <mail_ignored@web.de> schrieb:

> Carsten Posingies wrote:
>
>> So, und jetzt mache ich eben 1:1-"Relations" zwischen Tabellen
>> und Klassen daraus. 1 neues Feld = 1 neues Mitglied + 1 neuer
>> Zugreifer (VS.NET-Makros bestellen schöne Grüße, sprich:
>> "private <type> <name>" eingetippt, Makro aufgerufen, Zugreifer
>> der Optik halber verschoben, fertig ist die Laube).
>
> Jetzt stehe ich vielleicht auf dem Schlauch, aber was willst Du
> mir damit sagen?

Dass, wenn sich Tabellen ändern, sowohl Du als auch ich in den Code
eingreifen muss(t).

>>> Just FMI: Was stört Dich an [Interfaces]?
>> (meine Antwort)
> Harter Tobak.
>
> Also zum einen sind Interfaces für mehr als nur Versionierung bzw.
> Validierung durch den Compiler gut. Ich hatte zwar in meinem
> letzten Posting den Fokus stärker auf letztes gelegt, aber das
> ist nicht der einzige "Gag" an Interfaces.

Sicherlich haben Interfaces ihren Zweck. Ich habe jedoch nach wie vor
den Eindruck, dass viel von dem Tamtam, den MS um Interfaces macht,
daran liegt, dass sie damit ihre Entscheidung pro Interfaces und contra
Mehrfachvererbung begründen wollen: "Schaut mal, was man alles Tolles
mit Interfaces machen kann!" Letztlich wird das Interface-Konstrukt
jedoch weniger interessant, wenn Du Mehrfachvererbung und Templates
hast. Templates kommen ja mit der nächsten C#-Version in modifizierter
Form. Mehrfachvererbung wäre dann das I-Tüpfelchen, aber darauf kann ich
wohl noch sehr lange warten -- oder wieder auf C++ umsteigen, aber wenn
man ne Weile C# schreibt, findet man C++ irgendwie hässlich und
umständlich.

> Natürlich arbeite auch ich mit Regulären Ausdrücken, schon lange
> bevor ich zu VisualStudio oder .NET kam.
>
> Aber Dein Posting erweckt den Eindruck, man brauche keine
> Interfaces, sofern man mit regulären Ausdrücken umgehen kann. Und
> das ist einfach nur großer Käse.

Ich finde es eigentlich "nur" grundsätzlich schlecht, Interfaces dazu zu
verwenden, den Compiler zum Generieren von Fehlermeldungen zu bewegen.

>> Aua. Wieder ein tolles Feature vom VS.NET: "DataBinding"! (...)
>
> Ja. :) Aber das haben viele Leute unter Delphi und VB lange Zeit
> zum Volksport gemacht...

Und das VS unterstützt es nach wie vor exzessiv, statt irgendwelche
Add-Ins bereitzustellen, die DAL-Klassen aus Datenbanken erzeugen
können. Auch hier in den .NET-NGs wird sehr oft nach DataBinding
gefragt, ebenso in vielen .NET-Foren. Dieser Unfug ist also nach wie vor
lebendig. Lässt sich offenbar so schwer ausrotten wie eine
Kakerlaken-Kolonie.

>>> Exakt. Das Problem an solchen Änderungen ist ja oftmals gar
>>> nicht, dass es sich durch alle Tiers ziehen, sondern dass man
>>> nicht alle Stellen enstsprechend der Änderung anpasst. Das liegt
>>> i.d.R. schlicht daran, dass irgendwo in den Untiefen der BL
>>> (oder ehrlich gesagt dem Client) SQL Statements liegen, die
>>> nicht angepasst wurden.
>>
>> Sorry, dazu fällt mir nur ein "Ätschibätsch!" ein....
>
> Richtig, mit einer vernünftigen Architektur (wie z.B. bei meinem
> Vorschlag) wäre das nicht passiert.

Ja, aber angeblich gehört so eine Architektur ja schon zu den "advanced
practises", und im MSDN findet man nur ansatzweise etwas zum Thema.

>>> Bei Dir wären dass auch die Klassen, die mittels Reflection
>>> automagisch auf Tabellen der DB gemapped werden.
>>
>> Das ist richtig, aber wenn ich irren Spaß daran hätte, würde ich
>> mir das als Add-On ins VB basteln (Klick auf die Tabelle, fertig
>> ist die Klasse). Da ich lieber Geld verdiene, pflege ich die
>> Konsistenz mit der Hand, und zwar in genau einer einzigen
>> Source-Datei, wo ich alle DAL-Entity-Klassen zusammenstelle.
>
> Natürlich kannst Du das so machen, aber damit bist auf _einen_
> bestimmten Datenprovider festgenagelt.

Naja, ich bin auf alles festgenagelt, was ein DataSet als Input und
Output versteht/erzeugt. Meine SQL-Statements sind so generisch wie
möglich und orientieren sich am kleinsten Nenner in Sachen
SQL-Commandset. Der Rest ist eine Frage des connection-Strings, und der
steckt natürlich nicht in der Klasse. Abgesehen davon muss sich wohl
jeder Entwickler in DAL entscheiden, ob er aus Abstraktionsgründen einen
generischen Treiber (OleDb, Odbc) oder aus Performancegründen einen
spezifischen für MS-SQL-Server, für Oracle, für MySQL usw. benutzt.

> BTW, SP wirst Du so auch nicht in den Griff bekommen - aber das
> willst Du ja auch gar nicht :)

Richtig, weil mich SPs nun endgültig auf eine DBE festnageln. Was mache
ich mit all meinen schönen SPs, wenn Kunde X unbedingt eine "Advantage
Server Engine" fährt? Das ist ein Hybrid-Aufsatz auf dBase-Tabellen.
Wenn ich definitiv gegen eine vorgegebene DBE entwickle, benutze ich hin
und wieder auch mal SPs (wenn sie denn so viel Performance bringen
sollten, dass es sich lohnt). Aber Du weißt sicher aus der Praxis, was
der Wechsel eines Geschäftsführers oder des Abteilungsleiters IT
bewirken kann... heute noch SQL-Server, morgen Oracle, und schon kannst
Du alle Deine SPs in die Tonne kippen, und im schlimmsten Fall (Murphy
lässt grüßen) kannst Du die Funktionalität der alten SPs nicht in der
neuen DBE abbilden, also musst Du doch wieder an die Sourcen ran.

>>> Das Hauptproblem an solchen Abhängigkeiten liegt darin, dass man
>>> sie nur durch gründliche Source Recherche oder per "Ups!"-Effekt
>>> zur Laufzeit findet. Sie sind nicht durch den Compiler zu
>>> finden.
>>
>> Gut, das zu wissen. Mir ist der Compiler als
>> Source-Debugging-Tool nämlich ausgesprochen suspekt...
>
> Tatsächlich? Mir ist es lieber der Compiler sagt mir vorher das
> etwas nicht funktionieren wird, als wenn ich es selbst zur
> Laufzeit finden muss...

Ja, das ist mir schon klar. Neben .NET hacke ich derzeit in einer
antiken Sprache namens "XBase++" herum. Das ist ein "Clipper"-Nachfahre.
Der Compiler meckert da über fast gar nichts, weil die Syntax-Specs so
lazy sind, dass man staunt. Beispiel:

function foo(a, b, c)
 ...
return x

Diese function kannst Du nun als foo(), als foo(1, 2) und auch als
foo(1, "bar", 3, 4) aufrufen, nach Spec alles korrekt.

Sowas schult ungemein darin, Code absolut sauber zu schreiben und sich
eine Unmenge an Tools zu bauen. Der ursprüngliche Code der beiden
Gründer der Firma sieht jedenfalls danach aus, wo die beiden
"herkommen", nämlich nach Basic und Clipper. Ich hab ewig gekämpft, bis
wir nun konsequent OO machen und Methoden-Signaturen durch "lustige ifs"
simulieren, sodass wenigstens zur Laufzeit das Programm nicht abrauscht,
sondern Fehler meldet.

Jedenfalls habe ich in meiner Berufspraxis die Erfahrung gemacht, dass
es wesentlich angenehmer ist, während der Entwicklung ein paar Deadlines
zu überschreiten und sich das Gemosere des Kunden und des Vertriebs
anzuhören, dafür aber ein paar Wochen nach Auslieferung nichts mehr vom
Kunden zu hören, weil alles funktioniert, als wenn es andersrum ist und
man fehlerhafte Software ausliefert, die einen dann Monate in Atem und
von neuen Projekten abhält. Deswegen bin ich so extrem pingelig, was
fehlerfreien Code betrifft.

Klar, keine Software ist fehlerfrei, aber wenn man beispielsweise
Methoden-Namen per ^C^V in den Code packt, statt sie zu tippen,
vermeidet man so einige Typos. .NET-Compiler motzen da, aber z.B. mein
toller XBase-Compiler eben nicht. Und so schnell findet man die Stelle
eben nicht, wo statt "ZeigeWarnungen()" eben "ZeigeWanrungen()" steht.

>>> Zugegeben, der Code innerhalb der Manager, ist natürlich nicht
>>> ohne weiteres durch den Compiler kontrollierbar (SQL im String),
>>> weswegen ich auch stark auf SPs baue.
>>
>> Ich baue lieber auf die Akribie des Entwickels. Wer damit nicht
>> leben kann, nunja...
>
> Meiner einer baut lieber darauf, dass ich weiß, dass ich Fehler
> mache und immer machen werde. Also versuche ich lieber die
> Fehlerquellen zu minimieren statt darauf zu hoffen, dass ich
> akribisch genug sein werde.

Da widerspreche ich Dir ja nicht. Ich sage halt, dass die Reihenfolge
"1. Akribie und Konzentration - 2. Tools - 3. Compiler - 4. Debugger"
schon ihren Sinn hat ;-) Und letztlich reden wir ja nicht wirklich über
Typos, sondern über logische Fehler. Und da fällt der Compiler als
Werkzeug meist raus. Tools sind da extrem sinnvoll, aber aufwändig zu
erstellen. Deswegen halte ich es da ganz schwer mit 1. und dem guten,
alten "KISS"-Prinzip.

Carsten

• Previous message: Rainer Müller: "Re: ProgressBar aus- bzw. einblenden"
• In reply to: Immo Landwerth: "Re: Grundsatzfrage zum Klassen-Design"
• Messages sorted by: [ date ] [ thread ]