Trennung von GUI und Logik, wie geht ihr vor?

[SebE]

Zitat:

Zitat von stahli (Beitrag 1118159)

Zitat:

Zitat von SebE (Beitrag 1118156)

Der Thread heißt "Trennung von GUI und Logik".
Wenn du uns zeigen kannst, wie man ohne Vererbung diese gewünschte Trennung vollziehen kann, bin ich sofort ruhig.
Bis dahin sage ich: Wieder am Thema vorbei.

Was meinst Du damit?

Ich bin einfach der Meinung, dass man die Trennung nur durch Abstraktion (also mittels Vererbung) erreichen kann.

[bernerbaer]

sorry, wenn ich am Thread vorbei rede. Aber zurück zum Beispiel der Addition. Eine Trennung von GUI und Logik ist in diesem Mini-Beispiel definitiv nicht machbar. Zahl1 und Zahl2 sind zwingend mit der Form verbunden. D.h. benötige ich wie im Beispiel nur die Addition, weshalb soll ich eine Abstraktionsebene aufbauen in einem einzubindenden externen Objekt? Wo liegen hier die Vorteile der Trennung (nur in diesem Beispiel? Vererbung - was soll vererbt werden? Wiederverwendbarkeit des Codes? Kann ich mit Copy und Paste schneller, bessere Lesbarkeit des Codes?)

Nein, ich gehöre nicht zu den Programmierern die einfach Buttons und Edits auf die Form klatschen! Ich bin ein Programmierer der sich überlegt was er macht und den Aufwand und Ertrag abschätzt. Wo Trennung von GUI und Anwendungslogik sinn macht, setze ich es auch ein. Aber ich bin nicht ein Gläubiger der macht, was die Mehrheit sagt.

[SebE]

Zitat:

Zitat von Progman (Beitrag 1118162)

Aber was ist mit einem solchen "dreiteiligen" (ich nenns mal so) Programmieren, wenn 1 Woche vor Deadline der Entscheider meint, dass auf der Oberfläche noch einige Bedienelemente sein müssen, die dann Fenster erscheinen lassen, wo der User was eingeben/einstellen kann? In der normalen RAD-Programmierung geht das ruckzuck. Nach diesem "Model" müsste ich alle drei Teile erweitern und zusehen, dass ich die auch exakt wieder verbinde. Resultat wäre doch sicherlich ein Code-Chaos, wo man bei eventuell nötigen Änderungen gar nicht mehr durchblickt :lol:
Ich programmiere seit über 25 Jahren und bin der Meinung, dass hier extremst ubers Ziel hinausgeschossen wird. Das riecht verdammt nach OOP-Fetischismus *gg*

Das kommt immer auf die konkrete Aufgabenstellung an.
Das Model zu erweitern sollte der gleiche Aufwand sein wie beim RAD.
Neue Verbindungen zu ziehen, sollte dank "Philosophie" (die in einer Dokumentation - falls vorhanden - ersichtlich wäre) "relativ" leicht gehen.
Und am Ende entsteht nicht dieses Durcheinander wie beim RAD.

Man darf es auf beiden Seiten (Pro-OO und Contra-OO) nicht zu sehr verallgemeinern.
Es sind Philosophien, die Vor- und Nachteile mit sich bringen.
Ein Beispiel, was mir einfällt, um das zu verdeutlichen, wäre ein von Hand geschriebener Parser (eines Compilers), der Syntaxregeln folgt.
Sollte man den Parser nach den Durchläufen (Quellsprache Parsen, Zwischensprache generieren, Zielsprache generieren) oder nach den Regeln (If-Statement, For-Statement, Class-Definitio, ...) "ausrichten".

Vorteil der Ausrichtung nach Durchläufen:
Neue Durchläufe können schnell eingebaut werden (zB ein weiterer Optimierungsschritt auf der Zwischensprache).
Vorteil der Ausrichtung nach Regeln:
Neue Sprachkonstrukte können schnell eingebaut werden (zB for-each-Statement).

Wie man sieht, ist alles Situationsabhängig. Man muss eben abwägen.

[divBy0]

Zitat:

Zitat von SebE (Beitrag 1118161)

Dann hast du die Wahl: zwei Lösungen wurden vorgestellt (mehr kenne ich auch nicht):
- Nativ ohne Framework-Einsatz (mein Code sollte einen Einblick gegeben haben, wo die Knackpunkte liegen)
- "magische Lösung", bei der vieles versteckt wird und das Projekt schön klein bleibt.

Wenn du es unbedingt (aus Bildungsgründen) zu Fuß machen möchtest, schaue dir folgende Pattern an:
Observer, Visitor, Proxy

Ich muss mir die beiden Varianten jetzt mal genauer anschauen. Bei der "magischen Lösung" warte ich erst mal bis das Beispiel funktioniert. :-D

Noch mal, die Addition sollte hier nur ein Beispiel sein. Auch bei diesem Mini-Beispiel sollte eine Trennung möglich sein. In der Praxis sind die Klassen auch um einiges Größer (ca. 25 Parameter und verschiedene komplexe Berechnungen) nur die Klassen darf ich leider hier nicht posten.

Vielen Dank euch allen schon mal für die rege Teilnahme hier. Vielleicht kommen ja noch ein paar interessante Ideen oder Beiträge hinzu. Es würde mich sehr freuen! :thumb:

[SebE]

Zitat:

Zitat von bernerbaer (Beitrag 1118165)

sorry, wenn ich am Thread vorbei rede. Aber zurück zum Beispiel der Addition. Eine Trennung von GUI und Logik ist in diesem Mini-Beispiel definitiv nicht machbar. Zahl1 und Zahl2 sind zwingend mit der Form verbunden. D.h. benötige ich wie im Beispiel nur die Addition, weshalb soll ich eine Abstraktionsebene aufbauen in einem einzubindenden externen Objekt? Wo liegen hier die Vorteile der Trennung (nur in diesem Beispiel? Vererbung - was soll vererbt werden? Wiederverwendbarkeit des Codes? Kann ich mit Copy und Paste schneller, bessere Lesbarkeit des Codes?)

Darum geht es dem TE doch garnicht.
Er hätte auch ein beliebig größeres Beispiel wählen können.
Hater er aber nicht - damit müssen wir uns abfinden und nicht darauf rumreiten, dass es wenig Sinn ergibt.
Ich denke, je kleiner das Beispiel, desto einfacher kann man ein Verständnis für die Grundlagen erlangen.
Bei größeren Beispielen treten wieder Sonderfälle auf (ich habe selbst welche erwähnt), die vom Grundproblem ablenken und den Lernprozess behinern.

[divBy0]

Ihr dürft gerne auch ein umfangreicheres Beispiel posten...

[Stevie]

Zitat:

Zitat von bernerbaer (Beitrag 1118165)

sorry, wenn ich am Thread vorbei rede. Aber zurück zum Beispiel der Addition. Eine Trennung von GUI und Logik ist in diesem Mini-Beispiel definitiv nicht machbar. Zahl1 und Zahl2 sind zwingend mit der Form verbunden. D.h. benötige ich wie im Beispiel nur die Addition, weshalb soll ich eine Abstraktionsebene aufbauen in einem einzubindenden externen Objekt? Wo liegen hier die Vorteile der Trennung (nur in diesem Beispiel? Vererbung - was soll vererbt werden? Wiederverwendbarkeit des Codes? Kann ich mit Copy und Paste schneller, bessere Lesbarkeit des Codes?)

Nein, ich gehöre nicht zu den Programmierern die einfach Buttons und Edits auf die Form klatschen! Ich bin ein Programmierer der sich überlegt was er macht und den Aufwand und Ertrag abschätzt. Wo Trennung von GUI und Anwendungslogik sinn macht, setze ich es auch ein. Aber ich bin nicht ein Gläubiger der macht, was die Mehrheit sagt.

Seit wann sind 2 Zahlen für eine Addition mit einem Form verbunden? Schreib mal die App um, damit eine Konsolenanwendung draus wird. Jaja, bei dem Additionsbeispiel isses Killefit. Aber ich kanns auch noch gern zum xten mal sagen, es ging bei diesem Beispiel um die Ansätze und nicht darum, ob es Sinn ergibt.

Copy und Paste verletzt schonmal eine der grundlegendsten Regeln ("don't repeat yourself"), an die ich mich persönlich versuche zu halten (klappt auch nicht immer :oops:)

[Chemiker]

Hallo,

ich finde das Thema sehr interessant. Das Beispiel ist auch OK.

Ich versuche diese Trennung, wenn möglich auch immer hinzubekommen. Meine Erfahrung ist aber leider, wenn die GUI erweitert werden soll müssen die Daten ja in der Regel bis zur Business-Logik durchgereicht werden. Wenn wir bei dem Beispiel bleiben währe die Erweiterung der GUI um eine Edit-Komponente die eine 3 Zahl aufnimmt für die Berechnungen.

Bis bald Chemiker

[bernerbaer]

Zitat:

Zitat von Stevie (Beitrag 1118170)

Seit wann sind 2 Zahlen für eine Addition mit einem Form verbunden?

Siehe Ausgangspost:

Delphi-Quellcode:

..
type
  TForm1 = class(TForm)
    EditZahl1: TEdit;
    EditZahl2: TEdit;
...

und so würde das Beispiel bei mir aussehen
Pseudocode:

Code:

uses
meineMathUnit;

Resultat:= MeineAdditionsfunktion(zahl1,zahl2)

[SebE]

Zitat:

Zitat von bernerbaer (Beitrag 1118173)

Zitat:

Zitat von Stevie (Beitrag 1118170)

Seit wann sind 2 Zahlen für eine Addition mit einem Form verbunden?

Siehe Ausgangspost:

Delphi-Quellcode:

..
type
  TForm1 = class(TForm)
    EditZahl1: TEdit;
    EditZahl2: TEdit;
...

Das sind die visuellen Repräsentationen der Zahlen. Die Zahlen selbst sind es nicht (das drückt auch der Typ TEdit aus).
Man kann auch

Delphi-Quellcode:

TAddition.Addition(2, 3)

aufrufen.

Wie man sieht, gibt es min. zwei Schichten oder Komponenten, die man trennen KANN.

[Stevie]

Habt ihr übrigens gemerkt, dass die Binding Lösung auch die Typen Konvertierung von String in Int und wieder zurück übernimmt? ;) (mit nem kleinen Fehler im Demo seh ich gerade, negatives Ergebnis wird nicht richtig als signed Integer umgewandelt - fixed)

@divBy0: Beispiel müsste nach einem Update des svn repos nun fehlerfrei und erwartungsgemäß laufen.

[SebE]

Zitat:

Zitat von Stevie (Beitrag 1118177)

Habt ihr übrigens gemerkt, dass die Binding Lösung auch die Typen Konvertierung von String in Int und wieder zurück übernimmt? ;)

Du bist lustig!
Wie würde es denn anders funktionieren, besser: wo würde man es denn sonst noch einsetzen können?

Integer werden automatisch zu Zeichenketten, Zeichenketten werden automatisch zu Bezeichnern.
Das geht doch nicht mit rechten Dingen zu :twisted:

[ehX]

Ist es in der realen Welt nicht oft so, dass sich manche Porgrammierer gegenseitig lobhudeln, weil sie ach so tollen Code geschrieben haben und man auch noch in manchen Foren zerrissen wird, wenn man etwas nicht nach dem höchsten Gut der Programmierkunst programmiert hat, jedoch dann, im Gegensatz dazu, oft Programme mit "miesem" Code jahrelang überleben und erfolgreich sind? :-)

Warum ich das sage: Gutes Codedesign ist zwar generell löblich, jedoch nicht immer der Schlüssel zum Erfolg.
Oft trift sogar das Gegenteil zu: Die in kürzester Zeit hingewurschtelte "Quick'n dirty"-Lösung sichert einem oft genug den nächsten Auftrag vom gleichen Kunden :-D

Ich arbeite derzeit z.B. sehr viel in php mit dem Zend-Framework....mag sein, dass das "gutes" MVC ist..allerdings ist die unübersichtlichkeit aufgrund der MVC_Struktur so extrem, dass die Produktivität m.E. völlig flöten geht und ich das ganze in "bösem" prozeduralen Code oder auch OOP-Code, der nicht so extrem getrennt ist, schon 10x geschrieben hätte und der Kunde nicht so lange warten müsste.


Edit: Das ist nur meine Meinung! Um es nochmal zu verdeutlichen. :-)

[Stevie]

Zitat:

Zitat von SebE (Beitrag 1118179)

Zitat:

Zitat von Stevie (Beitrag 1118177)

Habt ihr übrigens gemerkt, dass die Binding Lösung auch die Typen Konvertierung von String in Int und wieder zurück übernimmt? ;)

Du bist lustig!
Wie würde es denn anders funktionieren, besser: wo würde man es denn sonst noch einsetzen können?

Integer werden automatisch zu Zeichenketten, Zeichenketten werden automatisch zu Bezeichnern.
Das geht doch nicht mit rechten Dingen zu :twisted:

Der Default Converter, den ich einsetze, kann fast alle simplen Datentypen. Hab ihm aber auch noch so kleine Nettigkeiten wie von Object auf Boolean (Assigned) verpasst. So dass man einfach mal abhängig davon, ob ein Item selektiert ist oder nicht Aktionen enablen/disablen oder visible machen kann.

Zitat:

Zitat von ehX (Beitrag 1118181)

Ist es in der realen Welt nicht oft so, dass sich manche Porgrammierer gegenseitig lobhudeln, weil sie ach so tollen Code geschrieben haben und man auch noch in manchen Foren zerrissen wird, wenn man etwas nicht nach dem höchsten Gut der Programmierkunst programmiert hat, jedoch dann, im Gegensatz dazu, oft Programme mit "miesem" Code jahrelang überleben und erfolgreich sind? :-)

Warum ich das sage: Gutes Codedesign ist zwar generell löblich, jedoch nicht immer der Schlüssel zum Erfolg.
Oft trift sogar das Gegenteil zu: Die in kürzester Zeit hingewurschtelte "Quick'n dirty"-Lösung sichert einem oft genug den nächsten Auftrag vom gleichen Kunden :-D

Ich arbeite derzeit z.B. sehr viel in php mit dem Zend-Framework....mag sein, dass das "gutes" MVC ist..allerdings ist die unübersichtlichkeit aufgrund der MVC_Struktur so extrem, dass die Produktivität m.E. völlig flöten geht und ich das ganze in "bösem" prozeduralen Code oder auch OOP-Code, der nicht so extrem getrennt ist, schon 10x geschrieben hätte und der Kunde nicht so lange warten müsste.


Edit: Das ist nur meine Meinung! Um es nochmal zu verdeutlichen. :-)

Das mag in einem gewissen Grad und bei einem Einzelkämpfer oder einem kleinen Team auch gut funktionieren. Wird das Projekt aber mit der Zeit immer größer und umfangreicher und viele Personen sind damit beschäftigt, dann ist es einfach fast nicht mehr machbar mit der hingewurschtelten "Quick'n dirty" Lösung. Andere oder man selber muss den Code nach Jahren noch pflegen und erweitern.

Hat eigentlich schonmal jemand in diesem Thread das Wort Unittests fallen lassen? Jaja, es gibt so tolle Sachen wie TestComplete, aber bei einer Trennung kann ich mal ebend meine Business Logik durchtesten ohne dass ich darauf angewiesen bin, dass ich in Edit4 dies eingebe, auf Button1 klicke und in ComboBox2 was auswähle.

[ehX]

Zitat:

Das mag in einem gewissen Grad und bei einem Einzelkämpfer oder einem kleinen Team auch gut funktionieren. Wird das Projekt aber mit der Zeit immer größer und umfangreicher und viele Personen sind damit beschäftigt, dann ist es einfach fast nicht mehr machbar mit der hingewurschtelten "Quick'n dirty" Lösung. Andere oder man selber muss den Code nach Jahren noch pflegen und erweitern.

Da gebe ich dir recht. Ich wollte damit eigentlich auch nur sagen, dass ein Programmierer sich vielleicht nicht von Anfang an unbedingt komplett darauf stützen muss, den "saubersten" Code zu schreiben, da das auch oft für die eigenen Ideen oder die Lösung im Kopf kontraproduktiv ist.
Optimieren und aufräumen muss man irgendwann, ja, aber nicht unbedingt immer gleich sofort :-)

[Stevie]

Zitat:

Zitat von ehX (Beitrag 1118185)

Zitat:

Das mag in einem gewissen Grad und bei einem Einzelkämpfer oder einem kleinen Team auch gut funktionieren. Wird das Projekt aber mit der Zeit immer größer und umfangreicher und viele Personen sind damit beschäftigt, dann ist es einfach fast nicht mehr machbar mit der hingewurschtelten "Quick'n dirty" Lösung. Andere oder man selber muss den Code nach Jahren noch pflegen und erweitern.

Da gebe ich dir recht. Ich wollte damit eigentlich auch nur sagen, dass ein Programmierer sich vielleicht nicht von Anfang an unbedingt komplett darauf stützen muss, den "saubersten" Code zu schreiben, da das auch oft für die eigenen Ideen oder die Lösung im Kopf kontraproduktiv ist.
Optimieren und aufräumen muss man irgendwann, ja, aber nicht unbedingt immer gleich sofort :-)

Manchmal kanns dann auch zu spät sein.... Wie war nochmal das Sprichwort: "Wehret den Anfängen!"

Es muss jeder für sich entscheiden, ob er und sein Umfeld Nutzen davon hat, oder ob er "schludern" (nicht negativ gemeint) kann. Ich vergleich ein Programm oft mit einem Haus... und jeder kennt wohl den Begriff Pfusch am Bau. Aber bei Software meinen viele, dat sieht ja keiner, da kann ich ruhig alles zurechtpfuschen - "läuft ja".

Zum Thema: Wer schonmal mit ExpressionBlend was gemacht hat, weiß, wie geil das sein kann, wenn man fein trennt zwischen GUI und Logik.

[FredlFesl]

Zitat:

Zitat von Stevie (Beitrag 1118186)

Es muss jeder für sich entscheiden, ob er und sein Umfeld Nutzen davon hat, oder ob er "schludern" (nicht negativ gemeint) kann. Ich vergleich ein Programm oft mit einem Haus... und jeder kennt wohl den Begriff Pfusch am Bau. Aber bei Software meinen viele, dat sieht ja keiner, da kann ich ruhig alles zurechtpfuschen - "läuft ja".

Der Vergleich mit dem Hausbau, also Planung, Vorbereitung, Design, Ausführung ist sehr gut.

Ebenso, wie man ein Bauvorhaben totplanen kann oder sich bei Verwendung der aktuellsten und neuesten Technologie völlig verhaspelt, wird es in der praktischen Softwareentwicklung (betonung auf 'praktisch') eher so sein, das man nicht die allerneuesten Technologien verwenden wird, sondern die, die ihre Praxistauglichkeit über Jahre bewiesen haben.

Ebensowenig wie man rumfrickeln darf (Quick'N Dirty wird mit Teeren'N Federn belohnt), sollte man so lange refaktorisieren, bis man Preise für Schonheit im Code erhält, wenn man dabei Budget, Deadline und die Geduld des Kunden aus den Augen verliert.

Zwei Dinge sind wichtig (in meinen Augen):
Bei der Arbeit werden nur erprobte Techniken und Pattern verwendet, in der R&D-Zeit allerdings sollte man sich ständig weiterentwickeln.

[Stevie]

Zitat:

Zitat von FredlFesl (Beitrag 1118190)

Der Vergleich mit dem Hausbau, also Planung, Vorbereitung, Design, Ausführung ist sehr gut.

Ebenso, wie man ein Bauvorhaben totplanen kann oder sich bei Verwendung der aktuellsten und neuesten Technologie völlig verhaspelt, wird es in der praktischen Softwareentwicklung (betonung auf 'praktisch') eher so sein, das man nicht die allerneuesten Technologien verwenden wird, sondern die, die ihre Praxistauglichkeit über Jahre bewiesen haben.

Ich würde sowas, wie wir in diesem Thread behandeln eher mit nem Fertighaus vergleichen. Einzelne Teile werden getrennt von einander gebaut (GUI, Business Logik, Daten(klassen)) und vor Ort einfach zusammen gesteckt.

Zitat:

Zitat von FredlFesl (Beitrag 1118190)

Quick'N Dirty wird mit Teeren'N Federn belohnt

Den muss ich mir merken ;)

[Hansa]

Zitat:

Zitat von Stevie (Beitrag 1118191)

Einzelne Teile werden getrennt von einander gebaut (GUI, Business Logik, Daten(klassen)) und vor Ort einfach zusammen gesteckt.

Ne, da wird nichts getrennt gebaut. Es wird ein zusammenhängender Bauplan gemacht und dann den Gegebenheiten angepasst. Siehe hier :

Delphi-Quellcode:

procedure TfrmSuch.btnZurueckClick(Sender: TObject);
begin
  if not SuchDS.Bof then begin
    SuchDS.Prior;
    ZeigeDaten;
    btnWeiter.Enabled := true;
  end
  else begin
    showmessage ('keine vorhergehenden Daten vorhanden !');
    btnZurueck.SetFocus;
    btnZurueck.Enabled := false;
    btnWeiter.Enabled := true;
  end;
end;

Es geht dabei um eine Datensatz-Suche. An dieser Stelle ist SuchDS völlig unbekannt. ZeigeDaten sieht so aus :

Delphi-Quellcode:

procedure TfrmSuch.ZeigeDaten;
begin
end;

Das ist also quasi Nullnummer. :mrgreen: Da geht es ja darum, etwas zu suchen. Manchmal ist man zu weit und muss zurück oder umgekehrt. Das bleibt immer gleich. Egal, um was es geht. Die GUI ist also schon da. Die Logik wird später eben besetzt. Man nennt das auch OOP. :lol:

[stahli]

Es geht ja aber gerade darum, das zu trennen.

Du kannst Deine gesamten Daten und Zustände in Deiner Datenebene verwalten. Ebenso die Methoden, die die Geschäftslogik darstellen.
Wenn Du Deine Datenebene als Objekt betrachtest, könntest Du z.B. über TFirma.MitarbeiterListe.BefördereMitarbeiter(5) irgendeine Aktion veranlassen.
Dadurch wird der Mitarbeiter gleich noch in das Chefzimmer verschoben und bekommt das doppelte Gehalt. Das wäre dann die Geschäftslogik ;-)

So, das Programm an sich funktioniert jetzt schon mal wunderbar.

Jetzt müssen wir noch ein Formular basteln, das die Daten anzeigt und einen Beförderungsknopf erhält.
Das ist auch schnell erledigt.

Nun fehlt noch die Verbindung der beiden Ebenen.
Mit DataBinding kann man eben zur Entwicklungszeit der ListBox die Mitarbeiterliste zuweisen (bestenfalls direkt im Objektinspektor per Aufklappliste) und dem Schalter die Beförderungsmethode.
Letzteres ist u.U. schwieriger, da ja manchmal bestimmte Parameter übergeben werden müssen. DAS muss man dann sicher per Code regeln.
Aber sonst muss es in der GUI nicht mehr viel Quelltext geben.

Also ich habe Blut geleckt! :-)


EDIT:
Und wenn man mal auf die Idee kommt, das Projekt als Konsolenanwendung, als Webanwendung oder für FireMonkey ;-) lauffähig zu machen, muss man grundsätzlich nur die GUI ersetzen. Alles weitere bleibt in der Datenebene unverändert. Nur der Zugriff von außen wird verändert.
Das ist eben bei einer "klassischen Delphi-Anwendung" so nicht möglich. Ebenso nicht spätere gravierende Umstrukturierungen.

[Stevie]

Zitat:

Zitat von Hansa (Beitrag 1118200)

Zitat:

Zitat von Stevie (Beitrag 1118191)

Einzelne Teile werden getrennt von einander gebaut (GUI, Business Logik, Daten(klassen)) und vor Ort einfach zusammen gesteckt.

Ne, da wird nichts getrennt gebaut. Es wird ein zusammenhängender Bauplan gemacht und dann den Gegebenheiten angepasst. Siehe hier :

Delphi-Quellcode:

procedure TfrmSuch.btnZurueckClick(Sender: TObject);
begin
  if not SuchDS.Bof then begin
    SuchDS.Prior;
    ZeigeDaten;
    btnWeiter.Enabled := true;
  end
  else begin
    showmessage ('keine vorhergehenden Daten vorhanden !');
    btnZurueck.SetFocus;
    btnZurueck.Enabled := false;
    btnWeiter.Enabled := true;
  end;
end;

Es geht dabei um eine Datensatz-Suche. An dieser Stelle ist SuchDS völlig unbekannt. ZeigeDaten sieht so aus :

Delphi-Quellcode:

procedure TfrmSuch.ZeigeDaten;
begin
end;

Das ist also quasi Nullnummer. :mrgreen: Da geht es ja darum, etwas zu suchen. Manchmal ist man zu weit und muss zurück oder umgekehrt. Das bleibt immer gleich. Egal, um was es geht. Die GUI ist also schon da. Die Logik wird später eben besetzt. Man nennt das auch OOP. :lol:

Sorry, aber sowas geht echt ma garnicht, wenn man voneinander trennen möchte.

[Luckie]

Ich bin auch für eine Trennung von Daten und Oberfläche. Aber zu viele Ebene machen, meiner Meinung nach, das ganze zu unübersichtlich und führen die Trennung ad absurdum. Ich habe mal mit CakePHP gearbeitet, da gibt es auch dieses drei Schichten Model MVC (Model, View und Controller) das war hart an der Grenze. Deswegen würde ich das Formular ruhig die Additionsklasse kennen lassen. Noch eine Ebene dazwischen schieben, halte ich für überflüssig und für zu viel des Guten. Denn wo ist der Unterschied, ob das Formular jetzt die Additionsklasse kennt oder eine Schicht dazwischen? Irgendwann habe ich immer die Bindung von den Daten und der GUI.

[Hansa]

Zitat:

Zitat von Stevie (Beitrag 1118203)

wenn man voneinander trennen möchte.

Was geht nicht ??

[SebE]

Zitat:

Zitat von Luckie (Beitrag 1118204)

Ich bin auch für eine Trennung von Daten und Oberfläche. Aber zu viele Ebene machen, meiner Meinung nach, das ganze zu unübersichtlich und führen die Trennung ad absurdum. Ich habe mal mit CakePHP gearbeitet, da gibt es auch dieses drei Schichten Model MVC (Model, View und Controller) das war hart an der Grenze. Deswegen würde ich das Formular ruhig die Additionsklasse kennen lassen. Noch eine Ebene dazwischen schieben, halte ich für überflüssig und für zu viel des Guten. Denn wo ist der Unterschied, ob das Formular jetzt die Additionsklasse kennt oder eine Schicht dazwischen? Irgendwann habe ich immer die Bindung von den Daten und der GUI.

(fett durch mich)

Im Allgemeinen gilt: je mehr Abstraktionen, desto flexibler die Anwendung (die Kommunikation).
Ob der Code dabei übersichtlich bleibt, ist fraglich.
Man kann auch Abstraktionen einführen, die wenig Sinn ergeben oder einfach nicht hilfreich sind.

Klar hat man irgendwo Bindungen. Diese sollten aber - wenn möglich - an "festen" Ort (Controller) plaziert werden und nicht dort, wo am ehesten Änderungen stattfinden (GUI, gefolgt vom Model).

Ein Muss ist auf jeden Fall, eine Abstraktion der GUI aus Sicht des Models, dieses darf die View nicht kennen.
Anders herum ist es vllt nicht immer notwendig, aber "schöner", wenn man eine zusätzliche Schicht hat (Controller).
Denken wir einmal an die Überarbeitung (Refactoring) unserer Business-Objekte (Schnittstellen "verschönern"): Hier wäre es gut, wenn man die GUI belassen kann, wie sie ist.

@Hansa:
Sorry, ich habe deinen Beitrag leider nicht verstanden (ich erkenne an deinem Code-Schnipsel weder OOP, noch wird mir eine Art Ironie ersichtlich).
Ich erkenne nur, dass hier nicht getrennt werden wollte.

[Stevie]

Zitat:

Zitat von Luckie (Beitrag 1118204)

Ich bin auch für eine Trennung von Daten und Oberfläche. Aber zu viele Ebene machen, meiner Meinung nach, das ganze zu unübersichtlich und führen die Trennung ad absurdum. Ich habe mal mit CakePHP gearbeitet, da gibt es auch dieses drei Schichten Model MVC (Model, View und Controller) das war hart an der Grenze. Deswegen würde ich das Formular ruhig die Additionsklasse kennen lassen. Noch eine Ebene dazwischen schieben, halte ich für überflüssig und für zu viel des Guten. Denn wo ist der Unterschied, ob das Formular jetzt die Additionsklasse kennt oder eine Schicht dazwischen? Irgendwann habe ich immer die Bindung von den Daten und der GUI.

Ich argumentiere ja für MVVM und da kennt das Form garnix, es hat Anzeige Controls, fertig. Wenn man Business Logik ohne den Ablauf über die GUI designed, kann man sie auch ohne die GUI Testen. Du kannst einfach testen, ob diese oder jene Eigenschaft so ist, wie du es erwartest, wenn du einen Wert setzt. Diese werden letztlich über die GUI präsentiert. Aber das Programm wäre auch komplett ohne Oberfläche lauffähig.

Zitat:

Zitat von Hansa (Beitrag 1118206)

Zitat:

Zitat von Stevie (Beitrag 1118203)

wenn man voneinander trennen möchte.

Was geht nicht ??

- Logik direkt ins Event kodiert.
- abhängig von der Logik werden wiederum Controls beeinflusst; zwar im kleinen Rahmen in diesem Beispiel, läuft trotzdem dem zuwider, was ich vor dem Quote schrieb.
- Feedback direkt über ShowMessage ausgegeben.

Diese Methode allein ist nicht unittestbar um zum Beispiel zu schauen, ob das mit dem nicht weiter zurück blättern klappt, wenn man schon vorne ist.

[Medium]

Ohne negativ werten zu wollen (im Gegenteil): Ab und an frage ich mich ja dann doch, was es denn nun genau für einen Unterschied macht, ob ich bei Änderungen meiner Software meine Bindings nun im Quellcode, oder in einer separierten Deklarationsschicht umschreibe. Letztlich beides mit großer Wahrscheinlichkeit Textdateien, und "deployen" muss ich auch in beiden Fällen etwas. In der Quelle brauche ich lediglich meine Compilerumgebung statt Notepad - aber die sollte ich ja wohl tunlichst haben.
Nicht gleich hauen! Ich setze grad selbst radikale Abstraktionen in unserem Betrieb mit Nachdruck durch. Aber mir passiert es ja nun auch selbst gerne mal, dass ich vor lauter Streben nach Eleganz und Wohlgeformtheit die Praxis und den wirtschaftlichen Nutzen mal für eine Hand voll Stunden vergesse. Dabei selbst erwischt sag ich zu mir selbst: "Ach du verfluchter Theoretiker, das ist eine Maßlösung für einen Kunden, und es arbeiten max. 3 Leute daran, von denen 2 im selben Haus wohnen. Fertigwerden!" Es schubbelt aber doch ein wenig an der Berufsehre :)
Was is wohl sagen will ist: In Maßen, so lange es der (auch längerfristigen) Produktivität dient, alles prima. Man muss nur höllisch aufpassen, dass sich da kein Selbstzweck entwickelt, was ausgesprochen leicht passiert.

Im Alltagsgeschäft schaut es, bei mittelständischen Betrieben, zudem auch gerne mal so aus, dass Abstraktionen nach Bedarf entwickelt werden. Somit entsteht über Jahre ein Framework, dass immer mächtiger und hübscher wird - aber in vielen Iterationen/Versionen existiert, und da man anfangs fast nie alles bedenken kann was mal noch an Anforderungen kommt (einfach weil der Bedarf nie da war), man auch gerne zueinander inkompatible Stände hat. So dass das aktuelle Rahmenwerk nicht mehr zum Bearbeiten der ersten Hand voll Projekte auf dessen Basis dienen kann, weil zigfach geändert.
Sowas geht erst dann gut, wenn einem entweder die frühen Kunden die Zeit geben und bezahlen die man in ein derart umfangreiches und flexibles Framework investieren müsste (teilweise reden wir ja schon über Frameframeworks...), oder der Betrieb kann es sich leisten eigens dafür ein Team von Informatikern in Vollzeit abzustellen, die am eigentlichen Geschäftsfeld sonst eher wenig beteiligt sind. Unter einer mutig geschätzten 50-Mann-Softwareschmiede wohl eher seltener anzutreffen, und auch dort wird man anfangs RAD-like Code produzieren (weil so ein Framework ist ja nicht in 10h geplant und gebaut bzw. angepasst/gelernt), der entweder teuer nachträglich verhübscht werden muss, oder man ihn als Legacy-Fessel durch die Jahre buckelt, spätestens bis die Zielplatform am Ende ist.

Der wirtschaftlich nötige und sinnvolle Abstraktionsgrad ist, würde ich schätzen, einer der am schwersten abzuschätzenden Dinge in der Softwareentwicklung. Besonders weil seine Entwicklung ggf. selbst sehr viel Zeit bedarf, die man zwar auf die Gesamtheit aller je zu erstellenden Projekte positiv bilanzieren kann, sie aber schon vorab investieren muss, bevor man überhaupt auch nur ein Produkt verkaufen kann. Es sei denn, man verkauft Frameframeworks :mrgreen:
Wenn es Kunden gäbe, die diese Dinge hinterblicken würden - DAMIT wäre uns wirklich sehr geholfen. Aber gebt mal einem Einkäufer diesen Thread hier zu lesen... Der schnallt doch ab! (Ausser er ist ungewöhnlich "open minded". Normal ist da reines Kurzfristigzahlenkleinhalten das einzige Programm im Hirncomputer.)

Sö, ich bin nun bereit eure Knüppel in Empfang zu nehmen :)

[ConstantGardener]

....keine Knüppel, +1

[Stevie]

Nun, es geht hier ja nicht um Übertreibungen sondern eigentlich um einige der einfachsten Software Prinzipien (z.B. SRP) Man kann das hier in diesem Thread beschriebene mit einfachen Mitteln realisieren, oder man kann es over engineeren. Natürlich kann man beim "klassischen Ansatz" bleiben, wenn es sich um ne 0815 Anwendung handelt und man dadurch nix gewinnt. Aber es mag auch Anwendungen geben, die über hunderttausende Zeilen Code gehen, mit hunderten von Forms und Frames. Gratulation, wer da noch bei dem klassischen Ansatz den Überblick behält. Ich kenne solchen Code nur zu gut, wo über Jahre immer neue Anforderungen in nem Form oder Frame implementiert wurden. Inzwischen sind das Monster geworden, die jeder einfach nur am liebsten in die Tonne kloppen und neu machen würde.

[stahli]

Zitat:

Zitat von Stevie (Beitrag 1118228)

Nun, es geht hier ja nicht um Übertreibungen sondern eigentlich um einige der einfachsten Software Prinzipien (z.B. SRP) Man kann das hier in diesem Thread beschriebene mit einfachen Mitteln realisieren, oder man kann es over engineeren. Natürlich kann man beim "klassischen Ansatz" bleiben, wenn es sich um ne 0815 Anwendung handelt und man dadurch nix gewinnt. Aber es mag auch Anwendungen geben, die über hunderttausende Zeilen Code gehen, mit hunderten von Forms und Frames. Gratulation, wer da noch bei dem klassischen Ansatz den Überblick behält. Ich kenne solchen Code nur zu gut, wo über Jahre immer neue Anforderungen in nem Form oder Frame implementiert wurden. Inzwischen sind das Monster geworden, die jeder einfach nur am liebsten in die Tonne kloppen und neu machen würde.

Da schließe ich mich an. Mein dienstliches Projekt (ich durfte ab 1993 2 Projekte für unsere Arbeit entwickeln, obwohl ich nicht als Programmierer angestellt bin) ist genau solch ein Fall. Daran habe ich über 15 Jahr immer wieder etwas dran erweitert.
Klar, würde nach Jahren ohnehin anders arbeiten. Aber große Korrekturen sind jetzt vor allem wegen der Vermixung von Programmlogig und GUI-Controls kaum noch möglich. Ich brauche lange, bis ich erahnen kann, was ich damals programmiert habe ;-)

Eine klare Trennung von Geschäftslogik und GUI würde dabei m.E. erheblich helfen. In Zukunft werde ich darauf achten.

Es stellen sich nur zwei Fragen:
- Wie komfortabel kann die die zwei Schichten verbinden? (Bisher geht das im Delphi ja nativ nicht so einfach.)
- Kann ich mir für mein aktuelles Projekt (durch geringen Mehraufwand am Anfang) insgesamt Arbeit sparen? (Das trifft für große und komplexe Projekte ganz bestimmt zu.)

Dann muss man darauf achten, dass die Programmlogik und die Formularanwendung jeweils komplett kompilierbar und funktionsfähig sind (wengleich man letzteres schwer vollständig testen kann), wenn der andere Part nicht existiert.

Um mal ein kleines, überschaubares Projekt zu erstellen, würde ich auf eine solche Trennung auch verzichten. Aber sobald das Projekt doch ausgebaut werden soll, dann unbedingt...

[Chemiker]

Hallo,

Zitat:

Eine klare Trennung von Geschäftslogik und GUI würde dabei m.E. erheblich helfen. In Zukunft werde ich darauf achten.

meiner Meinung nach wird das Project nicht zwangsläufig Übersichtlicher durch die Trennung. Und wie schon erwähnt, ist es leider so, dass bei Änderungen alle Ebenen in der Regel betroffen sind. Das mehr an Quellcode ist mit den heutigen Mittel die Delphi zur Verfügung stellt auch kein Problem. Dass man mit der Trennung die einzelnen Module besser Testen kann ist auch ok, aber man muss natürlich auch die Übergabe zusätzlich testen.

Bis bald Chemiker

[neo4a]

Schönes Thema mit kontroversen Meinungen. Zur Ehrenrettung der "Hab-Ich-Schon-Immer-So-Gemacht"-Fraktion sollte vielleicht nicht unerwähnt bleiben, dass viele Lösungsansätze in Delphi erst seit relativ kurzer Zeit zur Verfügung stehen.

Meine Motivation, den Delphi-RAD-Ansatz (teilweise) zu verlassen, kommt aus der Einsicht, durchgängig testbaren Code zu entwickeln. M. Hevery (Chef-Tester von Google) hat die Vorteile von Data-Binding so zusammengefasst:

- MVC leidet naturgemäß an zirkulären Referenzen, die Probleme erzeugen und Unit-Testing sehr erschweren.
- Data-Binding kehrt den normalen Ablauf der Abhängigkeiten um, erlaubt es zirkuläre Referenzen zu vermeiden und weniger gekoppelte Systeme zu erzeugen.
- Data-Binding eliminiert viel Boiler-Plate-Code, der die Daten zwischen Model und View hin und her transportiert und macht unseren Code leichter lesbar und verständlicher.

Dieses Mantra hat er hier 2010 veröffentlicht und 1 Jahr später gibt es nun Delphi-Ansätze (aber nur für die letzten Versionen), wie man das Data-Binding nutzen kann.

N. Hodge (ehem. Delphi-Manager) hat in Zusammenhang mit Dependency-Injection hier gefordert:

Regel 1: Codiere immer mit/gegen Interfaces
Regel 2: Halte den Constructor einfach

Mit einem geeigneten Framework wie Emballo ("nimmt Interfaces den Schrecken") oder Stevies DSharp schreibt man nun Programme, die sich auf einmal "richtig" anfühlen. Auch wenn man es zurzeit noch nicht nutzt: Tests, Mockups, GUI-Austausch, verschiedene OS - das alles ist auf einmal greifbar nahe.

(Nicht nur HP's letzter Haken zeigt: Die IT-Zukunft wird durch die Software bestimmt. Und mir ist dabei wichtig, bei all den Wechseln gelassen bleiben zu können und bei Ziel-Plattform und -OS die zu bedienen, für die sich letztlich meine Kunden entscheiden.)

[QuickAndDirty]

[Edit]
sowas ähnliches was neo4a sagt... nur ohne die quellen...und nur binding mag ich nicht ganz so...
habe da in Javafx wirklich schlechte Erfahrungen mit gesammtelt.
[/Edit]

Zitat:

Zitat von Luckie (Beitrag 1118204)

Ich bin auch für eine Trennung von Daten und Oberfläche. Aber zu viele Ebene machen, meiner Meinung nach, das ganze zu unübersichtlich und führen die Trennung ad absurdum. Ich habe mal mit CakePHP gearbeitet, da gibt es auch dieses drei Schichten Model MVC (Model, View und Controller) das war hart an der Grenze. Deswegen würde ich das Formular ruhig die Additionsklasse kennen lassen. Noch eine Ebene dazwischen schieben, halte ich für überflüssig und für zu viel des Guten. Denn wo ist der Unterschied, ob das Formular jetzt die Additionsklasse kennt oder eine Schicht dazwischen? Irgendwann habe ich immer die Bindung von den Daten und der GUI.

Ich sehe das so, in einem MVC müssen die 3 Programmteile mit einander informationen austauschen ohne sich zu kennen.

Andererseits will ich nicht wirklich Zwischenebenen einbauen die jeweils 2 oder alles Teile Kennen und quasi eine Postkasten(Messagequeue) Funktion erfüllen.


Die einfachste möglichkeit sehe ich also darin IControler, IView und IModel zu definieren und jeweils gegenseitig zu registrieren.

Wichtig dabei ist das es NICHT ein IView, IControler und IModel gibt sondern das es durchaus möglich ist das ich weiter aufteile und ableite
IStammdatenView, IStammdatenControler, IStammdatenModel
IBewegungsdatenView, IBewegungsdatenControler, IBewegungsdatenModel

usw.

Klassen die diese Interfaces implemtieren lassen sich dann einfach einander als Interface Registrieren egal was am ende wirklich da bedient wird.

Es ist dann auch egal ob das Formular Spaghetticode enthält, weil für die Betrachtunge der Gesammtaufgabe braucht man sich nur an den Interfacedefinition orientieren und im Kleinen ist Spaghetti code ertragbar(verzicht auf binding).

Leider habe ich noch kein Programm gesehen das auf diese Art und weise entwickelt wurde...
außer eines...aber da wurde kein Interface benutzt sondern jede ebene jedes Anwendungsfalles mit einem Webservice dargestellt(StammdatenViewWebservice,StammdatenCon trolerWebservice,StammdatenModelWebservice) und SOAP legt die Zugriffsmöglichkeiten ja auch ziemlich gut fest ohne das man sich gegenseitig ganz genau kennen muss ähnlich wie Interface...man muss eben nur die Adresse wissen.

[divBy0]

Binding kommt ja erst mit XE2, DSharp von Stevie funktioniert erst ab D2010 so einigermaßen wegen den Generics. Ich hab jetzt noch nicht mit Google gesucht, aber gibt es denn weitere Binding-Komponenten?

Wenn ich das richtig verstehe konnte man bisher eigentlich nur mit MVC eine Trennung durchführen.

DSharp gefällt mir echt gut und ich experimentiere damit jetzt etwas rum.

[Luckie]

Zitat:

Zitat von divBy0 (Beitrag 1118258)

Binding kommt ja erst mit XE2, DSharp von Stevie funktioniert erst ab D2010 so einigermaßen wegen den Generics.

Ach deswegen habe ich seine Lösung nicht verstanden. Ich habe noch 2006 und noch nie mit Generics was am Hut gehabt.

[SebE]

Zitat:

Wenn ich das richtig verstehe konnte man bisher eigentlich nur mit MVC eine Trennung durchführen.

Ich würde es so sagen: MVC ist das intuitivste, machen kannst du das, wie es dir beliebt.
FÜr mich ist MVC mehr ein Gedanke, die Umsetzung im Detail entspricht auch nicht dem "Standard" (den es ja so garnicht gibt).
Entwurfsmuster sind ja nur grobe Ideen (die Philosophie einer Problemlösung)

[stahli]

@DivBy0 + Luckie
Die Generics sind dabei nicht so maßgeblich, aber die neue RTTI ist eine Voraussetzung für die Bindung von außen.
Das anzubindende Objekt muss z.B. untersucht werden, ob das anzuzeigende property "Text" vorhanden ist.
Das ist mit der älteren RTTI in dem Umfang nicht möglich.

[Stevie]

Zitat:

Zitat von divBy0 (Beitrag 1118258)

DSharp gefällt mir echt gut und ich experimentiere damit jetzt etwas rum.

Freut mich, bei Fragen, Anregungen oder Bugs, einfach ne pm oder email an mich ;)

Zitat:

Zitat von divBy0 (Beitrag 1118258)

Binding kommt ja erst mit XE2, DSharp von Stevie funktioniert erst ab D2010 so einigermaßen wegen den Generics. Ich hab jetzt noch nicht mit Google gesucht, aber gibt es denn weitere Binding-Komponenten?

Nicht in dem Umfang und mit den Features, die ich implementiert habe, welche Zielsetzung ich verfolge, habe ich in einem meiner ersten Blogposts erläutert. Es gibt einige Mechanismen auch in anderen Komponenten (die data sensitiven Controls, wo man z.B. den Fieldname setzt). Ich kann auch schon in Delphi 7 und früher 2 Objekte verbinden, und sie miteinander kommunizieren lassen, ohne, dass sie sich gegenseitig kennen müssen. Meine Grenzen sind aber nunmal da, wo die Sprachunterstützung aufhört. Der größte Kritikpunkt wurde ja schon genannt, es ist string basiert, da es keinen language/compiler support für property binding gibt. Und die Notifications bei der Änderung einer Property muss auch selber implementiert werden, damit die angeschlossenen Bindings darüber informiert werden und die Gegenseite aktualisieren. Beides Dinge die meiner Meinung nach einfach zu implementieren wären und einen großen Schritt auch für RAD bedeuten würden.

Es gibt einige entscheidende Gründe, warum die derzeitige Lösung ab 2010 funktioniert - ich glaube aber alles davon könnte mit Abstrichen hier und da anders implementiert werden, um es auch in alten Delphi Versionen lauffähig zu machen:

• Multicast Events - die Implementierung, die ich gewählt habe, macht von Generics Gebrauch, so, dass ich aus jedem beliebigen Event typ (z.B. TNotifyEvent) ein Multicast Event machen kann. Würde aber auch ohne gehen, dann müsste man die konkreten Typen halt auscodieren, ähnlich wie man früher typisierte Objektlisten gebaut hat.
• RTTI - Eigenschaften von den einfachsten Objekten sollen bindable sein, geht nur mit der RTTI ab 2010, bei der alten ist man auf published Properties und TPersistent Derivate angewiesen.
• verbesserte Designtime Unterstützung - irgendwann zwischen Delphi 7 und Delphi 2009 wurden einige Erweiterungen für den OI gemacht, indem man selber dort Properties registrieren kann, die aber eigentlich garnicht Teil den Objekts sind - die gebrauche ich, um den dafür registrierten Controls die DataBinding Eigentschaft zu verpassen, sobald eine TBindingGroup auf dem Form oder Frame liegt - darauf müsste man verzichten, aber man kann ja immernoch über die BindingGroup selber Bindings anlegen.

[Phoenix]

Zitat:

Zitat von bernerbaer (Beitrag 1118165)

sorry, wenn ich am Thread vorbei rede. Aber zurück zum Beispiel der Addition. [...] Wiederverwendbarkeit des Codes? Kann ich mit Copy und Paste schneller, bessere Lesbarkeit des Codes?)

Du arbeitest wahrscheinlich nicht an größeren Projekten. Bei einem kleinen Projekt, an dem man alleine arbeitet, mag das pragmatisch und effizient sein. In einem größeren Projekt, wo Teams >= 10 Personen arbeiten ist z.B. gerade das von Dir angesprochene Copy & Paste zwar auch in jedem einzelnen Fall schneller, aber: Der Kunde ruft an und sagt dass an der Ausgabe von Stelle X ein Bug ist. Wahrscheinlich ein Umrechnungsproblem oder falsche verwendete Einheiten. Es fällt auf, dass eine bestimmte Funktion einen Bug hat, der zu einem falschen Ergebnis führt. Mitarbeiter A fixt den Bug und deployed die Applikation neu.

Zeitsprung, Irgendwann ein paar Wochen vorher: Mitarbeiter B hat die Aufgabe, eine Exportfunktion zu schreiben, die die Ausgabe, die an Stelle X gemacht wird, enthält. Das Sind Daten, die ein zulieferer zu Produktion von Teilen benötigt. Er kopiert genau den fehlerhaften Teil, anstelle ihn wiederverwendbar zu machen und zu benutzen (würde länger dauern, ist 'nicht pragmatisch', der Code ist mit der Kopie besser lesbar, und sowieso ist das ja eher RAD und das andere OOP Overkill).

Was genau das Problem ist? Der Fehler ist jetzt immer noch am Programm, denn Mitarbeiter A hat den Fehler an Stelle X und gefixt und, weitsichtig wie er war, sogar noch geschaut von welchen Stellen der Code noch benutzt wird. An einer weiteren Stelle musste die Ausgabe noch um die, jetzt korrekte, Einheit angepasst werden, aber mehr war nicht zu machen. Das der Code von einem anderen Kollegen an Stelle Y kopiert wurde, davon weiss er nichts. Selbst wenn er mit so etwas rechnen müsste und er bei seinen Kollegen fragt, kann sich B nicht mehr daran erinnern, genau den Code verwendet zu haben. Ist ja schon ein paar Wochen her, und die Exportfunktion schon lange vergessen.

Ohne zu wissen, dass der Fehler jetzt an stelle B immer noch im Programm (und damit im Export für den Zulieferer) ist - er sieht das korrekte Ergebnis ja an Stelle A - bestellt der Kunde anhand der Daten einen Großauftrag beim Zulieferer. Die gelieferten Kabelbäume für den A380 sind zu kurz - es gibt einen Millionenschaden. Weil irgendjemand Copy & Paste benutzt hat.

Zitat:

Zitat von bernerbaer (Beitrag 1118165)

Nein, ich gehöre nicht zu den Programmierern die einfach Buttons und Edits auf die Form klatschen! Ich bin ein Programmierer der sich überlegt was er macht und den Aufwand und Ertrag abschätzt. Wo Trennung von GUI und Anwendungslogik sinn macht, setze ich es auch ein. Aber ich bin nicht ein Gläubiger der macht, was die Mehrheit sagt.

Eigentlich sagt es nur eine Minderheit, das die Trennung von Logik und UI Sinnvoll ist. Das Problem ist, dass es leider keine Wirtschaftlichen Auswertungen darüber gibt, wieviel Geld und Zeit es kostet, es vorher ein einziges mal ein wenig aufwendiger zu implementieren und wieviel Geld un Zeit es kostet, hinterher in kopiertem Code, der zudem durch fehlende Trennung / zu starke Bindung schlecht bis gar nicht automatisiert Testbar ist, Bugs überhaupt an allen Stellen zu lokalisieren und zu fixen, ggf. mehrfach, und das alles hinterher wieder manuell durchzutesten.

Ich würde jede Wette eingehen, die Sicherheit und die Zuverlässigkeit, die eine sauber aufgesetzte Applikation bietet (im Sinne von: Fehler fallen durch automatisierte Tests sofort auf, durch saubere Trennung ist alles Testbar, durch saubere Trennung lassen sich neue Features leichter und schneller einbauen, weil sie schon funktionierenden Code absolut nicht beeinflussen können), wiegen den scheinbaren Vorteil den RAD bietet (ein wenig schneller bis zum ersten sichtbaren Ergebnis) um längen auf. Und zwar in nahezu jedem einzelnen Fall.

[bernerbaer]

Zitat:

Zitat von Phoenix (Beitrag 1118271)

Zitat:

Zitat von bernerbaer (Beitrag 1118165)

sorry, wenn ich am Thread vorbei rede. Aber zurück zum Beispiel der Addition. [...] Wiederverwendbarkeit des Codes? Kann ich mit Copy und Paste schneller, bessere Lesbarkeit des Codes?)

Du arbeitest wahrscheinlich nicht an größeren Projekten. Bei einem kleinen Projekt, an dem man alleine arbeitet, mag das pragmatisch und effizient sein. In einem größeren Projekt, wo Teams >= 10 Personen arbeiten ist z.B. gerade das von Dir angesprochene Copy & Paste zwar auch in jedem einzelnen Fall schneller, aber: Der Kunde ruft an und sagt dass an der Ausgabe von Stelle X ein Bug ist. Wahrscheinlich ein Umrechnungsproblem oder falsche verwendete Einheiten. Es fällt auf, dass eine bestimmte Funktion einen Bug hat, der zu einem falschen Ergebnis führt. Mitarbeiter A fixt den Bug und deployed die Applikation neu.

Sorry, da habe ich mich missverständlich ausgedrückt, selbstverständlich mache ich nicht copy und paste innerhalb (m)eines Projektes. Ich habe es folgendermassen gemeint: Ich habe eine Funktionssammlung und kopiere genau einmal die benötigte Funktion in eine Unit (m)eines Projektes.
In meiner über 30 jährigen Laufbahn als Softwareentwickler konnte ich noch _nie_ eine komplette Klasse eines Projektes in einem anderen Projekt wiederverwenden, aber hunderte von Funktionen die ich einfach aus meiner Sammlung kopiere und eine Funktionsunit einfügen kann (oder aber in dll's die von mehreren Programmen wiederverwendet werden können).

Nun jedermann soll vorgehen wie es die Firmenpolitik vorgibt oder der jeweilige Einzelprogrammierer es mag. Solange ich keine masochistischen Gelüste in mir spüre, verwende _ich_ für Projekte mit einer GUI ein RAD-Tool.

Manchmal kommt es mir vor, gewisse Programmierer arbeiten nach Zeilenentschädigung (das habe ich vor über 30 Jahren auch gemacht als freischaffender Journalist für Computerzeitschriften, da habe ich auch des öftern meinen Code aufgeblasen um mehr Geld für die Finanzierung des Studiums zu erhalten - und hunderte haben dann diesen Code mühsam abgetippt ;-).

[Luckie]

Und wenn du feststellst, dass die Funktion in der Sammlung einen Fehler enthält, dann durch suchst du alle deine Projekte um dann in jedem einzelnen den Fehler zu beheben? Wenn du nicht zentral auf diese eine Unit zugreifen willst (Ist immer etwas mühsam, wenn man es OpenSource verteilt, alle benötigten Units für das Archiv zusammenzusuchen.), dann ändere den Fehler in der Unit und kopiere sie in den Projektordner der betroffenen Projekte. Wenn du dann noch Buildscripte verwendest, brauchst du noch nicht mal die IDE zu öffnen. So mache ich das immer.