Entwickler-Ecke :: Thema anzeigen - OOA,OOD,OOP jetzt mal ersthaft

digi_c - So 29.01.06 17:58
Titel: OOA,OOD,OOP jetzt mal ersthaft

Hallo, wie ihr zweifelsohne gemerkt habt will ich wirklich OOP verstehen und bin gezwungen mir das im Selbststudium beizubringen. Aber irgendwie gehen alle Dokumente die ich dazu lese (für mich) am Thema vobei.
Versteht mich nicht falsch, aber ich weiß schon das OOP Klassen bedeutet und das man diese mit UML Klassendiagrammen darstellen kann ;)
Aber die ganze Verbindung mit den großen Konzepten sind mir nicht wirklich klar. Am besten ich fange erstmal an (damit ihr nicht einschlaaft in Stichpunkten)

-SW dient größtenteils der Optimierung von (Geschäftsprozessen)
-diese werden in der Wirtschaft per Ereignis Prozess Ketten-Diagrammen dargestellt werden
-Analysephase:
--Ist Beschreibung per Text/EPK/Datenfluss
--SOLL Beschreibung per Text
-->Zusammensetzen mit Kunden und verständlichen der Situation(Daten,Aktionen) für Coder per UML Use Case
-Designphase(Bottom Top?):
--Zielkonflikt(Geschwindigkeit,Wartbarkeit,...) Kompromiss Modell View Controller Gliederung(?Observer Patern?)
--Erstellung DatenKlassen und ihrer Abhängigkeiten per UML Klassendiagrammen
--finden/durchdenken von Algorithmen per Struktogramm/PAP
-Implementierungsphase
--GUI erstellen
--Abtippen/Generieren der leeren Klassen (Idealerweise durch CASE Tool automatisiert)
--Umsetzen der Zuweisungsmethoden der Attribute
--Anbindung fertiger Funktionen aus Bibliotheken
--Umsetzen der speziellen Algorithmen in Code
--Datenschnittstellen einbauen

Tja mir ist jetzt bloß total unklar wie da jetzt die Heinzelmänchen im UseCase nützlich sind und überhaupt 13 Diagrammtypen und zig Abstraktionsschichten. Und was ist mit den Patterns? Und ist DB da nicht total inkompatibel/umständlich? Wäre wirklich schön wenn mal jemand der das macht auch alltagstaugliche und überschaubare Beispiele bringen könnte. Vielleicht sogar in Delphi :)

Bitte speißt das jetzt nicht mit schau hier schau da ab, habe ich nämlich eigentlich schon:
http://wwwswt.informatik.uni-rostock.de/deutsch/Infothek/uml/kurs/
http://www.jeckle.de/unified.htm
http://www.oszhdl.be.schule.de/gymnasium/faecher/informatik/oop/index.htm
http://mezmedia.de/oop/
http://www.educeth.ch/informatik/vortraege/xmlintro/index.html
Suche in Wikipedia

UML ,

OBJEKTORIENTIERTE PROGRAMMIERUNG
http://de.wikibooks.org/wiki/Programmieren:_Der_Prozess_der_Softwareentwicklung
http://de.wikibooks.org/wiki/Muster
http://de.wikibooks.org/wiki/Softwaretechnik

Irgendwie fehlen da immer die Brückenschläg und dauernd TSkoda von TAuto abzuleiten macht ja auch keinen Spass ;)

mkinzler - So 29.01.06 18:12

UML zielt auf 2 Dinge: 1. Durchgängigkeit in allen Phasen der Softwareentwicklung und "gemeinsame "Sprache" von SW-Entwickler und Anwender.

USE-Cases dienen i.e.R. festzulegen was das Programm können soll, wie der allg. Datenfluß ist. Die einzelnen usecases finden sich später meistens als Methoden irgend welcher Klassen wieder.

Am besten besorgst du dir mal ein UML-Tool wie z.B. Poseidon [http://gentleware.com/downloadcenter.0.html] und gehst die Tut durch.

Aber um das Konzept von OOP zu verstehen würde ich nicht unbedingt zuerst UML lernen.

F34r0fTh3D4rk - So 29.01.06 18:27

OOP = Objekt Orientiertes Programmieren, sowas:

Delphi-Quelltext

1:	type myimage = class(Timage)

oder auch:

Delphi-Quelltext

1:	type myrecord = record

welche man ganz einfach so verwendet:

Delphi-Quelltext

1:
2:

var
  arecord: myrecord;

digi_c - So 29.01.06 19:37

Ja ebend und um diese "Schlauigkeit" weiterzureichen benutzt man doch Patterns oder? Dort wird doch der Aufbau/Beziehungen von Klassen sowie ihr zeitliches Zusammenspiel beschrieben?

Also mit UML soll ich durchgängig arbeiten können, das ist mir klar aber nicht wie das gehen soll. Ich muss ja den Prozess darstellen, daraus die Informationsflüsse und beteiligte Objekte isolieren und diese als Klasse überführen.

CASE Tools habe ich ja schon reichlich durch. Aber gerade da begegnen einem ja die ganzen Dinge und da will ich wissen, wie ich sie zu meinem Vorteil gebrauchen kann.

Wie ich sagte ich bin ja nicht auf den Kopf gefallen und weiß WAS OOP ist und ich denke auch ganz gut WIE man es benutzt aber ich verstehe das Zusammenspiel der ganzen Techniken die beim Engeniering so benutzt werden nicht...

mkinzler - So 29.01.06 19:45

Ursprünglich hätte UML ja UMM ( Unified Modelling Method) heißen sollen, wurde aber dann zu UML. Also keine Methode sondern nur eine (Notations-)Sprache.
Für solche Automatiken benötigst du dann weiter Tools welche das sogenannte MDA anbieten. Mit reinen UML-Tools muß der Programmierer die Überführung zwischen den einzelnen UML-Diagrammen noch manuell durchführen.
Diese Tools kosten allerdings auch etwas. Es gibt auch OS-Ansätze dafür. Borland's ECO-Framework geht in diese Richtung.

noidic - Mo 30.01.06 09:13

Ich bin auch der Meinung, bevor man sich mit UML auseinandersetzt, sollte man in OOP erstmal absolut sattelfest sein. Denn nur dann bringt man auch gescheite Modelle zustande.

Der wichtigste Punkt bei OOP ist, dass man sich aneignet, in Objekten zu denken. Wenn ich z.B. eine Überwachungssoftware bauen soll, müssen mir Räume, Etagen, Kameras und Personen direkt als Klassen ins Hirn springen, und nicht zuerst die einzelnen Aktionen, die durchgeführt werden. Da sehe ich auch ein Problem vieler Einsteigerbücher, gerade in Delphi, die erstmal damit anfangen, wie ich verschiedene Aktionen abbilde. Wenn das erstmal drin ist, isses schwierig, die Perspektive auf Objekte umzuschwenken. Soweit meine Meinung dazu :)

Was die Patterns angeht, einige lassen sich in Delphi recht gut abbilden ( z.B. Factory, Singleton ) und sind auch sehr hilfreich, andere wiederum sind nur mit grösserem Aufwand und auch dann nur unbefriedigend umzusetzen ( MVC z.B. ). Das liegt mE daran, dass Delphi zu konzipiert wurde, dass Oberfläche, Daten und Programmlogik eng miteinader verknüpft sind ( siehe allein datensensitive Komponenten ).

Um sich intensiv mir OOP zu beschäftigen, kann ich nur Java empfehlen, da kommt man garnicht erst in die Verlegenheit, an Objekten vorbei zu arbeiten :)

Stefan.Buchholtz - Mo 30.01.06 11:29

digi_c hat folgendes geschrieben:

Durch Java bin ich ja auch darauf gekommen da wir ein Jahr damit verbracht haben und mir das auch sehr gut bekommen ist. Aber wie ist den das mit Patterns nun im Detail zu verstehen?

Ein Design Pattern ist allgemein gesagt eine Lösung für ein häufiger vorkommendes Problem.
Ein einfaches Beispiel ist das Singleton-Pattern - das ist wohl das einfachste Design Pattern. Ein Singleton ist eine Klasse, von der immer nur eine Instanz existieren soll. In dem Projekt, an dem ich arbeite, haben wir eine ganze Menge Singletons, z.B. sind die Datenbankverbindung, eine globale Icon-Liste, die Programm-Voreinstellungen und diverse Factories als Singletons implementiert.

Ein Singleton sieht dann zum Beispiel so aus:

Delphi-Quelltext

1:
2:
3:
4:
5:
6:
7:
8:
9:
10:
11:
12:
13:
14:
15:
16:
17:
18:
19:
20:
21:
22:
23:
24:
25:
26:
27:
28:
29:
30:
31:
32:
33:

interface

type
  TSingleton = class
  private
    constructor Create;
  public
    destructor Destroy; override;
   
    class function Shared: TSingleton;
  end;

implementation

var
  GSingleton : TSingleton;

class function TSingleton.Shared: TSingleton;
begin
  if not Assigned(GSingleton) then
  begin
    GSingleton := TSingleton.Create;
  end;
  Result := GSingleton;
end;

...

initialization
  GSingleton := nil;
finalization
  GSingleton.Free;
end.

Der zugriff auf das Singleton erfolgt dann immer über TSingleton.Shared. Der erste Aufruf von Shared erzeugt die Singleton-Instanz, alle weiteren benutzen sie dann. Vorteile:
1. keine globale Variable
2. die Erzeugung geschieht automatisch bei der ersten Benutzung
3. es sit nicht möglich die Klasse versehentlich mehrfach zu erzeugen, weil der Konstruktor private ist.

Stefan

noidic - Mi 01.02.06 14:16

Was du damit beschreibst ist ganz allein dir überlassen. Das Diagramm wird sich nicht beschweren :)

Du kannst ja auch mit einem Klassendiagramm zusammenhänge beschreiben, die so garnix mit Klassen im Softwaresinne zu tun haben. Die verschiedenen Diagrammtypen wurden zwar für bestimmte Anforderungen entwickelt, das heisst aber nicht, dass sie nich auch für andere Anforderungen benutzt werden können.

Ich benutze z.B. eigentlic immer zur Modellierung von Algorithmen Aktivitätsdiagramme, da ich sie leichter lesbar finde als Struktogramme.

BenBE - Mi 01.02.06 18:56

Häh, so'n PAP für ASM tät'sch gern mal sehen wollen *g*

Naja, ich entwickel meine Softwareklassen auch nach der Ausfertigung eines Datenfluss-Diagramms, dass als stupides Organigramm vorliegt ... Wer sich beim Programmieren an das hält, was ihm beigebracht wurde, kann nicht weiter kommen, wie er es gelernt hat. Ich könnt nach einem Seminar "Einführung in die Informatik" immer wieder ganze Flugzeug-Hangars überfallen, um meinen Vorrat an Kotzbeuteln aufzustocken.

Software-Modellierung ist was von Leuten, die nicht programmieren können für Leute, die es nie können werden.

digi_c - Mi 01.02.06 20:52

Naja also erst denken und dann coden ist ja nun schonmal net verkehrt aber wenn man x tausend Möglichkeiten hat das dazustellen *aua*
Zumal ich gemerkt habe das die meisten Probleme durch Mißverständnisse("wie ich soll das Objekt kreiieren, ich dachte du machst das..."), mangelnden Datenaustausch("ich hab ne neue Komponente, ich maile sie euch mal", Wochen später: " wie du hast noch Komponente 1.2?") und mangelnde Absprache/Abstraktion("nö genau die selbe habe ich gestern erst geschrieben") zustande kommen.

F34r0fTh3D4rk - Mi 01.02.06 21:14

BenBE hat folgendes geschrieben:

Du sagst es ;)
Na ich mein, ein wenig Struktur schadet wohl keinem, ohne Struktur gehts net, aber wenn man für 5 Zeilen Code, vorher 5 Stunden Diagramme gemalt hat ist das einfach zu viel. (Denke im Studium wird das nochmal dicke auf mich zukommen *schauder*)

noidic - Do 02.02.06 09:07

Man kann die Modellierung auch übertreiben, das stimmt wohl. Aber die Aussage vom BenBE kann ich nicht nachvollziehen...

Ich halte mich eigentlich für einen veritablen Programmierer, trotzdem greife ich gerne auf Klassen- und Aktivitätsdiagramme zurück. Zum einen, um mir einen Überblick zu verschaffen, was an welcher Stelle wann zu tun ist, zum anderen, um mit anderen aus dem Team die Überlegungen diskutieren zu können, ohne das man sich auf, im Vergleich zu einem Modell unübersichtlichen, Code stürzen müsste.

Alpha_Wolf - Do 02.02.06 09:28

Bin deiner Meinung noidic.

Übertreiben kann man auch alles.. Aber auch ich setz mich gern mal mit nem Klassendiagramm hin und besprech das mit Kollegen, aber auch Reverse Engineering also sprich existierende Projekte wieder in UML darstellen ist sehr hilfreich.. Das Teil ausdrucken und es an die Wand hängen.. Eine sehr gute Übersicht.

Bei Kundenterminen können Use Case Diagramme sehr nützlich sein.. Es gibt Kunden die wissen selbst nich im Detail wie ihre Prozesse aussehen.. und n Blatt Papier und n Stift hat man immer dabei. Man zeichnet das grob auf fährt zurück ins Büro, bearbeitet es nach uns schickts mit der Nachbereitung dem Kunden (und legt es noch nebenbei in der Projektdefinition ab..) So hat man immer den Prozess leicht verständlich vor sich.. und der Kunde versteht es auch.

Software soll ja nicht nur ne Ansammlung von Funktionen sein sondern den Prozess verbessern..

noidic - Do 02.02.06 11:25

digi_c hat folgendes geschrieben:

Sind eigentlich diese Datenfluß-Diagramme wirklich aktuell oder sind die von UML abgelöst?

Was meinst du mit abgelöst? Es geht hier nicht um Software-Versionen, Gesetze oder irgendwas anderes, was einer ständigen Evolution unterworfen ist. Welche Art von Diagramm man verwendet ist Vereinbarungssache zwischen den Personen, die darüber mitaneinder arbeiten müssen. DIe UML hat nichts abgelöst, sondern nur eine neue Möglichkeit zur Modellierung geschaffen. Wer sie nicht nutzen will, muss es nicht tun und braucht dabei keine Sorge zu haben, das deswegen seine Software nicht funktioniert oder seine Kollegen ihn nicht mehr verstehen :)

Jeder sollte so modellieren, wie er es am besten kann, zumindest für sich selbst. Für die Kommunikation mit Kunden oder Kollegen kann es natürlich Vorgaben geben, an die sollte man sich dann halten.

noidic - Do 02.02.06 13:32

Also ich erstell mit bei grösseren Sachen zuerst mal eine Zusammenstellung der benötigten Tabellen in der Datenbank. Wenn neue Tabellen angelegt werden müssen, bastel ich mir ein kleines ERD dazu.

Als nächstes kommt ein Klassendiagramm mit den nötigen Klassen. Meistens macht das einige Änderungen durch, bis es endgültig fertig ist ( So man bei Software von endgültig fertig reden kann... ).

Dann setze ich die Klassen um ( Wenn ich das Diagramm mit dem Modelmaker gebaut hab, ists weniger Arbeit ). Dabei sind meist auch noch Änderungen am Modell nötig.

Als letztes mache ich mir Gedanken über die Abläufe. Bei komplizierteren Abläufen erstelle ich mir dazu ein Aktivitätsdiagramm.

Manchmal, aber eher selten kommt dann für den Test noch ein Use Case - Diagramm zum Einsatz, bei einigen Backend-Geschichten, die ich baue, ist auch mal ein Einsatzdiagramm für den Kunden drin.

Wobei ich jetzt dazu sagen muss, dass die ganzen Diagramme meistens auf den Rückseiten von irgendwelchen Konzeptausdrucken hingeschmiert werden :)

digi_c - Sa 11.02.06 12:55

Ich muss nochmal nachhaken und zwar wegen den Properties, wie ist den da der Zusammenhang zu OOP?

Also ich kann ja entweder eine Variable normal als Variable:Typ veröffentlichen oder eine Protectecte fVariable:Typ deklarieren und eine Property deklarieren die entweder direkt darauf zugreift oder über Get/Set Methoden um Sicherheit zu gewährleisten. Laut OOP soll man ja keine Variablen direkt "veräußern" sondern immer schön schützen...

Gibt es so ein Properties Konzept auch direkt in OOP? In Java musste man IMHO immer selbst als Get/Set Methode veröffentlichen und konnte die nicht als Property bündeln.

tm77 - Mo 13.02.06 22:55

digi_c hat folgendes geschrieben:

Hallo,
Getter/Setter sind nicht wirklich objektorientiert. Mal abgesehen davon, dass man beim Setzen oder Lesen irgendwie reagieren kann, oder dass man Accessoren in Schnittstellendefinitionen aufnehmen kann, besteht im Prinzip kein Unterschied zu öffentlichen Feldern. Ein interessanter Artikel dazu findet sich in der Javaworld http://www.javaworld.com/javaworld/jw-09-2003/jw-0905-toolbox.html .

Zitat:

Laut OOP soll man ja keine Variablen direkt "veräußern" sondern immer schön schützen...

Halte ich für ein Dogma.
cu

Allesquarks - Di 14.02.06 00:26

eine Variable erstmal schön private zu machen um sie dann als Property oder auch nicht über zwei public methoden auszulesen und zu schreiben grenzt für mich an Wahnsinn, und erinnert mich an manche Gesundheitsrichtlinien mit dem Unterschied, dass ein Computer deterministisch arbeitet. Traurigerweise wird einem dies in vielen deutschen Bildungsanstalten eingetrichtert, wahrscheinlich damit man gar keinen Grips mehr im Hirn braucht um zu programmieren, weil aufgrund der Regeln das Programm schon fehlerfrei geschrieben ist. Deshalb meine These: Wer zuviel mit diesen Hilfsdiagrammen rummacht verliert den Blick fürs wesentliche.
Deshalb auch meine Meinung zu Java: Auf keinen Fall eine gute Objektorientierte Sprache, weil die im Sinne der Objektorientierung sich so einen abgebrochen haben, dass man damit nicht gut programmieren kann.

tm77 - Di 14.02.06 00:50

Allesquarks hat folgendes geschrieben:

:-)

Zitat:

Deshalb auch meine Meinung zu Java: Auf keinen Fall eine gute Objektorientierte Sprache, weil die im Sinne der Objektorientierung sich so einen abgebrochen haben, dass man damit nicht gut programmieren kann.

Das trifft genau genommen auf alle c++ - "Derivate" zu. Delphi ist auch nicht besser. Aber woran dachtest du? Smalltalk, Eiffel?
Grundsätzlich würde ich aber behaupten, dass es sich aber auch mit Java "sauber" programmieren lässt.

P.S.: Was haltet ihr eigentlich von einer extra Ecke zu diesen Themen?:
http://www.delphi-forum.de/viewtopic.php?sid=3384514abe9ed89a700f7ea73e0ca0d9&t=55888&highlight=

Gute Nacht
Thomas

Allesquarks - Di 14.02.06 01:07

Ein bischen zu Sauber. Bin da wohl zu sehr matheorientiert. Da behaupten viele nen Beweis muss auch kurz sein um schön zu sein.
Und wenn man bedenkt wie stolz die Javaner doch darauf sind, dass in Java doch alles so abgesichert ist der Programmierer also vor sich selbst geschützt ist, um ihn vor dem bösen c/C++ Stil zu bewahren, wundert es mich, dass sie die Groß/Kleinschreibung nicht abgeschafft haben. Neulich hat bei mir doch glatt nen Java-Compiler rumgemeckert, weil ich kein default im switch hatte.
Ich gebe zu in Eclipse wars dann glaube ich anders, aber es ist die Grundtendenz demjenigen der am meisten Ahnung vom Code hat nämlich dem Entwickler, bestimmte Dinge zu verbieten die es nervig macht. Nebenbei zeugt es auch von einer Arroganz, die ich nicht kommentieren möchte.
Und nach meiner bisherigen Erfahrung ist dies eben gerade in Delphi nicht so.

tm77 - Di 14.02.06 02:04

Also eigentlich ging es mir jetzt nicht um irgendwelche konkreten Programmiersprachen...
Außerdem habe ich mit Java noch nicht viel gemacht. Ich komme eher aus der c/c++ - Ecke. Bin aber zu c# gewechselt.

Allesquarks hat folgendes geschrieben:

Neulich hat bei mir doch glatt nen Java-Compiler rumgemeckert, weil ich kein default im switch hatte.

Was Ähnliches hat mich an c# auch anfangs geärgert. Mann kann nicht mehr von case zu case "durchrutschen".

Zitat:

... der am meisten Ahnung vom Code hat nämlich dem Entwickler, bestimmte Dinge zu verbieten die es nervig macht. Nebenbei zeugt es auch von einer Arroganz, die ich nicht kommentieren möchte.

Mach doch. Hier im Forum war sicher keiner an der Entwicklung von JAVA beteiligt ;-)
Du musst dann auch Dinge wie Garbage-Collection, Typprüfung, Frameworks etc. als Anmaßend empfinden, oder? Ich bewundere Leute, die über ein gesamtes Programm den Überblick behalten können. Wirklich. Ich fand’ schon damals krass, wie gut ein Freund von mir Assembler coden konnte. Ich kann so was nicht.

Zitat:

Und nach meiner bisherigen Erfahrung ist dies eben gerade in Delphi nicht so.

Bei c++ usw. auch nicht. In beiden PS kannst du sowohl prozedural als auch objektorientiert programmieren. (Nebenbei bemerkt ist die massenhafte Verwendung von Gettern/Settern zumindest ein Indiz für prozedurales Denken.) Klar ist es irgendwie albern, z.b. eine statische Klasse für ein paar Konstanten zu definieren. Mal schnell eine globale Konstante in irgendeiner Datei abgelegt geht einfach schneller. Aus objektorientierter Sicht ist beides nicht so schön. Aber wenn es funktioniert und alle zufrieden sind: Was soll’s?

tm77 - Di 14.02.06 13:53
Titel: Re: OOA,OOD,OOP jetzt mal ersthaft

digi_c hat folgendes geschrieben:

-SW dient größtenteils der Optimierung von (Geschäftsprozessen)
-diese werden in der Wirtschaft per Ereignis Prozess Ketten-Diagrammen dargestellt werden
-Analysephase:
--Ist Beschreibung per Text/EPK/Datenfluss
--SOLL Beschreibung per Text
-->Zusammensetzen mit Kunden und verständlichen der Situation(Daten,Aktionen) für Coder per UML Use Case
-Designphase(Bottom Top?):
--Zielkonflikt(Geschwindigkeit,Wartbarkeit,...) Kompromiss Modell View Controller Gliederung(?Observer Patern?)
--Erstellung DatenKlassen und ihrer Abhängigkeiten per UML Klassendiagrammen
--finden/durchdenken von Algorithmen per Struktogramm/PAP
-Implementierungsphase
--GUI erstellen
--Abtippen/Generieren der leeren Klassen (Idealerweise durch CASE Tool automatisiert)
--Umsetzen der Zuweisungsmethoden der Attribute
--Anbindung fertiger Funktionen aus Bibliotheken
--Umsetzen der speziellen Algorithmen in Code
--Datenschnittstellen einbauen

Du beschreibst im Wesentlichen einen Wasserfallprozess. Zuerst das, dann das usw. Mit OO- Techniken soll zunächst einmal erreicht werden, dass du auf Anforderungsänderungen schnell reagieren kannst. Die Kapselung soll dazu beitragen, Änderungen möglichst an einem Punkt vornehmen zu können. D.h., du schließt die Analysephase z.B. nicht ab, sondern erweiterst die Anforderungen in Abständen, die dir letztlich der Kunde diktiert. So wächst die Software allmählich. A. D. und I. werden nacheinander mehrfach in sogenannten Inkrementen durchlaufen. Softwareprozesse würden mich an deiner Stelle erstmal gar nicht so sehr interessieren.
Erwarte bitte nicht, dass man in einem Forum OO lernen kann. Konkrete Fragen sind was anderes. Ansonsten kann ich dir nur ein Buch empfehlen:
Craig Larmann (Applying UML And Patterns)
Er beschreibt zwar auch den Entwicklungsprozess, zeigt aber vor allem auch, wie man OO entwickelt. Er geht auf Dinge ein wie:
- Verantwortlichkeiten zuweisen (welche Klasse ist für was verantwortlich?)
- Kohäsion
- Kupplung
- Polymorphie

usw. ein.

Stefan.Buchholtz - Di 14.02.06 13:55

tm77 hat folgendes geschrieben:

Zitat:

Laut OOP soll man ja keine Variablen direkt "veräußern" sondern immer schön schützen...

Halte ich für ein Dogma.
cu

Ich halte das ganz und gar nicht für ein Dogma. Ein wesentliches Ziel der OOP ist die Kapselung von Daten und Code in möglichst wiederverwendbare Teile und das Verstecken der Implementation eines Programmteils vor anderen Programmteilen. Mit public-Variablen hebelt man das aus, was dazu führt, dass wenn scih die Implementation einer Klasse ändert, wahrscheinlich auch andere Programmteile angepasst werden müssen. Mit einem sauberen Design will man ja genau das vermeiden.

Da finde ich das Property-Konzept von Delphi ziemlich gut: ich kann damit Felder öffentlich machen und damit ohne den Overhead eines Funktionsaufrufs darauf zugreifen. Wenn sich die Implementation der Klasse ändert und das ursprüngliche Feld ist gar kein Feld mehr oder das Objekt muss auf einen Feldzugriff irgendwie reagieren, kann ich stattdessen ohne Änderung des Interface Get- Und Set-Prozeduren verwenden. Damit kann ich die Effizienz einer public-Variablen haben und die Implementation der Klasse trotzdem sauber kapseln. Mit der Delphi-Codevervollständigung braucht ich damit nicht mal wesentlich mehr zu schreiben als wenn ich direkt eine public-Variable verwenden würde.
Delphi-Properties sind eins der Features, die ich bei Java schon vermisse.

Stefan

tm77 - Di 14.02.06 14:29

digi_c hat folgendes geschrieben:

Was sagt mir das jetzt zu Properties in Delphi :?

Also erstmal deklarier ich das meiste private und sortier es dann nach public aus und nur dort wo es mir sinvoll erscheitn mach ich ein Property mit Get/Set ansosnten wird direkt auf die lokale Variable per Property zugegrifen

Eigenlich hat es einen Klienten nicht zu interessieren, welche Attribute ein Objekt besitzt. Das grundsätzliche Problem dabei ist nämlich, dass du Implementierungsdetails der Klasse preisgibst und damit Klassen eng aneinander bindest. Angenommen du hast in einer Klasse einen Preis als Fließkommazahl. Klienten sollen den Preis erfragen können. Du hast jetzt ein privates Feld Preis auf das Klienten über einen Getter zugreifen können. An x Stellen deines Progs. benutzt du nun diesen Getter (der natürlich auch vom Typ Fließkommazahl ist). Im UI konvertierst du diese Zahl, um z.B. nur 2 Nachkommastellen anzuzeigen. Andere Klienten machen keine Konvertierung um genaue Werte zu bekommen etc. Was, wenn du dich später entschließt, verschiedene Währungen einzubauen? Der Preis stellt jetzt mehr ein Konzept dar (also ist Kandidat für eine eigene Klasse). An x Stellen musst du nun ändern.
In der Regel (Außnahmen gibt es ja immer) solltest du Getter/Setter vermeiden, bzw. vorsichtig sein. Desto tiefer du in die Materie eindringst, desto weniger wirst du sie brauchen. Zu diesem Thema sei nochmal auf den Artikel : "Why getter and setter methods are evil" in der javaworld verwiesen. http://www.javaworld.com/javaworld/jw-09-2003/jw-0905-toolbox.html
Dabei spielt die Programmiersprache keine Rolle.

Thomas

tm77 - Di 14.02.06 14:41

Stefan.Buchholtz hat folgendes geschrieben:

Hallo Stefan,

Ja klar. Eine variable einfach öffentlich zu machen ist natürlich ganz schön an der Sache vorbei. Stimme ich dir voll zu. Mir geht es nur darum, dass es konzeptionell keinen großen Unterschied zwischen einer Variablen und einem Property gibt. Wenn man auf ein Attribut eines Objektes zugreifen MUSS, dann natürlich über ein Property. Ich finde das auch bei Delphi gut gelöst.

Thomas

digi_c - Di 14.02.06 15:35

@tm77 ich danke dir für den Buchtip aber mir mangelt es erstmal nicht an Büchern zu dem Thema sondern an zeit :-)

Es ist erstaunlich bei welch kleinen Dingen man Orientierung sucht, in der Schule sah das mit dem "Obst Äpfel Birnen" Beispiel vor 2Jahren so einfach aus ;) Es ist aber echt komisch, nach dem 3. Versuch hatte ich mein damaliges Beispiel "Lizenzverwaltung" was ja eigentlich ganz einfach war(Kunde,Lizenz,Progdukte,Komponenten) doch reichlich anders gebaut.

Ich finde es schwer OO mit DB zu kombinieren. Wie soll man das da machen? On Demand und ein Objekt erzeugen das mit Daten aus dem Dataset füttern?
Ich hatte das in meinem Beispiel durch eine 3 Teilung gelöst(Primitivlinge,Kollektoren,DBVerbinder) ob das gut ist weiß ich nicht aber was großartiges Anderes wüßte ich nicht...

noidic - Di 14.02.06 15:54

Bei der Verbindung von OOP und DB kann sehr schnell die Performance mitspielen. Die Idee, Objekte ihre Daten selbst aus der DB holen zu lassen ist schön sauber. Wenn allerdings die Datenselektion aufwändig ist und zudem noch oftmals Objekte diesen Typs erzeugt werden, wird es schnell sehr träge. Da muss man dann drüber nachdenken, die Objekte von außen zu füttern, am besten über eine eigene Datenzugriffsschicht.

Es gibt kein Patentdesign für OOP-DB-Anwendungen und meistens ziehen sich auch 2 oder mehr Herangehensweisen durch ein Projekt.

tm77 - Di 14.02.06 15:57

digi_c hat folgendes geschrieben:

Es ist erstaunlich bei welch kleinen Dingen man Orientierung sucht, in der Schule sah das mit dem "Obst Äpfel Birnen" Beispiel vor 2Jahren so einfach aus ;) Es ist aber echt komisch, nach dem 3. Versuch hatte ich mein damaliges Beispiel "Lizenzverwaltung" was ja eigentlich ganz einfach war(Kunde,Lizenz,Progdukte,Komponenten) doch reichlich anders gebaut.

Versteh mich bitte nicht falsch. OO sollte kein Dogma sein. Das Wesentliche ist, dass man fertig wird und dem Kunden ein Produkt präsentiert, das läuft. Punkt. Wenn man aber in Richtung OO gehen will, sollte man versuchen von Projekt zu Projekt besser zu werden.

Zitat:

Ich finde es schwer OO mit DB zu kombinieren. Wie soll man das da machen? On Demand und ein Objekt erzeugen das mit Daten aus dem Dataset füttern?
Ich hatte das in meinem Beispiel durch eine 3 Teilung gelöst(Primitivlinge,Kollektoren,DBVerbinder) ob das gut ist weiß ich nicht aber was großartiges Anderes wüßte ich nicht...

Du meinst sicher die Anbindung an eine relationale Datenbank. Da haben sich schon eine Menge Menschen Gedanken zu gemacht. Ist wirklich ein riesiges Problem (Impedance Mismatch: http://en.wikipedia.org/wiki/Object-Relational_impedance_mismatch).

Das einfachste ist es eine objektorientierte DB zu verwenden. Nur wird das nicht immer möglich sein.

Die zweite Möglichkeit ist ein objektrelationnaler Mapper. Ich weiß nicht, was es da für Delphi so gibt.

Dein Vorschlag mit dem Dataset ist nicht der schlechteste. Fakt ist, dass relationale Datenbanken nicht kompatibel zu OO sind. Am "Rand" deines Programmes musst du also dein Design "verschmutzen". Ein Dataset ist deswegen okay, weil es Teil des Frameworks und damit relativ stabil ist. Für kleinere Projekte wäre es sicher die einfachste und somit beste Lösung. Denkbar wäre es, eine persistenten Basisklasseklasse zu haben die ein Dataset aufnehmen kann. Eine Art Memento (GOF- Pattern).
Das ist jetzt aber ein sehr weites Feld und ich muss wieder auf Literatur verweisen. Aber wer zwingt dich denn sofort den elegantesten OO- Code zu schreiben. Fertig machen, Lesen, verbessern, nächstes Projekt, Lesen, usw.

Thomas

tm77 - Di 14.02.06 16:22

noidic hat folgendes geschrieben:

Die Idee, Objekte ihre Daten selbst aus der DB holen zu lassen ist schön sauber.

Jein. Solange du nur gegen ein bestimmtes DBMS programmierst, ist was dran. Ist aber eben leider nicht so, dass SQL = "Standard Query Language" sondern mehr "Structured English Query Language". Mit anderen Worten: Jeder DBMS- Hersteller kocht sein eigenes Süppchen.
Aus OO- Sicht lässt sich auch dagegenhalten, dass diese Klassen zu viel Verantwortung bekommen.
Es hängt aber immer vom restlichen Design, den Anforderungen und der Umgebung ab. Daher ist keine generelle Aussage möglich.

digi_c - Di 14.02.06 17:06

Nun basht euch auch noch mit SQL :lol:

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. :wink:

tm77 - Mi 15.02.06 01:15

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)

digi_c - Mi 15.02.06 09:38

Naja also das ist doch nur eine Frage der Darstellung. Da finde ich UML Klassendiagramme eigentlich besser.
Suche in Wikipedia

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...

Stefan.Buchholtz - Mi 15.02.06 10:47

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

tm77 - So 05.03.06 22:48

digi_c hat folgendes geschrieben:

Da ja einige sich sicherlich auch für OOP interessieren:
http://wiki.delphigl.com/index.php/Tutorial_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

digi_c - Mo 15.05.06 09:13

Da ich natürlich noch lange nochnicht mit dem Thema durch bin habe ich mir "Patterns konkret" 3-93504246-9 [http://www.amazon.de/exec/obidos/ASIN/3935042469/qid%3D1147676736/302-6963083-2424843] 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.

digi_c - Mi 24.05.06 10:12

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 :roll: ). 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?

Entwickler-Ecke.de based on phpBB
Copyright 2002 - 2011 by Tino Teuber, Copyright 2011 - 2025 by Christian Stelzmann Alle Rechte vorbehalten.
Alle Beiträge stammen von dritten Personen und dürfen geltendes Recht nicht verletzen.
Entwickler-Ecke und die zugehörigen Webseiten distanzieren sich ausdrücklich von Fremdinhalten jeglicher Art!