Nun basht euch auch noch mit SQL

Nein also ich hatte mir schon Gewissenbisse gemacht das ich zu doof bin OOP einzuhalten aber wenn man einen Treeview aufbauen soll ist das mit den Objekten die sich slebst laden natürlich nicht schnell möglich.

Da ich nur Relationale DB benutze ist das auch nicht möglich. Und einen Serialisierer ist auch nicht so ohne weiteres möglich wenn die Eigenschaften aus verschiedenen Tabellen zusammenfließen.


Ich sehe OO nicht als Dogma an, keine Angst. Und ich bin auch immer dabei meinen Code zu verunstalten nur um terminlich fertig zu werden. Dem Kunden ist es sicherlich egal. Aber OO soll mir ja die Arbeit erleichtern also werde ich es mir zu Herzen nehmen.

BenBE hat folgendes geschrieben:

Um Objekt-Orientiert Programmieren zu lernen ist UML mehr als ungeeignet. Ich sehe in der Hinsicht keine Notwendigkeit UML zum "Modellieren" zu verwenden ... Man macht sich eh meist auf'm Papier ne viel übersichtlichere Darstellunge, was in eine Klasse rein muss. Eine der wichtigsten Fähigkeiten bei OOP ist es, zu wissen, was wohin muss; eine Fähigkeit, die mir heutzutage immer weniger begegnet!

Full Ack. Nimm CRC- Cards (= Class; Responsibility; Collaboration)

Naja also das ist doch nur eine Frage der Darstellung. Da finde ich UML Klassendiagramme eigentlich besser.
CLASS-RESPONSIBILITY-COLLABORATION

Außerdem finde ich das Generieren von Quellcodegerüsten durch Case Tools super.

Ja aber das mit dem Wissen was wohin ist so eine Sache, ich finde es eigentlich nicht schlecht, aus dem Pflichtenheft erstmal alle notwendigen Funktionen zu extrahieren und aufzulisten.
Dann baue ich erstmal die Attribute an die Klassen und dann die Funktionen unter Berücksichtigung, mit welchen Objekten sie arbeiten und das sie nicht unnötigerweise bei Klassen landen die sehr häufig instanziert werden...

Aber ich empfinde es trotz OO schwer neue Aspekte in ein angefangenes Modell zu integrieren aber das macht vielleicht die Erfahrung, das man da nicht gleich verzweifelt

Wie ist eigentlich eure Meinung zur Übergabe von Parametern in Konstruktoren?
Dadurch erspaart man sich ja manchmal das zuweisen bestimmter Werte von außen per Property und den Aufruf einer zusätzlichen DoXYZ Methode. Aber es ist doch schon arg unübersichtlich, vor allem wenn man teilweise feststellt, das in einigen Spezialfällen einige Werte garnicht übergeben werden müssen. Dann fängt man wieder an mit Defaults bei den Parametern zu arbeiten bzw. die Methoden zu überladen...

digi_c hat folgendes geschrieben:

Wie ist eigentlich eure Meinung zur Übergabe von Parametern in Konstruktoren? Dadurch erspaart man sich ja manchmal das zuweisen bestimmter Werte von außen per Property und den Aufruf einer zusätzlichen DoXYZ Methode. Aber es ist doch schon arg unübersichtlich, vor allem wenn man teilweise feststellt, das in einigen Spezialfällen einige Werte garnicht übergeben werden müssen. Dann fängt man wieder an mit Defaults bei den Parametern zu arbeiten bzw. die Methoden zu überladen...

Ich halte es normalerweise so, dass ich alle Informationen, die das Objekt zum sinnvollen Funktionieren braucht, als Parameter im Konstruktor übergebe. Da arbeite ich auch relativ häufig mit Default-Werten oder mehreren Konstruktoren - entweder überladen oder einfach mit verschiedenen Namen.

Stefan

Da ja einige sich sicherlich auch für OOP interessieren:
wiki.delphigl.com/in...Softwareentwicklung1

Zu schade, dass es noch keinen 2. Teil gibt, wirklich eines der besten Dokumenente IMHO zum Thema+UML.
Man bräuchte auch mal Beispielunterlagen von einem etwas größeren Projekt...

digi_c hat folgendes geschrieben:

Da ja einige sich sicherlich auch für OOP interessieren: wiki.delphigl.com/in...Softwareentwicklung1 Zu schade, dass es noch keinen 2. Teil gibt, wirklich eines der besten Dokumenente IMHO zum Thema+UML. Man bräuchte auch mal Beispielunterlagen von einem etwas größeren Projekt...

Ja, wirklich mal ein guter und kurzer Einstieg. Ich wollte nur kurz ergänzen:
Die Phasen Einstieg (Inception), Ausarbeitung (Elaboration), Kunstruktion (Construction), Übertragung (Transition) sind nicht mit dem Wasserfallmodell zu verwecheln! Vielmehr ist es so, dass in jeder Phase sogenannte Iterationen durchlaufen werden. Am Ende einer Iteration (nach z.B. 3 Wochen) sollte immer ein Ergebnis vorhanden sein.

Aber nochmal zu den CRC- Karten:
OOA & OOD mit UML ist sozusagen "Programmieren im Großen". CRC- Karten sind nur ein Hilfsmittel um Objektverantwortlichkeiten zu ermitteln. Sie dienen primär dem OO- Verständis und sind daher weniger ein Modellierungstool. Aber gerade das Ermitteln der Verantwortlichkeiten fällt mir zumindest besonders schwer. Was nützt das schönste Klassendiagramm, wenn die Klasse falsch/unpassend ist?

CU

Eine weitere gute Seite, die ich bsiher ausversehend verschwiegen hatte:

www.educeth.ch/informatik/diverses/

Obwohl ich sonst mitz Buchempfehlungen immer vorsichtig bin da die Wissenbasis der Leute meist zu verschieden ist möchte ich euch mal das Buch 3-427-01145-3 "Programmentwicklung mit UML" empfehlen. Wirklich sehr verständlich und praxisnah, habe schon 5 Bücher zu dem Thema gelesen aber das gefällt mir wirklich sehr gut.

Da ich natürlich noch lange nochnicht mit dem Thema durch bin habe ich mir "Patterns konkret" 3-93504246-9 besorgt.
Sehr gut da auf Delphi zugeschnitten aber man sollte OOP Grundlagen(Vererbung,Aggregation,....) schon drinhaben ansonsten verliert man sich. Dafür bekommt man wunderbare Einblicke in die einzelnen Vorgehensmodelle,Tools,Speichermanagement(Klassen,Interfaces,)... .
Ist auch einigermaßen lebhaft geschrieben...wenn auch ein wenig durcheinander, mir fehlt da an einigen Stellen echt der rote Faden bzw. dann wird wieder zu viel vorraus gesetzt.

Hallo,

es gibt jetzt auch den zweiten Teil:

wiki.delphigl.com/in...Softwareentwicklung2

Grüße
Peter

Was lange währt, wird wirklich gut! Beeindruckend

Also so richtig komme ich mit den Patterns nochnicht klar. O.k. das Buch war nicht schlecht aber dann teilweise doch ein wenig unverständlich(TRadeRoboter, es gab wohl nichts abstrakteres ). Ich habe jetzt das Warum und teilweise auch das Wie verstanden(Wrapper,... was man irgendwie schon mal selbst gebaut) nur würde ich behaupten, dass ich trotzdem bei eigenen Projekten aufm Schlauch steh.

Überlege ich mir beim Design bereits wo ich das am besten mit welchem Muster löse? Und schade bei Lightweight und Factory,Adapter,Proxy... seh ich irgendwie nicht so richtig den Sinn, verhüllen, abstrahieren tun sie doch alle aber da fehlt mir echt ein wenig Konkretes.


Und wie mache ich das bei Properties, sammle ich die Informationen während der Laufzeit in einer privaten Variable oder baue ich lieber eine Get Methode, die den Wert ermittelt?

Lese gerade Objektorientierte Softwaretechnik 3827370825. Sehr gut wenn man ein wenig Vorwissen hat. Ein wirklich guter Brückenschalg zwischen dem ganzen Teilwissen das ich schon habe.

Da ich z.Z. jede Menge im RL zu tun habe, komm ich erst mal nach 2 Monaten mal wieder her, sorry!
Habe aber ein weiteres gutes Buch zum Thema gefudnen, wirklich sehr tiefgreifend, was neue Programmiertechniken angeht und SPrachenunabhängig (hat aber leider keine Delphi Beispiele):
Praxisbuch Objektorientierung - Galileo Computing
ist sogar kostenlos zu lesen/downloaden: www.galileocomputing.de/openbook/oo/