-
Forum: Algorithmen, Datenstrukturen und Klassendesign
Delphi
by stahli,
15. Mär 2012
Hi, kannst Du eine grundsätzliche Meinung äußern nach 4 Wochen herumspielen? :mrgreen:
Insbesondere würde mich auch (wie unter #74 schon angedeutet) interessieren, wie die Möglichkeit der Arbeit mit Schnittstellen gegeben ist (bzw. wer die Objekte wie verwaltet) und wie man ggf. eine Datenbindung an die GUI realisieren kann (unter XE).
-
Forum: Algorithmen, Datenstrukturen und Klassendesign
Delphi
by stahli,
16. Feb 2012
Darf man sich als Threadersteller wünschen, dass man wieder auf die sach(dien)liche Ebene zurück kommt? Ich finde das alles sehr verwirrend - kann am Alter liegen. ;-)
-
Forum: Algorithmen, Datenstrukturen und Klassendesign
Delphi
by stahli,
16. Feb 2012
Das wäre wohl auch was für Euch: www.dialektik.de :stupid:
-
Forum: Algorithmen, Datenstrukturen und Klassendesign
Delphi
by stahli,
15. Feb 2012
Ich meinte mit "umfangreich" nicht unbedingt "besonders kompliziert" sondern eher "viele Möglichkeiten". Auch gerade wegen der Linq-Syntax.
Vorhin habe ich nochmal schnell die Dokumentationen zum Aurelius und DataModeller durchgeblättert. Das scheint schon sehr leistungsfähig zu sein, ist aber zwangsläufig auch recht DB-lastig.
Ich meine, man muss sich auch mit den DB detailliert...
-
Forum: Algorithmen, Datenstrukturen und Klassendesign
Delphi
by stahli,
15. Feb 2012
Da hoffe ich auf weniger Verwirrung und dann SOWAS! ;-)
Aber danke für die Info. Das sieht auf den ersten Blick sehr umfangreich aus. Werde ich mir mal die Tage anschauen...
(Der Kauf wäre notfalls machbar.)
-
Forum: Algorithmen, Datenstrukturen und Klassendesign
Delphi
by stahli,
15. Feb 2012
Mein aktueller Meinungsstand:
Künftige Verwendung von Interfaces: UNBEDINGT!
Ebenso das Verbergen der Klassen-Units untereinander (im Regelfall).
Im Projekt sollen dann grundsätzlich nur die Schnittstellen bekannt sein.
Auf eine Verschachtelung von Objekten über deren Owner werde ich verzichten. Beziehungen untereinander werden über eine Property abgebildet, die die ID des referenzierten...
-
Forum: Algorithmen, Datenstrukturen und Klassendesign
Delphi
by stahli,
14. Feb 2012
@neo4a (mit etwas Verspätung wegen zeitw. Netzausfall)
Sie sieht eben doch in jedem Fall in dem Tank nach.
Allerdings eben über eine gewissermaßen annonyme Funktion. Sie weiß nicht, dass sie im Tank nachsieht, macht es aber eben doch.
Wenn TObject bereits eine Property "Kraftstoff" hätte, deren Getter nach belieben überschrieben werden könnte, würde Eure Argumentation eigentlich schon...
-
Forum: Algorithmen, Datenstrukturen und Klassendesign
Delphi
by stahli,
14. Feb 2012
Sehe ich auch so. Eine strikte und klare Trennung macht oft sehr viel Sinn, ist aber manchmal auch unnötig.
Z.B. würde man die Panel.Font-Eigenschaften nicht direkt im Panel veröffentlichen. Wozu auch? Man kann zwar argumentieren, dass das logischer wäre, aber es wäre ein Aufwand, der letzlich keinen wirklichen Nutzen bringt.
Außerdem müsste man dann konsequenter Weise auch die...
-
Forum: Algorithmen, Datenstrukturen und Klassendesign
Delphi
by stahli,
13. Feb 2012
Darf ich da nochmal nachhaken?
einkaufsabteilung.bestelle(fuhrpark.ermittleBedarf());
"Bestelle" tut irgend etwas mit den Einträgen einer Liste, die "ErmittleBedarf" bereit stellt (5 Liter Diesel, 2 kg Hafer).
So weit richtig?
Sofern es ein Ökoauto als Ableitung von Auto gäbe (EDIT: "welches mit Hafer fährt"), könnte ich das mit Objekten genau so regeln.
Der Vorteil von Interfaces...
-
Forum: Algorithmen, Datenstrukturen und Klassendesign
Delphi
by stahli,
13. Feb 2012
Singelton bezieht sich aber (sicherlich) auf das globale Projekt. Du würdest also in jedes Auto exakt den selben einen Motor einbauen - was natürlich physisch nicht möglich ist. Man muss also jeweils eine Motorinstanz erzeugen und dessen Interface dann weiter verwenden. Die Frage ist dann für mich, wer Owner des erzeugten Objektes (dessen verwendete Schnittstelle verwendet wird) ist.
Im Auto...
-
Forum: Algorithmen, Datenstrukturen und Klassendesign
Delphi
by stahli,
13. Feb 2012
Hallo Andreas, vielen Dank nochmal!
Also das mit den Interfaces ist beschlossene Sache! :-)
Das werde ich auf jeden Fall angehen und mein Projekt in absehbarer Zeit überarbeiten. Man verbirgt dadurch natürlich wunderbar das ganze interne Klassen-Geraffel und kann sich bei der Verwendung schön auf die "veröffentlichten Schnittstellen" beschränken.
Auch ist es egal, um was für Objekte es sich...
-
Forum: Algorithmen, Datenstrukturen und Klassendesign
Delphi
by stahli,
10. Feb 2012
Die "Objekte" sind von TComponent abgeleitet (damit sie einen Owner haben und ich sie ggf. auch in der IDE einrichten kann) und enthalten Daten und BL.
Will ich in einem Spiel ermitteln, ob es sich in einem Turnier befindet, nutze ich eine lokale Variable und eine externe (in einer gesonderten Unit abgelegten) Funktion.
function OwnerTournament(C: TComponent): TodTournament;
begin
...
-
Forum: Algorithmen, Datenstrukturen und Klassendesign
Delphi
by stahli,
10. Feb 2012
Mal noch eine andere Frage, die aber auch in den Bereich mit hineinspielt:
Im Moment erzeuge ich diverse Objekte, die ineinander verschachtelt sind.
Eine Turnierveranstaltung enthält Turniere, die wieder Spiele enthalten, die wieder Spielparteien und zu spielende Sätze enthalten usw.
Über eine Iteration über Spiel.Owner..Owner..Owner kann ich ermitteln, zu welchem Turnier ein bestimmtes...
-
Forum: Algorithmen, Datenstrukturen und Klassendesign
Delphi
by stahli,
10. Feb 2012
Hi neo,
danke für den aufführlichen Beitrag. Das klingt an den meisten Stellen auch sehr plausibel und den Weg werde ich weiter andenken.
Allerdings sehe ich das wie Stefan, dass man GUI und BL getrennt betrachten sollte.
Die BL mit DI und Interfaces aufzubauen ist mit Sicherheit eine gute Sache und trägt zur Übersichtleichkeit bei der Projektwartung bei.
Die GUI würde ich aber (fast)...
-
Forum: Algorithmen, Datenstrukturen und Klassendesign
Delphi
by stahli,
9. Feb 2012
Ach das geht schon erst mal. Um die Weide ist ein kleiner Graben und wenn die Melkanlage erst mal auf vollen Touren läuft, dann schaue ich mir an, wie man am besten stabile Zäune baut :-)
-
Forum: Algorithmen, Datenstrukturen und Klassendesign
Delphi
by stahli,
9. Feb 2012
Ok, in Bezug auf die Teamarbeit ist das gewissermaßen schon nachvollziehbar. Damit habe ich aber (leider oder zum Glück?) keine Erfahrungen.
Die Testfälle zu organisieren ist aber sicher auch nicht trivial und kostet viel Zeit und Arbeit.
Da ich immer im eigenen Saft schmore und mit meinem eiegntlichen Projekt voran kommen will, habe ich leider wenig Zeit mich mit für mich neuen Grundlagen zu...
-
Forum: Algorithmen, Datenstrukturen und Klassendesign
Delphi
by stahli,
9. Feb 2012
Es ging mir um Fehler, die bei der Weiterentwicklung meiner datensensitiven Komponenten und meines Frameworks aufgetreten sind. Entweder haben die VCL-Controls (von denen ich ableite) teilweise nicht wie erwartet funktioniert oder ich habe den Ablauf meines Frameworks an irgendeiner Stelle problematisch verändert.
Diese Probleme hätte wohl kein Unit-Testing entdeckt - denke ich. Und Probleme,...
-
Forum: Algorithmen, Datenstrukturen und Klassendesign
Delphi
by stahli,
8. Feb 2012
Ok danke erst mal.
Mit dem Thema Testing tue ich mich etwas schwer. Ich habe mal zwei deutsche Seiten dazu gefunden:
http://sageniuz.wordpress.com/2010/04/29/testbarer-code-%E2%80%93-konstruktoren-teil-1/
http://msdn.microsoft.com/de-de/magazine/dd263069.aspx
Ich denke, dass solche Tests nur sehr begrenzten Sinn machen. Jedenfalls sind die Probleme, die mir so unterkommen meist sehr...
-
Forum: Algorithmen, Datenstrukturen und Klassendesign
Delphi
by stahli,
2. Feb 2012
Ich habe keine Erfahrung mit Interfaces, könnte mir aber inzwischen vorstellen, im nächsten Projekt mit solchen zu arbeiten.
Der Mehraufwand beim definieren der genutzen Klassen (durch zusätzliche Deklaration von Interfaces) und beim Erzeugen der Objekte (durch Zuweisung des Objektes an eine Interfacevariable) lässt sich durch eine bessere Strukturierung des Projektes rechtfertigen.
Wenn...