Discussion:
Hat OOP Vorteile gegenueber prozeduraler oder modularer Programmierung?
(zu alt für eine Antwort)
Stefan Ram
2007-12-06 05:02:49 UTC
Permalink
Newsgroups: de.comp.objekt,de.comp.lang.java,de.comp.lang.iso-c++
Followup-To: de.comp.objekt

Jemand fragt »wofür OOP denn nun gut sei« und erhält eine
abstrakte Antwort: Beispielsweise »Verbesserung der
Wartbarkeit von Software durch Polymorphie«.

Aber wie kann man solche Behauptungen belegen?
Hierfür wäre ein überzeugendes Beispiel hilfreich.
Am besten ein Beispiel, daß auch für Anfänger verständlich ist.

Was ist das kleinste (kürzeste, einfachste) portable Java-
oder C++-Programm, das etwas zu seinem Vorteil
verwendet, das so nur in der OOP möglich ist?

Dann könnte man dieses Programm vorlegen und sagen:
»Das ist offensichtlich viel besser (übersichtlicher,
kürzer, wartbarer, schneller, ...) als es in einer
prozeduralen oder modularen Programmiersprache
(wie Pascal, C oder Modula) je möglich wäre.«

Newsgroups: de.comp.objekt,de.comp.lang.java,de.comp.lang.iso-c++
Followup-To: de.comp.objekt

(Bei einer eventuellen Antwort bitte selber entscheiden,
in welche der genannten Gruppen sie erscheinen soll.
Das Followup-To ist nur ein unverbindlicher Vorschlag.)
Stefan Ram
2007-12-06 08:27:02 UTC
Permalink
Newsgroups: de.comp.objekt,de.comp.lang.java,de.comp.iso-c++
Followup-To: de.comp.objekt (unverbindlicher Vorschlag)
List<String> list=new ArrayList<String>();
Noch einmal zur Klarstellung der Fragestellung:

Gesucht ist eine konkrete Aufgabenstellung, z.B. »Berechne
alle Primzahlen kleiner als 100« und dann eine vollständige
Lösung in C++ oder Java (ein kompilierbares Programm), welche
diese Aufgabenstellung mit objektorientierter Programmierung
löst.

Dabei soll sich dann ein Vorteil erkennen lassen, den man in
einer nicht-objektorientierten Sprache (wie C oder Modula)
oder unter Vermeidung objektorientierter Programmierung nicht
hätte. Das heißt, wenn man dann dieselbe Aufgabenstellung in
einer prozeduralen Sprache löst, soll es nicht möglich sein,
sie so gut zu lösen, wie in der objektorientierten Sprache.

Dann hätte man ein konkretes Beispiel dafür, warum die
objektorientierte Programmierung besser ist. Oder - umgekehrt:
Wenn es niemandem gelingt, wenigstens ein solches Beispiel zu
finden, dann könnte dies ein Hinweise darauf sein, daß es
vielleicht gar keinen solchen Vorteil der objektorientierten
Programmierung gibt. (Ja, ... oder dafür, daß es vielleicht
doch einen Vorteil gibt, aber es nicht möglich ist, diesen in
einem konkreten Beispiel zu erkennen.)
Till Potinius
2007-12-06 09:06:43 UTC
Permalink
Stefan Ram
2007-12-06 09:52:35 UTC
Permalink
Der äußere Containier lässt sich von allen enthaltenen
Elementen ihre Größe geben, berechnet daraus die Gesamtgröße
der Grafik. Dann erzeugt er die Grafiken, in dem er allen
enthaltenen Elementen sagt: Zeichne dich an Position x,y in
diese Grafik.
Wenn da nun die genaue Aufgabenstellung und der konkrete
Quellcode vorliegen würde, könnte man das einmal prozedural
implementieren und dann vergleichen.

Schön wäre eben eine Aufgabe und ein konkreter
objektorientierter Quelltext, bei dem so etwas /nicht/ geht.
Beispielsweise etwas, bei dem jede prozedurale (modulare)
Lösung erkennbar komplizierter oder langsamer ist.
Da wüßte ich jetzt nicht, wie ich das einfach prozedural
lösen sollte.
Wenn man von der Aufgabenstellung ausgehend eine
prozedurale Lösung schreibt, wird diese vielleicht
von Anfang an anders aufgebaut - aber es ist jetzt
erst einmal noch nicht klar, daß dies dann schlechter
ist. Dazu müßte man die Lösungen dann konkret vergleichen.
Die objektorientierte Programmierung ist nicht "besser" oder
"schlechter" als andere.
Das wird doch oft so behauptet.

Etwa implizit dadurch, daß dies heute die Hauptrichtung
des Programmierens ist und die populären Sprachen
alle objektorientiert sein wollen.
Aber gerade komplexe Problemstellungen mit komplexen
Datenstrukturen lassen sich objektorientiert oft sehr schön
lösen.
Es ist nur erstaunlich, daß es so schwierig ist, ein
(möglichst einfaches) Beispielprogramm dafür zu finden.
Gerd K.
2007-12-06 10:16:53 UTC
Permalink
Hallo!
Post by Stefan Ram
Aber gerade komplexe Problemstellungen mit komplexen
Datenstrukturen lassen sich objektorientiert oft sehr schön
lösen.
Es ist nur erstaunlich, daß es so schwierig ist, ein
(möglichst einfaches) Beispielprogramm dafür zu finden.
Was daran liegt, dass der Mehrwert des objektorientierten Paradigmas
sich nicht beim "Programmieren im Kleinen" zeigt...

Gerade die Durchgängigkeit des oo-Ansatzes über alle Phasen
der Softwareentwicklung hinweg (s. Klassiker Coad/Yourdon
Bücher OOA,OOD,OOP usw.), die Natürlichkeit der Abbildung realer
Aspekte ist es, was das oo-Paradigma auszeichnet.

Und oo ist die Konsequenz eines bis zum Ende getriebenen
Geheimnisprinzips, Stichwort Datenkapselung. Gerade Modula 2
Entwicklen kann so oo gut beibringen. Sie kennen mit
der Trennung zwischen DEFINITION und IMPLEMENTATION Modulen
schon einen Grundansatz. Realisiert man abstrakte Datentypen
oder abstrakten Datenobjekte in dieser Sprache, ist man schon ganz
nah an der oo-Welt. Fehlt "nur" Vererbung. *g*

Grüße!
Gerd
Till Potinius
2007-12-06 10:29:01 UTC
Permalink
Wenn da nun die genaue Aufgabenstellung und der konkrete Quellcode
vorliegen würde, könnte man das einmal prozedural implementieren und
dann vergleichen.
Das war keine Aufgabenstellung, sondern teil eines recht großen Skriptes.
Ich werd hier jetzt nicht einige Tausend LOC von Perl posten.
Schön wäre eben eine Aufgabe und ein konkreter objektorientierter
Quelltext, bei dem so etwas /nicht/ geht. Beispielsweise etwas, bei
dem jede prozedurale (modulare) Lösung erkennbar komplizierter oder
langsamer ist.
Da wüßte ich jetzt nicht, wie ich das einfach prozedural lösen sollte.
Wenn man von der Aufgabenstellung ausgehend eine prozedurale Lösung
schreibt, wird diese vielleicht von Anfang an anders aufgebaut - aber
es ist jetzt erst einmal noch nicht klar, daß dies dann schlechter
ist. Dazu müßte man die Lösungen dann konkret vergleichen.
Die objektorientierte Programmierung ist nicht "besser" oder
"schlechter" als andere.
Das wird doch oft so behauptet.
Es wird auch behauptet, dass man eine PFW braucht, damit man sicher ist.
Trotzdem wird es nicht richtiger.
Etwa implizit dadurch, daß dies heute die Hauptrichtung des
Programmierens ist und die populären Sprachen alle objektorientiert
sein wollen.
Mit einer Sprache, die objektorientiert ist, kannst du meist auch
prozedural arbeiten. Umgekehrt geht es nicht.
Aber gerade komplexe Problemstellungen mit komplexen Datenstrukturen
lassen sich objektorientiert oft sehr schön lösen.
Es ist nur erstaunlich, daß es so schwierig ist, ein (möglichst
einfaches) Beispielprogramm dafür zu finden.
Du verlangst ein einfaches Beispiel. Der Vorteil von OOP zeigt sich aber
nicht bei einfachen Problemen. Ein "HelloWorld" lässt sich notfalls auch
auf einer Turing-Maschine schreiben.
Der Vorteil von OOP liegt darin, dass es gut lesbar ist und vor allem,
dass es impliziert ein Problem auf kleinere Teilprobleme aufteilt. Jede
Klasse stellt eine Blackbox dar, und kann ohne Kenntnis des
innenliegenden Programmcodes genutzt werden(so sollte es zumindest sein).
Trotzdem ist es aber möglich, eigene Funktionalität hinzuzufügen, indem
man eine Unterklasse definiert, die die Klasse erweitert.

Ein Beispiel, wo sich die Stärken von OOP zeigen, wird nie wirlich
einfach sein, sondern erfordert einiges an Code und vermutlich auch
einige Seiten Problemstellung.

Grüße, Till
--
"Computer gehorchen deinen Befehlen, nicht deinen Absichten."
Frank Buss
2007-12-06 12:37:43 UTC
Permalink
Post by Till Potinius
Mit einer Sprache, die objektorientiert ist, kannst du meist auch
prozedural arbeiten. Umgekehrt geht es nicht.
Umgekehrt geht das auch recht gut. Gibt in C viele Beispiele dafür, z.B.
das Windows GDI: Man kann ein Fenster als Objekt auffassen und hat eine
Menge Funktionen, die dieses als ersten Parameter bekommen. Ob man nun
window.getSize() oder getWindowSize(window) schreibt ändert nichts am
objektorientierten Konzept. Das wird beim Windows GDI sogar noch weiter
getrieben, mit Window Klassen usw.

Generell eignet sich objektorientierte Programmierung, ob nun in C, C++
oder Java, wohl gut für GUI-Aufgaben. Liegt aber vielleicht auch daran, daß
noch nicht viele gute Konzepte bekannt sind, um GUI-Libraries z.B. rein
funktional abzubilden (wobei es aber schon einige interessante Ansätze für
Haskell gibt).
--
Frank Buss, ***@frank-buss.de
http://www.frank-buss.de, http://www.it4-systems.de
Niels Braczek
2007-12-06 11:00:44 UTC
Permalink
Post by Stefan Ram
Aber gerade komplexe Problemstellungen mit komplexen
Datenstrukturen lassen sich objektorientiert oft sehr schön
lösen.
Es ist nur erstaunlich, daß es so schwierig ist, ein
(möglichst einfaches) Beispielprogramm dafür zu finden.
Das mag daran liegen, dass bei einfachen Problemstellungen idR die
prozedurale Programmierung effizienter ist. OO kann ihre Stärken erst
bei hinreichender Komplexität ausspielen.

MfG
Niels
--
| http://www.kolleg.de · Das Portal der Kollegs in Deutschland |
| http://www.bsds.de · BSDS Braczek Software- und DatenSysteme |
| Webdesign · Webhosting · e-Commerce · Joomla! Content Management |
------------------------------------------------------------------
Ingo Leschnewsky
2007-12-06 11:40:16 UTC
Permalink
Hallo Niels!
Post by Niels Braczek
Das mag daran liegen, dass bei einfachen Problemstellungen idR die
prozedurale Programmierung effizienter ist. OO kann ihre Stärken erst
bei hinreichender Komplexität ausspielen.
Wenn man sich also konsequent an das Motto "keep it simple" hält, sollte
man OOP nicht benötigen... ;-)

Da aber C-Profis zur Zeit auf dem Arbeitsmarkt nicht besonders gefragt
sind, versuche ich gerade, anhand von Java die OOP zu erlernen. Das
fällt mir allerdings schwer, weil die Beispiele entweder zu simpel sind,
um die Vorteile von OOP zu erkennen, oder zu komplex, um daran eine neue
Programmiersprache zu erlernen.

Ich programmiere ja nun schon länger als 30 Jahre (von Taschenrechnern
über BASIC, PASCAL, C, Assembler, Tcl/Tk, etc.), aber bei Java habe ich
nicht den Eindruck, daß das unter dem Motto "keep it simple" steht. ;-)

Wenn ich z.B. (was ja öfter mal vorkommt) nur eine Datei öffnen möchte,
dann mache ich das in C oder PASCAL mit einem einzigen Befehl, dem ich
dem Dateinamen bzw. Pfad übergebe. Danach kann ich aus der Datei mittels
des Handles, welches ich beim Öffnen erhalte, lesen. In Java habe ich
gerade gelernt, daß ich drei Schritte dazu brauche: Einmal ein
Dateiobjekt anhand des Namens erzeugen, dann damit ein weiteres Objekt
verbinden, und mit diesem wiederum einen "BufferedReader", um dann
endlich etwas aus der Datei lesen zu können.

Der einzige Vorteil, den ich bei der OOP (gegenüber C, nicht jedoch
gegenüber Tcl/Tk) schon erkennen kann, ist die Entwicklung von GUIs:
Fenster, Buttons und andere Widgets sind natürlich ideale Objekte, bei
denen Vererbung und Polymorphie gewisse Vorteile bieten. Aber wenn dann
diese Sichtweise auch noch auf "die Welt da draußen" übertragen wird,
dann kann ich das kaum noch nachvollziehen. (Die Kapselung sehe ich
nicht als wesentlichen Bestandteil der OOP an, weil ich die auch ebenso
z.B. in C oder PASCAL benutzen kann.)

Und die zusätzliche Sicherheit bei der Speicherverwaltung wird dadurch
erkauft, daß keine Speicherarithmetik mehr möglich ist. Auch habe ich in
JAVA bislang vergebens nach einem "free"-Befehl gesucht, um dem Garbage
Collector die Arbeit zu erleichtern. :)

Ich glaube, ich werde in nächster Zeit hier noch öfter mit Fragen
auftauchen. Aber zuerst einmal muß ich es schaffen, eclipse richtig zu
installieren. Nach dem Startversuch passiert nicht sehr viel, und mit
der Fehlermeldung im Log kann ich noch nicht viel anfangen... :-/

Gruß,
Ingo
Ingo R. Homann
2007-12-06 12:00:56 UTC
Permalink
Hi,
Post by Ingo Leschnewsky
Wenn ich z.B. (was ja öfter mal vorkommt) nur eine Datei öffnen möchte,
dann mache ich das in C oder PASCAL mit einem einzigen Befehl, dem ich
dem Dateinamen bzw. Pfad übergebe. Danach kann ich aus der Datei mittels
des Handles, welches ich beim Öffnen erhalte, lesen. In Java habe ich
gerade gelernt, daß ich drei Schritte dazu brauche: Einmal ein
Dateiobjekt anhand des Namens erzeugen, dann damit ein weiteres Objekt
verbinden, und mit diesem wiederum einen "BufferedReader", um dann
endlich etwas aus der Datei lesen zu können.
IIRC ist zumindest das File-Objekt nicht nötig, weil ein FileInputStream
direkt mit einem Dateinamen initialisiert werden kann. Gut, es muss noch
ein BufferedReader drumherum gebastelt werden, was ein gewisser
Mehraufwand ist, aber was soll's? Dafür habe ich immerhin die
Möglichkeit, das Ganze später einmal ganz einfach z.B. auf eine URL
(anstelle der Datei) zu erweitern.
Post by Ingo Leschnewsky
Der einzige Vorteil, den ich bei der OOP (gegenüber C, nicht jedoch
Fenster, Buttons und andere Widgets sind natürlich ideale Objekte, bei
denen Vererbung und Polymorphie gewisse Vorteile bieten. Aber wenn dann
diese Sichtweise auch noch auf "die Welt da draußen" übertragen wird,
dann kann ich das kaum noch nachvollziehen. (Die Kapselung sehe ich
nicht als wesentlichen Bestandteil der OOP an, weil ich die auch ebenso
z.B. in C oder PASCAL benutzen kann.)
Nun, gerade GUIs finde ich mit Java *nicht* schön zu entwickeln, weil
die mitgeleiferten Layout-Manager (IMHO) eine einzige Katastrophe sind.
Ohne JGoodies' FormsLayout wäre ich längst verzweifelt.
Post by Ingo Leschnewsky
Und die zusätzliche Sicherheit bei der Speicherverwaltung wird dadurch
erkauft, daß keine Speicherarithmetik mehr möglich ist. Auch habe ich in
JAVA bislang vergebens nach einem "free"-Befehl gesucht, um dem Garbage
Collector die Arbeit zu erleichtern. :)
Das schöne ist doch, dass gar kein free() mehr nötig ist! Zu C++-Zeiten
bestand der Haupt-Teil der Entwicklung größerer Software doch daraus,
Speicherlecks und Speicherzugriffsfehler (aufgrund einer verfrühten
Freigabe) zu fixen.

Mit der Kritik, dass es schön wäre, dem GC manchmal unter die Arme zu
greifen, und dass vernünftige "finalizer" praktisch wären, hast Du
allerdings recht.

Ciao,
Ingo
Ingo Leschnewsky
2007-12-06 12:23:00 UTC
Permalink
Hi Namensvetter! :)
Post by Ingo R. Homann
IIRC ist zumindest das File-Objekt nicht nötig, weil ein FileInputStream
direkt mit einem Dateinamen initialisiert werden kann. Gut, es muss noch
ein BufferedReader drumherum gebastelt werden, was ein gewisser
Mehraufwand ist, aber was soll's? Dafür habe ich immerhin die
Möglichkeit, das Ganze später einmal ganz einfach z.B. auf eine URL
(anstelle der Datei) zu erweitern.
Ok, bei C war man auf möglichst gute Libraries jenseits der Standard-Lib
angewiesen. (Wie es bei C++ ist, weiß ich nicht.) Die mußte man entweder
"bekommen", oder selbst entwickeln, um vernünftig programmieren zu
können. Insbesondere, wenn es um die Entwicklung von GUIs ging...
Post by Ingo R. Homann
Nun, gerade GUIs finde ich mit Java *nicht* schön zu entwickeln, weil
die mitgeleiferten Layout-Manager (IMHO) eine einzige Katastrophe sind.
Ohne JGoodies' FormsLayout wäre ich längst verzweifelt.
So weit bin ich noch nicht. ;-)

Ich fand die Layout-Manager in Tk eigentlich ziemlich gut und
nachvollziehbar. In Java habe ich bislang nur mitbekommen, daß es
wesentlich mehr von der Sorte gibt, ohne daß ich schon im Einzelnen die
Unterschiede, bzw. Vor- und Nachteile kenne.
Post by Ingo R. Homann
Das schöne ist doch, dass gar kein free() mehr nötig ist! Zu C++-Zeiten
bestand der Haupt-Teil der Entwicklung größerer Software doch daraus,
Speicherlecks und Speicherzugriffsfehler (aufgrund einer verfrühten
Freigabe) zu fixen.
Ich habe allerdings weder C++ gemacht, noch in C größere Projekte
bearbeitet. Kann mir aber gut vorstellen, daß das bei mangelnder
"Disziplin" in einem größerem Team zum Problem werden kann.
Post by Ingo R. Homann
Mit der Kritik, dass es schön wäre, dem GC manchmal unter die Arme zu
greifen, und dass vernünftige "finalizer" praktisch wären, hast Du
allerdings recht.
A propos: Leider habe ich in meinem "Lehrbuch" ("Java von Kopf bis Fuß")
nichts über einen "destructor" gefunden, der beim "Sterben" eines
Objekts ausgeführt wird. Es wird zwar darauf hingewiesen, daß man in
Klassenvariablen prima zählen kann, wieviele Objekte erzeugt wurden
(indem man im Konstruktor inkrementiert). Aber es muß doch auch eine
Möglichkeit geben, solch einen Zähler wieder zu dekrementieren, wenn
Objekte nicht mehr referenziert werden, oder?

Gruß,
Ingo
Stefan Kuhne
2007-12-06 12:36:40 UTC
Permalink
Post by Ingo Leschnewsky
Hi Namensvetter! :)
A propos: Leider habe ich in meinem "Lehrbuch" ("Java von Kopf bis Fuß")
nichts über einen "destructor" gefunden, der beim "Sterben" eines
Objekts ausgeführt wird. Es wird zwar darauf hingewiesen, daß man in
Klassenvariablen prima zählen kann, wieviele Objekte erzeugt wurden
(indem man im Konstruktor inkrementiert). Aber es muß doch auch eine
Möglichkeit geben, solch einen Zähler wieder zu dekrementieren, wenn
Objekte nicht mehr referenziert werden, oder?
Dafür gibt es die finalize Methode:

public class Tisch {
static private int existierendeTische = 0;

public Tisch() {
++existierendeTische;
}

public void finalize() {
--existierendeTische;
}

static public int wievieleTischeExistent() {
return existierendeTische;
}
}

Stefan Kuhne
Ingo Leschnewsky
2007-12-06 12:51:40 UTC
Permalink
Hi Stefan!
Danke! Dazu aber gleich noch eine Frage...

Werden Objekte mit einer finalize-Methode denn "sofort" von der Garbage
Collection bearbeitet, sobald sie nicht mehr referenziert werden?

Ich weiß ja über die Garbage Collection eigentlich nur, daß "irgendwann"
aufgeräumt wird, z.B. wenn Speicher benötigt wird. Aber solange finalize
(in Deinem Beispiel) nicht ausgeführt wird, hätte ja die statische
Variable noch nicht den korrekten Wert. (Aufgrund dieses Problems hatte
ich auch nach so etwas wie "free" (in C) Ausschau gehalten.)

Gruß,
Ingo
Andreas Hartl
2007-12-06 13:28:17 UTC
Permalink
Post by Ingo Leschnewsky
Hi Stefan!
Danke! Dazu aber gleich noch eine Frage...
Werden Objekte mit einer finalize-Methode denn "sofort" von der Garbage
Collection bearbeitet, sobald sie nicht mehr referenziert werden?
Hängt vom Garbage Collector ab. Einer der einfachsten GC-Strategien ist
das "Reference Counting", bei dem einfach ein Zähler inkrementiert und
dekrementiert wird. Fällt er auf 0, kann auch gleich der Speicher
freigegeben werden (und wird meistens auch).

Reference Counting funktioniert leider mit zyklischen Strukturen (A
referenziert B, B referenziert A) nicht ohne manuellen Eingriff; Java
hatte immer schon etwas kompliziertere GC-Strategien, die allerdings
alle *irgendwann* ablaufen. Ein kurzes und gut verständliches White
Paper dazu findest du unter
<http://java.sun.com/javase/technologies/hotspot/gc/memorymanagement_whitepaper.pdf>.
Post by Ingo Leschnewsky
Ich weiß ja über die Garbage Collection eigentlich nur, daß "irgendwann"
aufgeräumt wird, z.B. wenn Speicher benötigt wird. Aber solange finalize
(in Deinem Beispiel) nicht ausgeführt wird, hätte ja die statische
Variable noch nicht den korrekten Wert. (Aufgrund dieses Problems hatte
ich auch nach so etwas wie "free" (in C) Ausschau gehalten.)
Java garantiert dir übrigens nicht mal, dass finalize überhaupt
ausgeführt wird. Sonst gäbe es nämlich System.runFinalizersOnExit nicht.
Diese Methode ist übrigens deprecated, und das aus guten Gründen. Mehr dazu:

<http://www.hpl.hp.com/personal/Hans_Boehm/misc_slides/java_finalizers.pdf>

Sprachen sind unterschiedlich, auch wenn C und Java auf den ersten Blick
wegen der Klammern und mancher Basistypen ähnlich aussehen. Du solltest
dich drauf einstellen und versuchen, nicht C in Java-Syntax zu schreiben
(real programmers can write Fortran in any language). Wahrscheinlich
brauchst du free nicht, sondern ein anderes Vorgehen. Typischerweise
eine explizite .dispose() oder .free() Methode in der Klasse, die du in
einem finally {}-Teil des Objekt-Erzeugers aufrufst.

Lies dir am besten die Folien von Hans Böhm durch, dazu noch
<http://www.devx.com/Java/Article/30192>. Wenn du danach immer noch der
Ansicht bist, für ein Problem unbedingt sowas ähnliches wie einen
Destructor zu brauchen, schlage ich vor, du fragst hier in dclj wieder nach.

Andreas
Jochen Theodorou
2007-12-06 13:40:17 UTC
Permalink
Post by Ingo Leschnewsky
Hi Stefan!
Danke! Dazu aber gleich noch eine Frage...
Werden Objekte mit einer finalize-Methode denn "sofort" von der Garbage
Collection bearbeitet, sobald sie nicht mehr referenziert werden?
ein guter Rat: vergiss finalize. Sun hat es bereut diese Methode jemals
eingeführt zu haben und es wäre wahrscheinlich eine der ersten die
weider aus Java herausfliegt wenn man mit der Kompatibilität brechen würde.

finalize wird aufgerufen wenn der normale GC das Objekt abräumt...
allerdings, wenn dein Programm abschmiert oder anders vorzeitig beendet
wird (zum Beispiel durch System.exit()), dann ist der Aufruf von
finalize nicht mehr garantiert. Ausserdem reduziert das Vorhandensein
dieser Methode die Performance des GC nicht unerheblich.

Kurz: ich kann nur davon abraten das zu verwenden. Ich habe bisher noch
nicht wirklich eine Verwendung von finalize gesehen die auch Sinn macht.
Da Zählen der Objekte könnte man auch anders machen... auch wenn das
dann nicht wirklich schön ist

Gruss theo
--
Jochen "blackdrag" Theodorou
The Groovy Project Tech Lead (http://groovy.codehaus.org)
http://blackdragsview.blogspot.com/
http://www.g2one.com/
Ingo Leschnewsky
2007-12-06 13:48:09 UTC
Permalink
Hallo Jochen!
Post by Jochen Theodorou
Kurz: ich kann nur davon abraten das zu verwenden. Ich habe bisher noch
nicht wirklich eine Verwendung von finalize gesehen die auch Sinn macht.
Ok, es gibt ja auch andere Möglichkeiten. Nur drängte sich die Frage
halt auf, weil als Beispiel bei den statischen Variablen ja gerade die
"Eleganz" gepriesen wird, mit der man erzeugte Objekte zählen kann. Aber
wenn der umgekehrte Fall umso komplizierter ist, dann werde ich darauf
wohl verzichten.
Post by Jochen Theodorou
Da Zählen der Objekte könnte man auch anders machen... auch wenn das
dann nicht wirklich schön ist
Hm, ich habe den Eindruck, daß man in JAVA auch gar nicht so "schön" (im
Sinne von "elegant") wie in C programmieren kann... ;-)

Gruß,
Ingo
Jochen Theodorou
2007-12-06 17:42:20 UTC
Permalink
Ingo Leschnewsky schrieb:
[...]
Post by Ingo Leschnewsky
Hm, ich habe den Eindruck, daß man in JAVA auch gar nicht so "schön" (im
Sinne von "elegant") wie in C programmieren kann... ;-)
was glaubst du warum ich mich an der Entwicklung einer Sparche für die
JVM beteilige (sieh Signatur). Groovy ist entstanden weil einige Leute
einfach nur von der Sprache Java genervt waren

Gruss theo
--
Jochen "blackdrag" Theodorou
The Groovy Project Tech Lead (http://groovy.codehaus.org)
http://blackdragsview.blogspot.com/
http://www.g2one.com/
Robert Kochem
2007-12-08 10:48:40 UTC
Permalink
Post by Jochen Theodorou
Kurz: ich kann nur davon abraten das zu verwenden. Ich habe bisher noch
nicht wirklich eine Verwendung von finalize gesehen die auch Sinn macht.
Wenn man nur natives Java programmiert mag das stimmen. Sobald man aber
über JNI mit der Außenwelt "kommuniziert" ist finalize() sehr brauchbar, da
man in der GC-losen Außenwelt Objekte eben selber freigeben muss.

Robert
Hubert Partl
2007-12-07 11:25:22 UTC
Permalink
Post by Ingo Leschnewsky
Werden Objekte mit einer finalize-Methode denn "sofort" von der Garbage
Collection bearbeitet, sobald sie nicht mehr referenziert werden?
nein, sondern "irgendwann" oder vielleicht auch gar nicht,
wenn bis zum System.exit() kein Speicherengpass auftritt
oder wenn gar kein System.exit() ausgefuehrt wird,
weil der User das Java-GUI mehrere Wochen lang
bis zum naechsten Stromausfall auf seinem PC offen laesst.

Deshalb sollte man das Schliessen von Ressourcen
nicht in finalize() programmieren,
sondern in einer eigenen close() Methode,
die der Anwender dann an geeigneten Stellen explizit aufrufen muss.

Beispiele: OutputStream, Socket, Connection, ...


--
Jochen Theodorou
2007-12-06 13:34:21 UTC
Permalink
Post by Stefan Kuhne
Post by Ingo Leschnewsky
Hi Namensvetter! :)
A propos: Leider habe ich in meinem "Lehrbuch" ("Java von Kopf bis
Fuß") nichts über einen "destructor" gefunden, der beim "Sterben"
eines Objekts ausgeführt wird. Es wird zwar darauf hingewiesen, daß
man in Klassenvariablen prima zählen kann, wieviele Objekte erzeugt
wurden (indem man im Konstruktor inkrementiert). Aber es muß doch auch
eine Möglichkeit geben, solch einen Zähler wieder zu dekrementieren,
wenn Objekte nicht mehr referenziert werden, oder?
public class Tisch {
static private int existierendeTische = 0;
public Tisch() {
++existierendeTische;
}
public void finalize() {
--existierendeTische;
}
static public int wievieleTischeExistent() {
return existierendeTische;
}
}
es wird nicht garantiert das finalize auch aufgerufen wird! In Java
macht man die Ressourcenverwaltung immer programmatisch. Das Problem von
"free", dem man begegnen möchte, sind ja nicht Ressourcen, die nicht
freigegeben werden (Aufruf von free vergessen), sondern man möchte
verhindern das man Zeiger auf Speicherbereiche mit ungültigen Inhalt
bekommt.... man hat also irgendwo ein free gemacht, aber vergessen den
Pointer zu diesem Bereich auch an allen(!) Stellen zu entfernen. Die
Suche nach nicht freigegeben Ressourcen kann zwar manchmal auch nerven,
ist meist aber wesentlich leichter reproduzierbar.

Gruss theo
--
Jochen "blackdrag" Theodorou
The Groovy Project Tech Lead (http://groovy.codehaus.org)
http://blackdragsview.blogspot.com/
http://www.g2one.com/
Ralf Ullrich
2007-12-06 13:44:56 UTC
Permalink
Post by Ingo Leschnewsky
A propos: Leider habe ich in meinem "Lehrbuch" ("Java von Kopf bis Fuß")
nichts über einen "destructor" gefunden, der beim "Sterben" eines Objekts
ausgeführt wird. Es wird zwar darauf hingewiesen, daß man in
Klassenvariablen prima zählen kann, wieviele Objekte erzeugt wurden
(indem man im Konstruktor inkrementiert). Aber es muß doch auch eine
Möglichkeit geben, solch einen Zähler wieder zu dekrementieren, wenn
Objekte nicht mehr referenziert werden, oder?
Nein! Bitte nicht!

Wenn schon dann bitte eine PhantomReference verwenden, die ist dazu da,
über das "Sterben" eines Objektes zu berichten.

finalize() sollte dazu nicht missbraucht werden. Solange man nicht (z.B.
via JNI) Ressourcen belegt hat, die unbedingt eine explizite Freigabe
benötigen, gibt es *KEINEN* Grund finalize() zu überschreiben.

Für den GC ist es außerordentlich aufwendig Objekt aufzuräumen deren
finalize-Methode überschrieben ist, weshalb man das wirklich nicht für
solche Kinkerlitzchen hernehmen sollte.

cu
Hubert Partl
2007-12-06 12:42:24 UTC
Permalink
A propos: Leider habe ich in meinem "Lehrbuch" ("Java von Kopf bis Fuss")
nichts ueber einen "destructor" gefunden, der beim "Sterben" eines
Objekts ausgefuehrt wird.
Es gibt in Java keinen Destruktor.
Das findest Du in jedem Java-Lehrbuch. :-)

Objekte werden frÃŒhestens dann vom Carbage Colletor "entfernt",
wenn keine Referenz mehr darauf verweist.
Damit soll u.a. verhindert werden, dass eine Referenz auf ein "gestorbenes"
Objekt
zu einer "allgemeinen Schutzverletzung" oder zu anderen Laufzeitfehlern
fuehrt.
Moeglichkeit geben, solch einen Zaehler wieder zu dekrementieren, wenn
Objekte nicht mehr referenziert werden, oder?
Dafuer verwendet man add- und remove-Methoden,
die den Zaehler in- bzw. dekrementieren.

Oder man verwendet als Zaehler gleich die size()-Methode der Liste. :-)

--
Ingo R. Homann
2007-12-06 13:46:30 UTC
Permalink
Hi,
Post by Ingo Leschnewsky
Post by Ingo R. Homann
IIRC ist zumindest das File-Objekt nicht nötig, weil ein
FileInputStream direkt mit einem Dateinamen initialisiert werden kann.
Gut, es muss noch ein BufferedReader drumherum gebastelt werden, was
ein gewisser Mehraufwand ist, aber was soll's? Dafür habe ich immerhin
die Möglichkeit, das Ganze später einmal ganz einfach z.B. auf eine
URL (anstelle der Datei) zu erweitern.
Ok, bei C war man auf möglichst gute Libraries jenseits der Standard-Lib
angewiesen. (Wie es bei C++ ist, weiß ich nicht.) Die mußte man entweder
"bekommen", oder selbst entwickeln, um vernünftig programmieren zu
können. Insbesondere, wenn es um die Entwicklung von GUIs ging...
Ich meinte weniger das Fehlen von guten Standard-Libraries in C, als
vielmehr der Vorzug, gegen die "Schnittstelle" InputStream programmieren
zu können, ohne wissen zu müssen, ob dahinter eine Datei oder eine URL
steckt.
Post by Ingo Leschnewsky
Post by Ingo R. Homann
Das schöne ist doch, dass gar kein free() mehr nötig ist! Zu
C++-Zeiten bestand der Haupt-Teil der Entwicklung größerer Software
doch daraus, Speicherlecks und Speicherzugriffsfehler (aufgrund einer
verfrühten Freigabe) zu fixen.
Ich habe allerdings weder C++ gemacht, noch in C größere Projekte
bearbeitet. Kann mir aber gut vorstellen, daß das bei mangelnder
"Disziplin" in einem größerem Team zum Problem werden kann.
Gerade bei großen, verteilten und/oder multithreaded Anwendungen ist das
nicht nur eine Frage von "Disziplin", sondern auch von "gutem" (bzw.
sehr komplex werdendem) Design.
Post by Ingo Leschnewsky
A propos: Leider habe ich in meinem "Lehrbuch" ("Java von Kopf bis Fuß")
nichts über einen "destructor" gefunden, der beim "Sterben" eines
Objekts ausgeführt wird. Es wird zwar darauf hingewiesen, daß man in
Klassenvariablen prima zählen kann, wieviele Objekte erzeugt wurden
(indem man im Konstruktor inkrementiert). Aber es muß doch auch eine
Möglichkeit geben, solch einen Zähler wieder zu dekrementieren, wenn
Objekte nicht mehr referenziert werden, oder?
Wie schon andere schrieben: finalizer. Entgegen hartnäckigen Gerüchten
läuft der in der Praxis sehr, sehr gut (sofern man dort keine
Schweinerein anstellt, wie die Referenz wieder reachable zu machen), hat
aber natürlich den Nachteil, dass er nicht unmittelbar beim
out-of-scope-gehen der (letzten) Referenz aufgerufen wird, sondern erst
wenn der GC sich bequemt. (Und damit ist er dann in der Tat wieder für
viele praktische Zwecke unbrauchbar - nur eben aus anderen Gründen, als
viele Leute denken. :-)

Ciao,
Ingo
Ingo R. Homann
2007-12-06 13:49:22 UTC
Permalink
Hi,
Post by Ingo R. Homann
Wie schon andere schrieben: finalizer. Entgegen hartnäckigen Gerüchten
läuft der in der Praxis sehr, sehr gut (sofern man dort keine
Schweinerein anstellt, wie die Referenz wieder reachable zu machen), hat
aber natürlich den Nachteil, dass er nicht unmittelbar beim
out-of-scope-gehen der (letzten) Referenz aufgerufen wird, sondern erst
wenn der GC sich bequemt. (Und damit ist er dann in der Tat wieder für
viele praktische Zwecke unbrauchbar - nur eben aus anderen Gründen, als
viele Leute denken. :-)
OK, wie Ralf gerade dargelegt hat, gibt es noch einen weiteren guten
Grund, keinen finalizer zu verwenden (der allerdings ebenfalls
unabhängig von den beiden o.g. Gründen (bzw. dem og. echten, und dem
"Nicht-Grund") ist! :-)

Ciao,
Ingo
Till Potinius
2007-12-06 12:45:25 UTC
Permalink
Post by Ingo R. Homann
Das schöne ist doch, dass gar kein free() mehr nötig ist! Zu C++-Zeiten
bestand der Haupt-Teil der Entwicklung größerer Software doch daraus,
Speicherlecks und Speicherzugriffsfehler (aufgrund einer verfrühten
Freigabe) zu fixen.
Mit der Kritik, dass es schön wäre, dem GC manchmal unter die Arme zu
greifen, und dass vernünftige "finalizer" praktisch wären, hast Du
allerdings recht.
Da gab es mal, AFAIR von IBM, ein paper, wo schön aufgezeigt wurde, dass
mittlerweile der automatische GC von Java effizienter arbeitet als das
manuelle verwalten mit malloc und free.

ah, hier:
http://www-128.ibm.com/developerworks/java/library/j-jtp09275.html?ca=dr-
jw22JavaUrbanLegends

Grüße, Till
--
"Computer gehorchen deinen Befehlen, nicht deinen Absichten."
Ingo R. Homann
2007-12-06 13:40:18 UTC
Permalink
Hi,
Post by Till Potinius
Post by Ingo R. Homann
Das schöne ist doch, dass gar kein free() mehr nötig ist! Zu C++-Zeiten
bestand der Haupt-Teil der Entwicklung größerer Software doch daraus,
Speicherlecks und Speicherzugriffsfehler (aufgrund einer verfrühten
Freigabe) zu fixen.
Mit der Kritik, dass es schön wäre, dem GC manchmal unter die Arme zu
greifen, und dass vernünftige "finalizer" praktisch wären, hast Du
allerdings recht.
Da gab es mal, AFAIR von IBM, ein paper, wo schön aufgezeigt wurde, dass
mittlerweile der automatische GC von Java effizienter arbeitet als das
manuelle verwalten mit malloc und free.
Im Allgemeinen ist das ganz sicher richtig. Trotzdem denke ich, gibt es
Spezialfälle, wo ein expliziter Hinweis an den GC sinnvoll sein kann.

Und mit "vernünftigem finalizer" meinte ich natürlich einen Mechanismus,
der beim out-of-scope-gehen einer Referenz zuschlägt (z.B. um andere
Resourcen als Speicher freigeben zu können, wie DB-Verbindungen). Das
ist natürlich weitgehend unabhängig von einem GC (eben weil's Referenzen
betrifft und nicht Objekte).

Ciao,
Ingo
Christoph Herrmann
2007-12-06 14:37:29 UTC
Permalink
Post by Ingo Leschnewsky
Wenn man sich also konsequent an das Motto "keep it simple" hält, sollte
man OOP nicht benötigen... ;-)
An das Motto sollte man sich immer halten. Je einfacher eine Lösung umso
leichter Wartbar ist diese in der Regel weil sie verständlicher ist als
eine äquivalente Lösung, welche vor Komplexität strotzt.
Post by Ingo Leschnewsky
Da aber C-Profis zur Zeit auf dem Arbeitsmarkt nicht besonders gefragt
sind, versuche ich gerade, anhand von Java die OOP zu erlernen. Das
fällt mir allerdings schwer, weil die Beispiele entweder zu simpel sind,
um die Vorteile von OOP zu erkennen, oder zu komplex, um daran eine neue
Programmiersprache zu erlernen.
Vielleicht liegt das Problem eher an der Gewöhnung an die prozedurale
Arbeitsweise. Scheinst dafür wohl zu stur zu sein. ;)
Post by Ingo Leschnewsky
Wenn ich z.B. (was ja öfter mal vorkommt) nur eine Datei öffnen möchte,
dann mache ich das in C oder PASCAL mit einem einzigen Befehl, dem ich
dem Dateinamen bzw. Pfad übergebe. Danach kann ich aus der Datei mittels
des Handles, welches ich beim Öffnen erhalte, lesen. In Java habe ich
gerade gelernt, daß ich drei Schritte dazu brauche: Einmal ein
Dateiobjekt anhand des Namens erzeugen, dann damit ein weiteres Objekt
verbinden, und mit diesem wiederum einen "BufferedReader", um dann
endlich etwas aus der Datei lesen zu können.
Sollte in etwa das sein (kenne Java nicht ganz auswendig ^^):
BufferedReader reader = new BufferedReader(new
InputStreamReader(System.in));

Ist auch eine einzelne Zeile, ab dann kannst per "reader.readLine()"
Zeilenweise die Datei einlesen.

Gerade das Beispiel zeigt doch die Stärke von Java. Wenn ich hier jetzt
keine Datei einlesen will, sondern ein Stream einer Socketverbindung,
dann muss ich nur die Stelle "System.in" ändern. Dem außen herum ist es
egal woher die Daten kommen, es ändert nichts an den Methoden wie ich
etwas lesen kann, du hast auf jeden streambasierenden Datenstrom die
selbe Schnittstelle zum lesen der Daten. Das finde ich genial einfach.
Post by Ingo Leschnewsky
Der einzige Vorteil, den ich bei der OOP (gegenüber C, nicht jedoch
Fenster, Buttons und andere Widgets sind natürlich ideale Objekte, bei
denen Vererbung und Polymorphie gewisse Vorteile bieten. Aber wenn dann
diese Sichtweise auch noch auf "die Welt da draußen" übertragen wird,
dann kann ich das kaum noch nachvollziehen. (Die Kapselung sehe ich
nicht als wesentlichen Bestandteil der OOP an, weil ich die auch ebenso
z.B. in C oder PASCAL benutzen kann.)
Kein Kommentar... habe ich in einem anderen Thread schon erwähnt.
Post by Ingo Leschnewsky
Und die zusätzliche Sicherheit bei der Speicherverwaltung wird dadurch
erkauft, daß keine Speicherarithmetik mehr möglich ist. Auch habe ich in
JAVA bislang vergebens nach einem "free"-Befehl gesucht, um dem Garbage
Collector die Arbeit zu erleichtern. :)
Es gibt keine Notwendigkeit dafür. Du erleichterst dem GC einfach die
Arbeit, indem nicht mehr benötigte Objekte auch nicht mehr referenzierst...
Post by Ingo Leschnewsky
Ich glaube, ich werde in nächster Zeit hier noch öfter mit Fragen
auftauchen. Aber zuerst einmal muß ich es schaffen, eclipse richtig zu
installieren. Nach dem Startversuch passiert nicht sehr viel, und mit
der Fehlermeldung im Log kann ich noch nicht viel anfangen... :-/
Unten hast Link auf meine Homepage und dort im Impressum
Kontaktmöglichkeiten zu mir per Messenger, ich helfe gerne was Eclipse
angeht. Alternativ per E-Mail, aber sowas ist schneller per Messenger
erklärt.
--
Mit freundlichen Grüßen,
Christoph Herrmann

http://dragonprojects.de/
Ingo Leschnewsky
2007-12-06 15:15:23 UTC
Permalink
Hallo Christoph!
Post by Christoph Herrmann
Vielleicht liegt das Problem eher an der Gewöhnung an die prozedurale
Arbeitsweise. Scheinst dafür wohl zu stur zu sein. ;)
Das kann durchaus sein, denn schließlich programmiere ich bereits seit
vielen Jahren prozedural. Auch mit exotischen Sprachen wie LISP hatte
ich keine Verständnisprobleme. Aber mein erster vergeblicher Versuch mit
OOP war schon zur Zeit von Turbo PASCAL 5.5. Das war noch die Zeit, als
Arbeitsspeicher knapp war (vor allem unter DOS noch auf 640 kB
beschränkt!), die Prozessoren noch in MHz tickten, und man deswegen
Teile der Programme in Assembler schrieb; doch da schreckte mich die
Größe (und auch die Performance) der kompilierten OO-Programme ab.

Später habe ich es dann nochmal mit C++ versucht. Da ich dafür damals
aber keine Verwendung hatte, blieb auch das ein halbherziger Versuch.
Daß ich es jetzt mit JAVA nochmal probieren will, liegt einerseits
daran, daß dadurch meine Chancen auf dem Arbeitsmarkt mittelfristig
etwas besser werden (obwohl meistens doch nur "erfahrene"
JAVA-Programmierer gesucht werden). Und andererseits möchte ich
irgendwann auch mal Progrämmchen für mein Handy schreiben. Und da drängt
sich JAVA förmlich auf. :)
Post by Christoph Herrmann
Unten hast Link auf meine Homepage und dort im Impressum
Kontaktmöglichkeiten zu mir per Messenger, ich helfe gerne was Eclipse
angeht. Alternativ per E-Mail, aber sowas ist schneller per Messenger
erklärt.
Danke für das Angebot, aber IRC scheint das einzige Element der
Schnittmenge zu sein (ich hätte ansonsten noch Skype zu bieten)... ;-)

Dann werde ich demnächst mal zuhause den IRC-Client entstauben, und Dir
dann (spätabends?) spannende Geschichten aus dem Logfile erzählen... :-D

Bis dahin kann ich meine bislang noch recht kleinen JAVA-Programme auch
noch in UltraEdit erstellen.

Gruß,
Ingo
Jochen Theodorou
2007-12-06 17:34:08 UTC
Permalink
Post by Ingo Leschnewsky
Hallo Christoph!
Post by Christoph Herrmann
Vielleicht liegt das Problem eher an der Gewöhnung an die prozedurale
Arbeitsweise. Scheinst dafür wohl zu stur zu sein. ;)
Das kann durchaus sein, denn schließlich programmiere ich bereits seit
vielen Jahren prozedural. Auch mit exotischen Sprachen wie LISP hatte
ich keine Verständnisprobleme.
wenn du LISP kennst, wie wäre es dann mit CLOS? Manche behaupten ja,
Java sein nicht wirklich gute OOP ;)
Post by Ingo Leschnewsky
Aber mein erster vergeblicher Versuch mit
OOP war schon zur Zeit von Turbo PASCAL 5.5. Das war noch die Zeit, als
Arbeitsspeicher knapp war (vor allem unter DOS noch auf 640 kB
beschränkt!), die Prozessoren noch in MHz tickten, und man deswegen
Teile der Programme in Assembler schrieb; doch da schreckte mich die
Größe (und auch die Performance) der kompilierten OO-Programme ab.
TP 5.5, OMG! Ich muss sagen ich fan damals die Records ja ganz schön und
auch das man Funktionen in den records "speichern" konnte, aber so
richtige OOP habe ich damit damals nicht begriffen. Es ist auch nicht
etwas wie eine mathematische Gleichung, bei der man es versteht, sobald
man die Grundlagen verstehet. Ich denke OOP versteht man erst dann
wirklich wenn man damit arbeitet. Nach und nach schleicht sich eine
bestimmte Denkweise in deinen Programmierstil, denn OOP ist meiner
Ansicht nach keine Technik, sondern eine Denkweise. Würde ich es mit
westlicher und östlicher Denkweise vergleichen, wäre für mich OOP der
ganzheitliche Ansatz und Prozedural der westliche Ansatz... aber der
Unterschied ist vielleicht noch schwerer zu erklären.. oder bist du
Sinologe? hehe.

[...]
Post by Ingo Leschnewsky
Bis dahin kann ich meine bislang noch recht kleinen JAVA-Programme auch
noch in UltraEdit erstellen.
würde ich einem Anfänger, der die Klassenbibliothek noch nicht so gut
kennt sowieso empfehlen... aber naja, dazu gab es schon zahlreiche
Threads in dclj

Gruss theo
--
Jochen "blackdrag" Theodorou
The Groovy Project Tech Lead (http://groovy.codehaus.org)
http://blackdragsview.blogspot.com/
http://www.g2one.com/
Ingo Leschnewsky
2007-12-07 10:11:02 UTC
Permalink
Hallo Jochen!
Post by Jochen Theodorou
TP 5.5, OMG! Ich muss sagen ich fan damals die Records ja ganz schön und
auch das man Funktionen in den records "speichern" konnte, aber so
richtige OOP habe ich damit damals nicht begriffen.
Das wurde Turbo PASCAL damals ja auch mit Gewalt übergestülpt.
Post by Jochen Theodorou
Es ist auch nicht
etwas wie eine mathematische Gleichung, bei der man es versteht, sobald
man die Grundlagen verstehet. Ich denke OOP versteht man erst dann
wirklich wenn man damit arbeitet.
Genau da beißt sich der Hund in den Schwanz: Denn solange ich kein
"erfahrener JAVA-Programmierer" bin, ist es sehr schwierig, einen
entsprechenden Job zu bekommen.
Post by Jochen Theodorou
Nach und nach schleicht sich eine
bestimmte Denkweise in deinen Programmierstil, denn OOP ist meiner
Ansicht nach keine Technik, sondern eine Denkweise. Würde ich es mit
westlicher und östlicher Denkweise vergleichen, wäre für mich OOP der
ganzheitliche Ansatz und Prozedural der westliche Ansatz... aber der
Unterschied ist vielleicht noch schwerer zu erklären.. oder bist du
Sinologe? hehe.
Nur Hobbysinologe. ;-) Aber viel "Ganzheitliches" kann ich gerade wegen
der Kapselung in der OOP nicht entdecken.

Ich würde eher sagen: Prozedurale Programmierung entspricht meiner
natürlichen Denkweise, weswegen mir ja auch das Programmieren an sich
quasi mit in die Wiege gelegt wurde. Und dann denke ich immer, die OOP
müssen sich Leute ausgedacht haben, die nicht prozedural denken können
oder wollen. ;-)

Gruß,
Ingo
Jochen Theodorou
2007-12-07 13:10:32 UTC
Permalink
Post by Ingo Leschnewsky
Hallo Jochen!
[....]
Post by Ingo Leschnewsky
Es ist auch nicht etwas wie eine mathematische Gleichung, bei der man
es versteht, sobald man die Grundlagen verstehet. Ich denke OOP
versteht man erst dann wirklich wenn man damit arbeitet.
Genau da beißt sich der Hund in den Schwanz: Denn solange ich kein
"erfahrener JAVA-Programmierer" bin, ist es sehr schwierig, einen
entsprechenden Job zu bekommen.
Java zwingt dich recht schnell dazu in Objekten zu denken.. das geht
eigentlich ganz automatisch. Du kannst auch in dclj fragen nach dem
Design anhand eines Beispielprogrammes stellen. Dann musst du zwar
darauf gefasst sein wegen deinem Design angemeckert zu werden von
manchen, aber du wirst sicherlich auch ein paar wertvolle Tipps bekommen
wie das richtig auszusehen hat.
Post by Ingo Leschnewsky
Nach und nach schleicht sich eine bestimmte Denkweise in deinen
Programmierstil, denn OOP ist meiner Ansicht nach keine Technik,
sondern eine Denkweise. Würde ich es mit westlicher und östlicher
Denkweise vergleichen, wäre für mich OOP der ganzheitliche Ansatz und
Prozedural der westliche Ansatz... aber der Unterschied ist vielleicht
noch schwerer zu erklären.. oder bist du Sinologe? hehe.
Nur Hobbysinologe. ;-) Aber viel "Ganzheitliches" kann ich gerade wegen
der Kapselung in der OOP nicht entdecken.
Ich würde eher sagen: Prozedurale Programmierung entspricht meiner
natürlichen Denkweise, weswegen mir ja auch das Programmieren an sich
quasi mit in die Wiege gelegt wurde. Und dann denke ich immer, die OOP
müssen sich Leute ausgedacht haben, die nicht prozedural denken können
oder wollen. ;-)
hehe... wie denkt man den proedural? Gerade da ich das mit turbo Pascal
mitgemacht habe und dann auch noch objektorientierung in Ada95 erlebt
habe kommt mir das alles wie eine "natürliche" Weiterentwicklung von
Verbundtypen zu Klassen vor. Am Anfang gruppiert man vielleicht ganz
prozedural seine Methoden in der Klasse, so wie man es in einem
Record/Struct tun würde, aber ohne die Möglichkeit diese Methode
auszutauschen und ohne Vererbung zu benutzen. Dann kommt irgendwann der
Punkt an dem man doch die Methode austauschen möchte, also fängt man an
eine Kindklasse zu schreiben, die das macht. Als nächstes merkt man
vielleicht das man dies und das hätte besser machen können, weil der
Code dann kleiner wird oder weniger umständlich... und nach und nach
entwickelt man ein Gespür für OOP. Ich finde diesen Weg am besten, aber
der kostet viel Zeit und viel Arbeit... mehr als die meisten aufbringen
können.

Gruss theo
--
Jochen "blackdrag" Theodorou
The Groovy Project Tech Lead (http://groovy.codehaus.org)
http://blackdragsview.blogspot.com/
http://www.g2one.com/
Ingo Leschnewsky
2007-12-07 13:19:06 UTC
Permalink
Post by Jochen Theodorou
Java zwingt dich recht schnell dazu in Objekten zu denken.. das geht
eigentlich ganz automatisch. Du kannst auch in dclj fragen nach dem
Design anhand eines Beispielprogrammes stellen. Dann musst du zwar
darauf gefasst sein wegen deinem Design angemeckert zu werden von
manchen, aber du wirst sicherlich auch ein paar wertvolle Tipps bekommen
wie das richtig auszusehen hat.
Na, da komme ich hoffentlich auch noch hinkommen, daß ich "in Objekten
denke". Im Moment versuche ich noch, anhand von einfachen Beispielen
herauszufinden, wie es überhaupt richtig auszusehen hat.
Post by Jochen Theodorou
hehe... wie denkt man den proedural? Gerade da ich das mit turbo Pascal
mitgemacht habe und dann auch noch objektorientierung in Ada95 erlebt
habe kommt mir das alles wie eine "natürliche" Weiterentwicklung von
Verbundtypen zu Klassen vor. Am Anfang gruppiert man vielleicht ganz
prozedural seine Methoden in der Klasse, so wie man es in einem
Record/Struct tun würde, aber ohne die Möglichkeit diese Methode
auszutauschen und ohne Vererbung zu benutzen. Dann kommt irgendwann der
Punkt an dem man doch die Methode austauschen möchte, also fängt man an
eine Kindklasse zu schreiben, die das macht. Als nächstes merkt man
vielleicht das man dies und das hätte besser machen können, weil der
Code dann kleiner wird oder weniger umständlich... und nach und nach
entwickelt man ein Gespür für OOP. Ich finde diesen Weg am besten, aber
der kostet viel Zeit und viel Arbeit... mehr als die meisten aufbringen
können.
Ich mache mir gerade Gedanken darüber, welches mein erstes eigenes
JAVA-Programm werden soll. Ideen habe ich einige, und kann ja auch
versuchen, ein "älteres" Programm nochmal neu in JAVA zu schreiben. Nur
sollte es nicht zu umfangreich werden, weil ich sonst als Anfänger den
Überblick verliere. (So ergeht es mir nämlich gerade beim Durchlesen des
Buchs "Java von Kopf bis Fuß".)

Als nächstes will ich jedoch die "Lernvideos" für Anfänger zu eclipse
und JAVA durcharbeiten, die ich im Web gefunden habe. Dazu muß ich es
nur erst noch schaffen, eclipse zuhause zum Laufen zu bringen. Hier auf
der Arbeit kann ich den Fehler leider nicht reproduzieren. Ich werde
zuhause nochmal ein älteres JDK aufspielen, nachdem ich hier die
winkenden Zaunlatten gesehen habe. :)

Gruß,
Ingo
Wanja Gayk
2007-12-07 17:06:13 UTC
Permalink
Ingo Leschnewsky said...
Post by Ingo Leschnewsky
Post by Jochen Theodorou
Java zwingt dich recht schnell dazu in Objekten zu denken.. das geht
eigentlich ganz automatisch. Du kannst auch in dclj fragen nach dem
Design anhand eines Beispielprogrammes stellen. Dann musst du zwar
darauf gefasst sein wegen deinem Design angemeckert zu werden von
manchen, aber du wirst sicherlich auch ein paar wertvolle Tipps bekommen
wie das richtig auszusehen hat.
Na, da komme ich hoffentlich auch noch hinkommen, daß ich "in Objekten
denke". Im Moment versuche ich noch, anhand von einfachen Beispielen
herauszufinden, wie es überhaupt richtig auszusehen hat.
Oh, was "richtig" ist oder "falsch", kann bei OOP-Diskussionen schon in
Glaubenskriege ausarten...

Z.B. würden einige etwas so machen:

class Point{
private int x;
private int y;
public void setX(final int x){this.x=x;}
public void setY(final int y){this.y=y;}
public int getX(){return x;}
public int getY(){return y;}
public void mirrorX(){x=-x;}
public void mirrorY(){y=-y;}
}

Dann ist alles an einem Ort.

Andere hingegen würden es bevorzugen die Methoden, mit denen man einen
Punkt manipulieren kann, in eine eigene Klasse zu stecken.

class Point{
private int x;
private int y;
public void setX(final int x){this.x=x;}
public void setY(final int y){this.y=y;}
public int getX(){return x;}
public int getY(){return y;}
}

interface PointUtil{
public void mirrorX(final Point p);
public void mirrorX(final Point p);
}

class PointUtilImpl{
public void mirrorX(final Point p){p.setX(-p.getX());}
public void mirrorX(final Point p){p.setY(-p.getY());}
}

class ProjectedPointUtilImpl{
private Function projection = new SomeProjection();
public void mirrorX(final Point p){p.setX(projection.eval(-p.getX()));}
public void mirrorX(final Point p){p.setY(projection.eval(-p.getY()));}
}

Dann kann man diesen Manipulator z.B. einfach austauschbar machen, indem
man dieser Methode die eine oder die andere Implementation übergibt:

...
public void mirrorX(Point p, PointUtil util){
util.mirrorX(p);
}


Weitere würden, z.B. jede Manipulation als einzelne Aktion zu
betrachten:

class Point{
private int x;
private int y;
public void setX(final int x){this.x=x;}
public void setY(final int y){this.y=y;}
public int getX(){return x;}
public int getY(){return y;}
}

interface Manipulation<X>{
void manipulate(X target);
}

class MirrorPointX implements Manipulation<Point>{
public void manipulate(final Point p){
p.setX(-p.getX());
}
}

class MirrorPointY implements Manipulation<Point>{
public void manipulate(final Point p){
p.setY(-p.getY());
}
}

Damit kann man dann alle Manipulationen in einer Liste halten und z.B.
auf eine ganze Samlung von Punkten auszuführen:

List<Manipulation<Point>> pipeline = new List<Manipulation<Point>>();
pipeline.add(new MirrorPointX());
....
for(final Point point : cluster){
for(final Manipulation<Point> m : pipeline){
m.manipulate(point);
}
}

Zuletzt macht sich die Frage darüber, was ein Objekt kann oder nicht
also meist am Anwendungsfall fest.

Deswgen ist es schwer zu sagen, was "richtig" und was "falsch" ist.

Gruß,
-Wanja-
--
"Gewisse Schriftsteller sagen von ihren Werken immer: 'Mein Buch, mein
Kommentar, meine Geschichte'. [..] Es wäre besser, wenn sie sagten:
'unser Buch, unser Kommentar, unsere Geschichte'; wenn man bedenkt, dass
das Gute darin mehr von anderen ist als von ihnen." [Blaise Pascal]
Stefan Ram
2007-12-07 17:36:15 UTC
Permalink
Post by Ingo Leschnewsky
Ich mache mir gerade Gedanken darüber, welches mein
erstes eigenes JAVA-Programm werden soll.
Traditionell nimmt man dafür ein Programm,
das »Hello world!« ausgibt. (SCNR)
Ingo Leschnewsky
2007-12-07 22:30:23 UTC
Permalink
Hallo Stefan!
Post by Stefan Ram
Post by Ingo Leschnewsky
Ich mache mir gerade Gedanken darüber, welches mein
erstes eigenes JAVA-Programm werden soll.
Traditionell nimmt man dafür ein Programm,
das »Hello world!« ausgibt. (SCNR)
Also, über dieses Stadium bin ich dann doch schon hinaus. ;-)

Es wird vermutlich entweder das Programm, welches mir zufällig
Vorschläge aus meiner Musiksammlung macht (die liegt als CSV-Datei vor).
Oder das, welches aus ein paar Nährwertangaben die WeightWatcher-Points
berechnet. Das waren damals auch meine ersten Programme in Tcl/Tk. :)

Gruß,
Ingo
Ingo R. Homann
2007-12-07 13:33:01 UTC
Permalink
Hi Ingo,
Post by Ingo Leschnewsky
Ich würde eher sagen: Prozedurale Programmierung entspricht meiner
natürlichen Denkweise, weswegen mir ja auch das Programmieren an sich
quasi mit in die Wiege gelegt wurde. Und dann denke ich immer, die OOP
müssen sich Leute ausgedacht haben, die nicht prozedural denken können
oder wollen. ;-)
Hier liegt IMHO ein Denkfehler vor: Schließlich ist OO ja kein Gegensatz
zu Prozeduraler Programmierung, sondern eine "Erweiterung".

Der Aufbau der einzelnen Methoden bzw. der Programmablauf ist in OO ja
immernoch Prozedural!

Der (erste aber natürlich nicht einzige) Unterschied (bzw.
"Erweiterung") ist der, dass Du in der OO die "Daten" und die
"Prozduren" zusammenfasst.

In einer einfachen, Prozeduralen Sprache würdest Du vielleicht folgendes
schreiben:


struct vektor {
int x,y;
}

funtction vektor add(vektor v1, vektor v2) {
vektor e;
e.x=v1.x+v2.x;
e.y=v1.y+v2.y;
return e;
}

Aufruf:

vektor v1=(1,2), v2=(3,4);
vektor e=add(v1,v2);


Und in einer OO-Sprache sähe das so aus:


class Vektor {

int x,y;

Vektor add(Vektor v) {
return new Vektor(this.x+v.x,this.y+v.y);
}

}


Aufruf:

Vektor v1=new Vektor(1,2), v2=new Vektor(3,4);
Vektor e=v1.add(v2);


Die einzelnen Methoden/Funktionen innerhalb einer Klasse sind aber
immernoch prozedural. Sie sind halt nur *zusätzlich* an ein Objekt gebunden.

Ciao,
Ingo
Tobias Müller
2007-12-06 17:00:13 UTC
Permalink
Post by Ingo Leschnewsky
Da aber C-Profis zur Zeit auf dem Arbeitsmarkt nicht besonders gefragt
sind, versuche ich gerade, anhand von Java die OOP zu erlernen. Das
fällt mir allerdings schwer, weil die Beispiele entweder zu simpel sind,
um die Vorteile von OOP zu erkennen, oder zu komplex, um daran eine neue
Programmiersprache zu erlernen.
Man sollte OOP weniger als Werkzeug ansehen, mehr als ein Konzept.
Post by Ingo Leschnewsky
Ich programmiere ja nun schon länger als 30 Jahre (von Taschenrechnern
über BASIC, PASCAL, C, Assembler, Tcl/Tk, etc.), aber bei Java habe ich
nicht den Eindruck, daß das unter dem Motto "keep it simple" steht. ;-)
Man sollte OOP also weitere "Abstraktionsschicht" in der
Softwareentwicklung sehen. Und das eigentlich unabhängig von der genauen
Sprache.
Post by Ingo Leschnewsky
Wenn ich z.B. (was ja öfter mal vorkommt) nur eine Datei öffnen möchte,
dann mache ich das in C oder PASCAL mit einem einzigen Befehl, dem ich
dem Dateinamen bzw. Pfad übergebe. Danach kann ich aus der Datei mittels
des Handles, welches ich beim Öffnen erhalte, lesen. In Java habe ich
gerade gelernt, daß ich drei Schritte dazu brauche: Einmal ein
Dateiobjekt anhand des Namens erzeugen, dann damit ein weiteres Objekt
verbinden, und mit diesem wiederum einen "BufferedReader", um dann
endlich etwas aus der Datei lesen zu können.
Deine Herrangehensweise ist, meiner Meinung nach, nicht ganz richtig:
Du vergleichst Java mit anderen Sprachen, wie man ein Problem von der
reinen "Tipparbeit" löst, siehst das Java mehr Zeilen braucht, als
C/Pascal. Daraus schliesst das OOP keine Vorteil gegenüber
prozeduralen/modularen Sprachen besitzt. Was ist, wenn andere
OOP-Sprachen das ebenfalls mit einem Befehl machen?
Und sicherlich wird auch non-OOP Sprachen geben, die mehr als eine
Befehl brauchen. Vergleiche Konzepte miteinandere und
Programmiersprachen, aber wenn das mischt, wird dich nur verwirren.
Post by Ingo Leschnewsky
Der einzige Vorteil, den ich bei der OOP (gegenüber C, nicht jedoch
Fenster, Buttons und andere Widgets sind natürlich ideale Objekte, bei
denen Vererbung und Polymorphie gewisse Vorteile bieten. Aber wenn dann
diese Sichtweise auch noch auf "die Welt da draußen" übertragen wird,
dann kann ich das kaum noch nachvollziehen. (Die Kapselung sehe ich
nicht als wesentlichen Bestandteil der OOP an, weil ich die auch ebenso
z.B. in C oder PASCAL benutzen kann.)
Und eigentlich liegt da die Stärke vonn OOP, Sachen aus der Welt da
draussen, lassen sich meisten sehr gut als Klasse modellieren.
Das Problem ist auch, das OOP-Sprachen ein Schritt weiter von der
"realen" Hardware sind, als du es gewohnt bist. Aber das ist Absicht.
Das führt zu "abstracteren" Code, der besser struktueriert ist.
OOP ist ja kein Negativ von Prozeduraler oder modularer Programmierung,
daher findes du in eben auch Ähnlichkeiten.

Grus
Tobias
Sascha Broich
2007-12-07 08:45:36 UTC
Permalink
Post by Tobias Müller
Du vergleichst Java mit anderen Sprachen, wie man ein Problem von der
reinen "Tipparbeit" löst, siehst das Java mehr Zeilen braucht, als
C/Pascal. Daraus schliesst das OOP keine Vorteil gegenüber
prozeduralen/modularen Sprachen besitzt. Was ist, wenn andere
OOP-Sprachen das ebenfalls mit einem Befehl machen?
Und sicherlich wird auch non-OOP Sprachen geben, die mehr als eine
Befehl brauchen. Vergleiche Konzepte miteinandere und
Programmiersprachen, aber wenn das mischt, wird dich nur verwirren.
Dazu fällt mir das "Hello World"-Poster ein:
http://www.lob.de/pdf/helloworld.pdf


Sascha Broich
--
Früher war alles besser.
Aber dann wurden die Pyramiden gebaut.
Ingo Leschnewsky
2007-12-07 10:29:15 UTC
Permalink
Hallo Tobias!
Post by Tobias Müller
Man sollte OOP weniger als Werkzeug ansehen, mehr als ein Konzept.
Es kollidiert nur etwas mit den Konzepten, die ich bereits im Kopf habe. :)
Post by Tobias Müller
Man sollte OOP also weitere "Abstraktionsschicht" in der
Softwareentwicklung sehen. Und das eigentlich unabhängig von der genauen
Sprache.
Hm, C war mir schon abstrakt genug, um nicht alles in Assembler machen
zu müssen. ;-)
Post by Tobias Müller
Du vergleichst Java mit anderen Sprachen, wie man ein Problem von der
reinen "Tipparbeit" löst, siehst das Java mehr Zeilen braucht, als
C/Pascal.
Nunja, das liegt halt auch an meinen persönlichen Vorlieben. Ich mag
halt "Hochsprachen" wie C oder PERL, die nicht so "geschwätzig"
daherkommen. Das andere Extrem ist vermutlich COBOL.
Post by Tobias Müller
Daraus schliesst das OOP keine Vorteil gegenüber
prozeduralen/modularen Sprachen besitzt. Was ist, wenn andere
OOP-Sprachen das ebenfalls mit einem Befehl machen?
Und sicherlich wird auch non-OOP Sprachen geben, die mehr als eine
Befehl brauchen. Vergleiche Konzepte miteinandere und
Programmiersprachen, aber wenn das mischt, wird dich nur verwirren.
Was "Konzepte" betrifft, so suche ich mir persönlich natürlich Sprachen,
die mir liegen, weil sie den Konzepten in meinem Kopf möglichst gut
entsprechen. Das sind nur leider nicht die Sprachen, die gerade auf dem
Arbeitsmarkt gefragt sind.
Post by Tobias Müller
Und eigentlich liegt da die Stärke vonn OOP, Sachen aus der Welt da
draussen, lassen sich meisten sehr gut als Klasse modellieren.
Ich sehe das eher "ganzheitlich", und stopfe daher nicht so gerne
"Sachen aus der Welt da draußen" in irgendwelche Schubladen. ;-)
Post by Tobias Müller
Das Problem ist auch, das OOP-Sprachen ein Schritt weiter von der
"realen" Hardware sind, als du es gewohnt bist.
Das habe ich schon gemerkt. s.o.
Post by Tobias Müller
Aber das ist Absicht.
Das führt zu "abstracteren" Code, der besser struktueriert ist.
Letzteres bezweifele ich.
Post by Tobias Müller
OOP ist ja kein Negativ von Prozeduraler oder modularer Programmierung,
daher findes du in eben auch Ähnlichkeiten.
An ein "Negativ" dachte ich auch nicht. Eher an eine Art "Erweiterung"
für Leute, die Probleme damit haben, strukturiert zu programmieren. Wenn
ich mir allerdings den Markt anschaue, dann scheint es von der Sorte
recht viele zu geben... ;-)

Gruß,
Ingo
Niels Braczek
2007-12-07 12:50:59 UTC
Permalink
Post by Ingo Leschnewsky
Post by Tobias Müller
Und eigentlich liegt da die Stärke vonn OOP, Sachen aus der Welt da
draussen, lassen sich meisten sehr gut als Klasse modellieren.
Ich sehe das eher "ganzheitlich", und stopfe daher nicht so gerne
"Sachen aus der Welt da draußen" in irgendwelche Schubladen. ;-)
OO steckt die Sachen ja auch nicht in Schubladen, sondern fasst ähnliche
Objekte zu Klassen zusammen; Affen und Pferde sind Säugetiere (mit
gemeinsamen Merkmalen), Heuschrecken und Mücken sind Insekten (mit
gemeinsamen Merkmalen), Säugetiere und Insekten sind Lebewesen (mit
gemeinsamen Merkmalen) usw. Somit kann man mit OOP Heuschrecken und
Pferde mit denselben Werkzeugen bearbeiten, wenn diese Werkzeuge auf
Lebewesen im Allgemeinen gemünzt sind.
Post by Ingo Leschnewsky
Post by Tobias Müller
Aber das ist Absicht.
Das führt zu "abstracteren" Code, der besser struktueriert ist.
Letzteres bezweifele ich.
Das liegt an deiner mangelnden Erfahrung mit der Materie.
Post by Ingo Leschnewsky
Post by Tobias Müller
OOP ist ja kein Negativ von Prozeduraler oder modularer Programmierung,
daher findes du in eben auch Ähnlichkeiten.
An ein "Negativ" dachte ich auch nicht. Eher an eine Art "Erweiterung"
für Leute, die Probleme damit haben, strukturiert zu programmieren. Wenn
ich mir allerdings den Markt anschaue, dann scheint es von der Sorte
recht viele zu geben... ;-)
Man kann auch mit OOP Müll programmieren. OO verlangt jedoch, dass man
sich vorher Gedanken über die Zusammenhänge macht; man kann icht so ohne
Weiteres drauflos programmieren. Insofern ist die Fähigkeit strukturiert
programmieren zu können, Voraussetzung für die erfolgreiche Anwendung
des OO-Paradigmas.

MfG
Niels
--
| http://www.kolleg.de · Das Portal der Kollegs in Deutschland |
| http://www.bsds.de · BSDS Braczek Software- und DatenSysteme |
| Webdesign · Webhosting · e-Commerce · Joomla! Content Management |
------------------------------------------------------------------
Ingo Leschnewsky
2007-12-07 13:06:57 UTC
Permalink
Hallo Niels!
Post by Niels Braczek
OO steckt die Sachen ja auch nicht in Schubladen, sondern fasst ähnliche
Objekte zu Klassen zusammen; Affen und Pferde sind Säugetiere (mit
gemeinsamen Merkmalen), Heuschrecken und Mücken sind Insekten (mit
gemeinsamen Merkmalen), Säugetiere und Insekten sind Lebewesen (mit
gemeinsamen Merkmalen) usw. Somit kann man mit OOP Heuschrecken und
Pferde mit denselben Werkzeugen bearbeiten, wenn diese Werkzeuge auf
Lebewesen im Allgemeinen gemünzt sind.
Wenn sie das sind, dann brauche ich nicht einmal zwischen den
verschiedenen Lebewesen zu unterscheiden, sondern kann alle gleich
behandeln. Unterschiedliche Klassen halte ich nur da für sinnvoll, wo
ich eben auch spezielle (klassenspezifische) Werkzeuge benötige.
Post by Niels Braczek
Post by Ingo Leschnewsky
Post by Tobias Müller
Aber das ist Absicht.
Das führt zu "abstracteren" Code, der besser struktueriert ist.
Letzteres bezweifele ich.
Das liegt an deiner mangelnden Erfahrung mit der Materie.
Daran versuche ich ja gerade etwas zu ändern. ;-)
Post by Niels Braczek
Man kann auch mit OOP Müll programmieren. OO verlangt jedoch, dass man
sich vorher Gedanken über die Zusammenhänge macht; man kann icht so ohne
Weiteres drauflos programmieren.
Das war eigentlich auch schon vor OOP so. Nicht nur, daß man Müll
programmieren konnte, sondern auch, daß man sich Gedanken über die zu
verwendenden Algorithmen und Datenstrukturen machte.
Post by Niels Braczek
Insofern ist die Fähigkeit strukturiert
programmieren zu können, Voraussetzung für die erfolgreiche Anwendung
des OO-Paradigmas.
Gibt es eigentlich weniger Bugs, seit es OOP gibt? Oder findet man sie
nur nicht mehr so häufig? ;-)

Gruß,
Ingo
Niels Braczek
2007-12-07 17:10:07 UTC
Permalink
Post by Ingo Leschnewsky
Hallo Niels!
Post by Niels Braczek
OO steckt die Sachen ja auch nicht in Schubladen, sondern fasst ähnliche
Objekte zu Klassen zusammen; Affen und Pferde sind Säugetiere (mit
gemeinsamen Merkmalen), Heuschrecken und Mücken sind Insekten (mit
gemeinsamen Merkmalen), Säugetiere und Insekten sind Lebewesen (mit
gemeinsamen Merkmalen) usw. Somit kann man mit OOP Heuschrecken und
Pferde mit denselben Werkzeugen bearbeiten, wenn diese Werkzeuge auf
Lebewesen im Allgemeinen gemünzt sind.
Wenn sie das sind, dann brauche ich nicht einmal zwischen den
verschiedenen Lebewesen zu unterscheiden, sondern kann alle gleich
behandeln. Unterschiedliche Klassen halte ich nur da für sinnvoll, wo
ich eben auch spezielle (klassenspezifische) Werkzeuge benötige.
Es gibt aber dinge, die ein Insekt tun kann, die einem Säugetier nicht
möglich sind und umgekehrt. Die Klassenbildung und Ableitung sorgt
dafür, dass gemeinsame Methoden nur einmal implementiert werden müssen.
Post by Ingo Leschnewsky
Post by Niels Braczek
Man kann auch mit OOP Müll programmieren. OO verlangt jedoch, dass man
sich vorher Gedanken über die Zusammenhänge macht; man kann icht so ohne
Weiteres drauflos programmieren.
Das war eigentlich auch schon vor OOP so. Nicht nur, daß man Müll
programmieren konnte, sondern auch, daß man sich Gedanken über die zu
verwendenden Algorithmen und Datenstrukturen machte.
Nicht in dem Maße wie bei OOP.
Post by Ingo Leschnewsky
Post by Niels Braczek
Insofern ist die Fähigkeit strukturiert
programmieren zu können, Voraussetzung für die erfolgreiche Anwendung
des OO-Paradigmas.
Gibt es eigentlich weniger Bugs, seit es OOP gibt? Oder findet man sie
nur nicht mehr so häufig? ;-)
Es gibt weniger Bugs, weil OOP, richtig betrieben, frei von
Seiteneffekten ist. Zudem sind Bugs idR schneller lokalisiert.

MfG
Niels
--
| http://www.kolleg.de · Das Portal der Kollegs in Deutschland |
| http://www.bsds.de · BSDS Braczek Software- und DatenSysteme |
| Webdesign · Webhosting · e-Commerce · Joomla! Content Management |
------------------------------------------------------------------
Ingo Leschnewsky
2007-12-07 22:34:58 UTC
Permalink
Hallo Niels!
Post by Niels Braczek
Post by Ingo Leschnewsky
Das war eigentlich auch schon vor OOP so. Nicht nur, daß man Müll
programmieren konnte, sondern auch, daß man sich Gedanken über die zu
verwendenden Algorithmen und Datenstrukturen machte.
Nicht in dem Maße wie bei OOP.
Hm, bei mir war und ist das schon immer so. Das ist eigentlich sogar der
interessanteste Teil. Wenn ich den zufriedenstellend gelöst habe, habe
ich manchmal nicht mal mehr Lust, das auch noch zu kodieren. ;-)
Post by Niels Braczek
Post by Ingo Leschnewsky
Gibt es eigentlich weniger Bugs, seit es OOP gibt? Oder findet man sie
nur nicht mehr so häufig? ;-)
Es gibt weniger Bugs, weil OOP, richtig betrieben, frei von
Seiteneffekten ist. Zudem sind Bugs idR schneller lokalisiert.
So, wie das dasteht (mit dem "richtig betrieben"), gilt das aber nicht
nur für OOP.

Gruß,
Ingo
Florian Diesch
2007-12-08 02:57:34 UTC
Permalink
Post by Ingo Leschnewsky
Post by Tobias Müller
Du vergleichst Java mit anderen Sprachen, wie man ein Problem von
der reinen "Tipparbeit" löst, siehst das Java mehr Zeilen braucht,
als C/Pascal.
Nunja, das liegt halt auch an meinen persönlichen Vorlieben. Ich mag
halt "Hochsprachen" wie C oder PERL, die nicht so "geschwätzig"
daherkommen.
Dann könnten z.B. Python oder Ruby was für dich sein, wenn du OOP machen
willst.





Florian
--
<http://www.florian-diesch.de/>
-----------------------------------------------------------------------
** Hi! I'm a signature virus! Copy me into your signature, please! **
-----------------------------------------------------------------------
Ingo Leschnewsky
2007-12-10 01:58:04 UTC
Permalink
Hallo Florian!
Post by Florian Diesch
Post by Ingo Leschnewsky
Nunja, das liegt halt auch an meinen persönlichen Vorlieben. Ich mag
halt "Hochsprachen" wie C oder PERL, die nicht so "geschwätzig"
daherkommen.
Dann könnten z.B. Python oder Ruby was für dich sein, wenn du OOP machen
willst.
Es ist nicht so, daß ich OOP machen will. Sondern ich denke, daß ich OOP
machen sollte, um auf dem Arbeitsmarkt bessere Chancen zu haben. Und ich
vermute, Java ist zur Zeit am meisten gefragt.

Den letzten Job habe ich auch bekommen, bevor ich die Sprache, die ich
jetzt fast sieben Jahre lang programmiert habe, überhaupt konnte. Aber
es war kein Problem für mich, Tcl innerhalb von zwei Monaten zu lernen.

Und genau das will ich ab Januar mit Java nochmal machen. Da Java stark
an C orientiert ist, eine Sprache, die ich mal sehr gut beherrscht habe,
kann und will ich mich vorwiegend auf die objektorientierten Aspekte von
Java konzentrieren, denn das ist für mich halt neu.

Gruß,
Ingo
Florian Diesch
2007-12-11 13:17:49 UTC
Permalink
Post by Ingo Leschnewsky
Hallo Florian!
Post by Florian Diesch
Post by Ingo Leschnewsky
Nunja, das liegt halt auch an meinen persönlichen Vorlieben. Ich mag
halt "Hochsprachen" wie C oder PERL, die nicht so "geschwätzig"
daherkommen.
Dann könnten z.B. Python oder Ruby was für dich sein, wenn du OOP machen
willst.
Es ist nicht so, daß ich OOP machen will. Sondern ich denke, daß ich
OOP machen sollte, um auf dem Arbeitsmarkt bessere Chancen zu
haben.
Momentan sieht es ja nicht so ganz schlecht aus für Programmierer...
Post by Ingo Leschnewsky
Und ich vermute, Java ist zur Zeit am meisten gefragt.
Kommt wohl auch auf den Anwendungsbereich an, C++ und PHP sind auch
ziemlich verbreitet. Java zu können ist aber sicher kein Fehler.
Post by Ingo Leschnewsky
Den letzten Job habe ich auch bekommen, bevor ich die Sprache, die ich
jetzt fast sieben Jahre lang programmiert habe, überhaupt konnte. Aber
es war kein Problem für mich, Tcl innerhalb von zwei Monaten zu lernen.
Ist mit OOP ähnlich: Wenn du mal das Prinzip verstanden hast, kannst du
dich relativ schnell in eine neue Sprache einarbeiten.
Post by Ingo Leschnewsky
Und genau das will ich ab Januar mit Java nochmal machen. Da Java
stark an C orientiert ist, eine Sprache, die ich mal sehr gut
beherrscht habe, kann und will ich mich vorwiegend auf die
objektorientierten Aspekte von Java konzentrieren, denn das ist für
mich halt neu.
Dann schau dir mal was zum Thema "Entwurfsmuster" an; der Klassiker ist
"Design Patterns" von Gamma, Helm, Johnson und Vlissides. Es geht dabei
um Lösungsansätze für oft auftretende Probleme; ist am Anfang sicher
hilfreich um ein Gefühl dafür zu bekommen, wie man ein Problem mit OOP
angeht, und auch später als Ideengeber nützlich.



Florian
--
<http://www.florian-diesch.de/>
-----------------------------------------------------------------------
** Hi! I'm a signature virus! Copy me into your signature, please! **
-----------------------------------------------------------------------
Christoph Herrmann
2007-12-12 07:50:13 UTC
Permalink
Post by Florian Diesch
Kommt wohl auch auf den Anwendungsbereich an, C++ und PHP sind auch
ziemlich verbreitet. Java zu können ist aber sicher kein Fehler.
Je nach Anwendungsgebiet bedingt, da jede Sprache ihr Spezialgebiet hat.
Was letztendlich aber wenig mit der Frage OOP zu tun hat, denn das ist
mittlerweile in allen drei Sprachen vorhanden.

Aber die Theorie, die bei OOP dahinter steckt lernt man meiner Meinung
nach am besten mit Java.
Post by Florian Diesch
Ist mit OOP ähnlich: Wenn du mal das Prinzip verstanden hast, kannst du
dich relativ schnell in eine neue Sprache einarbeiten.
Jep, wie bei allen Themen in der Programmierung, die Theorie ist immer
die selbe und nur Details der Sprache ändern sich (Java Schnittstellen,
C++ Mehrfachvererbung zum Beispiel).
Post by Florian Diesch
Dann schau dir mal was zum Thema "Entwurfsmuster" an; der Klassiker ist
"Design Patterns" von Gamma, Helm, Johnson und Vlissides. Es geht dabei
um Lösungsansätze für oft auftretende Probleme; ist am Anfang sicher
hilfreich um ein Gefühl dafür zu bekommen, wie man ein Problem mit OOP
angeht, und auch später als Ideengeber nützlich.
Wem das zu trocken ist, "Entwurfsmuster von Kopf bis Fuß" fand ich zu
dem Thema sehr angenehm zu lesen und vor allem aus dem Alltag gegriffene
Beispiele und damit alles anschaulich erklärt.
--
Mit freundlichen Grüßen,
Christoph Herrmann

http://dragonprojects.de/
Ingo Leschnewsky
2007-12-12 10:37:22 UTC
Permalink
Hallo Christoph!
Post by Christoph Herrmann
Post by Florian Diesch
Dann schau dir mal was zum Thema "Entwurfsmuster" an; der Klassiker ist
"Design Patterns" von Gamma, Helm, Johnson und Vlissides. Es geht dabei
um Lösungsansätze für oft auftretende Probleme; ist am Anfang sicher
hilfreich um ein Gefühl dafür zu bekommen, wie man ein Problem mit OOP
angeht, und auch später als Ideengeber nützlich.
Wem das zu trocken ist, "Entwurfsmuster von Kopf bis Fuß" fand ich zu
dem Thema sehr angenehm zu lesen und vor allem aus dem Alltag gegriffene
Beispiele und damit alles anschaulich erklärt.
Was ist mit "Objektorientierte Analyse & Design von Kopf bis Fuß"? Das
geht doch auch in die Richtung, oder?

Wobei ich sagen muß, daß mir "Java von Kopf bis Fuß" nicht besonders
gefällt (ich habe jetzt ungefähr zwei Drittel durchgelesen). Die
"Rätsel" finde ich größtenteils daneben, da wird in unkommentiertem Code
meistens nur ziemlich wirr mit Zahlen und Strings jongliert, und man
soll herausfinden, was genau passiert. Das ist eigentlich meine tägliche
Arbeit, wenn ich den Code von Kollegen debuggen muß. ;-)

Außerdem habe ich bislang noch keinen Überblick über die Möglichkeiten
von Java, und ich fürchte, den werde ich wider Erwarten auch am Ende des
Buches nicht haben, weil die einfach auf viele Aspekte gar nicht näher
eingehen, und dafür andere lang und breit behandeln.

Gibt es nicht so etwas wie den Kernigahn/Ritchie für Java bzw. OOP? ;-)
Den fand ich damals nämlich klasse. Der war gut zu lesen und lernen, und
gleichzeitig vollständig, d.h. man brauchte eigentlich kein zweites
Buch, weil da bereits alles über C drinstand. (Ich habe dennoch ein
zweites Buch über C, und das kann ich auch jedem empfehlen, der den
Kernighan/Ritchie studiert hat, und noch tiefer in die Materie
einsteigen möchte: "Expert C Programming" von Peter Van Der Linden.)

Gruß,
Ingo
Christoph Herrmann
2007-12-12 10:55:34 UTC
Permalink
Post by Ingo Leschnewsky
Was ist mit "Objektorientierte Analyse & Design von Kopf bis Fuß"? Das
geht doch auch in die Richtung, oder?
Wobei ich sagen muß, daß mir "Java von Kopf bis Fuß" nicht besonders
gefällt (ich habe jetzt ungefähr zwei Drittel durchgelesen). Die
"Rätsel" finde ich größtenteils daneben, da wird in unkommentiertem Code
Die Buchreihe ist nicht konservativer Natur sondern ist nach neueren
Lernstudien aufgebaut. Das ist einerseits gewöhnungsbedürftig,
allerdings empfinde ich es als sehr angenehm mit Pizzen oder Enten zu
jonglieren als mit Stacks zum Beispiel.
Post by Ingo Leschnewsky
meistens nur ziemlich wirr mit Zahlen und Strings jongliert, und man
soll herausfinden, was genau passiert. Das ist eigentlich meine tägliche
Arbeit, wenn ich den Code von Kollegen debuggen muß. ;-)
Wenn du sagst das Buch beschreibt das, was man im täglichen Leben machen
muss als Entwickler, dann würde ich doch behaupten es trifft genau den
Kern den man als Entwickler wissen muss, oder nicht? ;) Ich debugge in
der Regel nur meinen eigenen Code in der Firma, da bei uns jeder sein
Mist selbst korrigiert. :)

Ich kenne aus der Reihe jetzt nur das Buch über Entwurfsmuster, da sind
die Quellcodes natürlich wenig Kommentiert oder die Details der
einzelnen Funktionalitäten beschrieben. Es geht dort ja auch "nur" um
die Entwurfsmuster und deren Grundgedanken, nicht um Java direkt, dieses
dient nur als Hilfsmittel.
Post by Ingo Leschnewsky
Außerdem habe ich bislang noch keinen Überblick über die Möglichkeiten
von Java, und ich fürchte, den werde ich wider Erwarten auch am Ende des
Buches nicht haben, weil die einfach auf viele Aspekte gar nicht näher
eingehen, und dafür andere lang und breit behandeln.
Schau in die Java API[1] Dokumentation rein. Da hast ein Überblick über
alle Klassen und deren Funktionalitäten. Der Sinn des Buches besteht
eher darin die Syntax und die Prinzipien der Sprache zu erläutern und
nicht einen Überblick über alle Klassen zu geben. Deswegen nennt man es
auch Lehrbuch und nicht Referenz. :)

Es dürfte auch relativ schwer werden für ein Buch alle Aspekte und
Möglichkeiten von Java abzudecken. Dafür ist Java viel zu umfangreich
und in sehr vielen Gebieten beheimatet. Aus diesem Grunde ist es in der
Regel auch unsinnig bis unmöglich alles über Java zu wissen.

[1] http://java.sun.com/j2se/1.6.0/docs/api/
--
Mit freundlichen Grüßen,
Christoph Herrmann

http://dragonprojects.de/
Ingo Leschnewsky
2007-12-12 13:12:38 UTC
Permalink
Hallo Christoph!
Post by Christoph Herrmann
Post by Ingo Leschnewsky
Wobei ich sagen muß, daß mir "Java von Kopf bis Fuß" nicht besonders
gefällt (ich habe jetzt ungefähr zwei Drittel durchgelesen). Die
"Rätsel" finde ich größtenteils daneben, da wird in unkommentiertem Code
Die Buchreihe ist nicht konservativer Natur sondern ist nach neueren
Lernstudien aufgebaut. Das ist einerseits gewöhnungsbedürftig,
allerdings empfinde ich es als sehr angenehm mit Pizzen oder Enten zu
jonglieren als mit Stacks zum Beispiel.
Jein, für Anfänger mag das stimmen. Aber ich weiß seit meinen ersten
Programmen auf dem HP-25 (mit UPN und 49 Programmschritten) Anfang der
Siebziger, was ein Stack ist. Vermutlich habe ich mir nur ein für mich
ungeeignetes Lehrbuch gekauft, was angesichts des Preises allerdings
bedauerlich ist. Gibt es nicht sowas wie "Java für C-Programmierer"? Ich
habe nur "C für Java-Programmierer" gefunden. :)
Post by Christoph Herrmann
Post by Ingo Leschnewsky
meistens nur ziemlich wirr mit Zahlen und Strings jongliert, und man
soll herausfinden, was genau passiert. Das ist eigentlich meine
tägliche Arbeit, wenn ich den Code von Kollegen debuggen muß. ;-)
Wenn du sagst das Buch beschreibt das, was man im täglichen Leben machen
muss als Entwickler, dann würde ich doch behaupten es trifft genau den
Kern den man als Entwickler wissen muss, oder nicht? ;)
Wieder jein, denn ich möchte Programmbeispiele zum Lernen haben, wie sie
in der Praxis sein sollten, und nicht wie sie sind. s.u. ;-)
Post by Christoph Herrmann
Ich debugge in
der Regel nur meinen eigenen Code in der Firma, da bei uns jeder sein
Mist selbst korrigiert. :)
Schön wär's, aber bei uns kam man irgendwann auf die Idee, daß die
Projektentwickler effektiver an ihren Projekten arbeiten können, wenn
sie nicht immer wieder dadurch unterbrochen werden, daß sie Fehler in
ihrem alten Code suchen und beseitigen müssen. Außerdem mußte sich ja
auch jemand um den Code derjenigen kümmern, die inzwischen nicht mehr in
der Firma sind. Zu diesem Zweck gab es dann eine
"Maintenance-Abteilung", der ich seit einigen Jahren angehöre.

Leider wurde meine Anregung, die Entwickler zwischen Projekten und
Maintenance immer mal wieder wechseln zu lassen, nicht umgesetzt. Was
dazu führte, daß die Projektentwickler keine Ahnung davon haben, wieviel
und welchen Müll sie produzieren, und ich außerdem seit Jahren nicht
mehr in einem Projektteam mitgearbeitet habe. Daher bin ich auch froh,
daß ich ab April endlich die Gelegenheit habe, mal wieder was Neues zu
machen und mich weiterzuentwickeln. Ich strebe ja nicht nach einer
klassischen Karriere, bei der ich in der Hierarchie hinaufklettere,
sondern möchte mein Fachwissen und meine Erfahrungen ausbauen.
Post by Christoph Herrmann
Schau in die Java API[1] Dokumentation rein. Da hast ein Überblick über
alle Klassen und deren Funktionalitäten. Der Sinn des Buches besteht
eher darin die Syntax und die Prinzipien der Sprache zu erläutern und
nicht einen Überblick über alle Klassen zu geben. Deswegen nennt man es
auch Lehrbuch und nicht Referenz. :)
Der Kernighan/Ritchie ist halt beides. In der API-Dokumentation habe ich
auch schon geblättert, aber die hat kein System, ist sehr
unübersichtlich, und - gerade für Anfänger - zu knapp. Beispiel: Ich kam
neulich auf das Thema "Layout-Manager", die ich prinzipiell ja schon von
Tcl/Tk her kenne. Und da wollte ich dann mal vergleichen, was es so in
Java gibt. Aber ich habe bis jetzt noch keinen Überblick, welcher
Java-Layout-Manager wofür zu gebrauchen ist, weil es so viele sind, und
deren Beschreibungen (ohne Beispiele natürlich) in der API-Dokumentation
viel zu kurz sind.

Das heißt, ich müßte, um zu erfahren, was mich interessiert könnte, alle
mühsam ausprobieren, auch auf die Gefahr hin, daß ich das (gerade als
Anfänger) falsch oder unangemessen tue. Und genau dafür fände ich ein
Buch gut, welches an Beispielen unter anderem die verschiedenen
Layout-Manager vergleicht. (Mein Buch erwähnt und verwendet nur wenige
davon.)
Post by Christoph Herrmann
Es dürfte auch relativ schwer werden für ein Buch alle Aspekte und
Möglichkeiten von Java abzudecken. Dafür ist Java viel zu umfangreich
und in sehr vielen Gebieten beheimatet. Aus diesem Grunde ist es in der
Regel auch unsinnig bis unmöglich alles über Java zu wissen.
Vielleicht sollte ich dann doch besser C++ lernen? Denn ich habe
durchaus den Anspruch, Programmiersprachen vollständig zu beherrschen,
so wie das auch bei Pascal oder C der Fall war. Dazu muß ich vor allem
wissen, welche Möglichkeiten eine Sprache bietet, und welche nicht, also
einen kompletten Überblick haben, auch wenn ich nicht alles davon
benutzen und vertiefen werde.

Gruß,
Ingo
Christoph Herrmann
2007-12-12 13:28:53 UTC
Permalink
Post by Ingo Leschnewsky
Der Kernighan/Ritchie ist halt beides. In der API-Dokumentation habe ich
auch schon geblättert, aber die hat kein System, ist sehr
unübersichtlich, und - gerade für Anfänger - zu knapp. Beispiel: Ich kam
neulich auf das Thema "Layout-Manager", die ich prinzipiell ja schon von
Tcl/Tk her kenne. Und da wollte ich dann mal vergleichen, was es so in
Java gibt. Aber ich habe bis jetzt noch keinen Überblick, welcher
Java-Layout-Manager wofür zu gebrauchen ist, weil es so viele sind, und
deren Beschreibungen (ohne Beispiele natürlich) in der API-Dokumentation
viel zu kurz sind.
Die API Dokumentation sollte ausreichen um zu erfahren WIE man etwas
benutzt. WARUM man dies tut und WANN man etwas am besten einsetzt wird
man wohl nie genau wissen. :) Ich würde dir empfehlen ein allgemeines
Buch zu nehmen um die Syntax von Java und die grundlegenden
Eigenschaften der Sprache zu lernen und dann ein weiterführendes Buch in
eine der Themengebiete von Java.
Post by Ingo Leschnewsky
Vielleicht sollte ich dann doch besser C++ lernen? Denn ich habe
durchaus den Anspruch, Programmiersprachen vollständig zu beherrschen,
so wie das auch bei Pascal oder C der Fall war. Dazu muß ich vor allem
wissen, welche Möglichkeiten eine Sprache bietet, und welche nicht, also
einen kompletten Überblick haben, auch wenn ich nicht alles davon
benutzen und vertiefen werde.
Ich glaube kaum, dass jemand C++ vollständig mit allen möglichen
Bibliotheken beherrscht. C++ an sich ist relativ schlank genau wie Java
in den Grundeigenschaften und den grundlegendsten Funktionalitäten.

Allerdings macht Java die Klassenbibliothek recht mächtig und es wäre
unsinnig diese auswendig zu lernen. Warum solltest du als Entwickler
einer Anwendung wissen wie ein JSP (Java Server Page) funktioniert?
Warum solltest du dich als Webentwickler vertraut machen mit den
verschiedenen Layout Managern (höchstens du benutzt halt Frameworks die
eine GUI umbauen auf HTML...)? Genauso, warum solltest du in C++ die
DirectX Bibliothek auswendig kennen, wenn du eine Anwendung mit QT oder
den Widgets entwickelst.

Sinnlos eine Sprache mit all Ihren Möglichkeiten zu lernen. Dann hast in
paar Jahren vielleicht ein breites Wissen, dass nicht sehr tief geht. Da
würde ich doch eher raten ein tiefes Wissen über ein Themengebiet
anzueignen und den Rest vielleicht mal anzuschneiden. Bzw. lerne eine
Sprache zu benutzen und eigne dir tiefer gehendes Wissen an, wenn du es
benötigst.
--
Mit freundlichen Grüßen,
Christoph Herrmann

http://dragonprojects.de/
Ingo Leschnewsky
2007-12-12 14:20:24 UTC
Permalink
Hallo Christoph!
Post by Christoph Herrmann
Ich würde dir empfehlen ein allgemeines
Buch zu nehmen um die Syntax von Java und die grundlegenden
Eigenschaften der Sprache zu lernen und dann ein weiterführendes Buch in
eine der Themengebiete von Java.
Mit der Syntax habe ich überhaupt kein Problem, da sich diese bislang
nicht wesentlich von der C-Syntax zu unterscheiden scheint.

Und ich benötige wohl eher ein "OOP-Lehrbuch" als weitere Bücher zu Java...
Post by Christoph Herrmann
Ich glaube kaum, dass jemand C++ vollständig mit allen möglichen
Bibliotheken beherrscht.
Ich weiß es nicht, da ich halt auch nie C++ gelernt habe. Aber bei C
ging das (noch), da hatte ich über alle Standardbibliotheken wie stdio,
math, etc. einen guten Überblick.
Post by Christoph Herrmann
C++ an sich ist relativ schlank genau wie Java
in den Grundeigenschaften und den grundlegendsten Funktionalitäten.
Genau deswegen glaube ich, daß ich "Java an sich" bereits verstehe.
Post by Christoph Herrmann
Allerdings macht Java die Klassenbibliothek recht mächtig und es wäre
unsinnig diese auswendig zu lernen. Warum solltest du als Entwickler
einer Anwendung wissen wie ein JSP (Java Server Page) funktioniert?
Warum solltest du dich als Webentwickler vertraut machen mit den
verschiedenen Layout Managern (höchstens du benutzt halt Frameworks die
eine GUI umbauen auf HTML...)? Genauso, warum solltest du in C++ die
DirectX Bibliothek auswendig kennen, wenn du eine Anwendung mit QT oder
den Widgets entwickelst.
Sinnlos eine Sprache mit all Ihren Möglichkeiten zu lernen. Dann hast in
paar Jahren vielleicht ein breites Wissen, dass nicht sehr tief geht. Da
würde ich doch eher raten ein tiefes Wissen über ein Themengebiet
anzueignen und den Rest vielleicht mal anzuschneiden. Bzw. lerne eine
Sprache zu benutzen und eigne dir tiefer gehendes Wissen an, wenn du es
benötigst.
Du hast sicherlich Recht, nur weiß ich jetzt nicht so recht, wie ich
weitermachen soll. Privat benötige ich Java halt nicht für die kleinen
Progrämmchen, die ich ab und zu mal schreibe. Und was ich beruflich
brauchen werde, das weiß ich jetzt noch nicht.

Ich glaube, ich werde mir erstmal "Entwurfsmuster von Kopf bis Fuß"
bestellen. Auf jeden Fall danke ich Dir (und anderen) für die Anregungen
und Hinweise...

Gruß,
Ingo
Christoph Herrmann
2007-12-12 15:28:40 UTC
Permalink
Post by Ingo Leschnewsky
Ich weiß es nicht, da ich halt auch nie C++ gelernt habe. Aber bei C
ging das (noch), da hatte ich über alle Standardbibliotheken wie stdio,
math, etc. einen guten Überblick.
Mir geht es nicht um die Standardbibliotheken, sondern eher um alles
weitere was man benötigt um zum Beispiel eine GUI zu entwickeln. Diese
Bibliotheken sind in Java schon enthalten, deswegen bietet Java bei
weitem mehr Möglichkeiten von Haus aus. Aber man wird diese nie alle
benötigen, daher lernt man diese am besten, wenn man Sie braucht.
Post by Ingo Leschnewsky
Du hast sicherlich Recht, nur weiß ich jetzt nicht so recht, wie ich
weitermachen soll. Privat benötige ich Java halt nicht für die kleinen
Falls Übungen brauchst zum Thema OOP kann ich dir gerne welche geben. ;)
Post by Ingo Leschnewsky
Progrämmchen, die ich ab und zu mal schreibe. Und was ich beruflich
brauchen werde, das weiß ich jetzt noch nicht.
Du solltest zumindest wissen, in welche Richtung du dich grob
spezialisieren willst: Anwendungsentwicklung oder Web-/Serverentwicklung
sind denke ich die beiden größten Themengebiete bei Java. Graphisch im
Bereich Spiele oder Simulationen nimmt man ja eher etwas anderes. :)
Post by Ingo Leschnewsky
Ich glaube, ich werde mir erstmal "Entwurfsmuster von Kopf bis Fuß"
bestellen. Auf jeden Fall danke ich Dir (und anderen) für die Anregungen
und Hinweise...
Das Buch erklärt aber weniger die Prinzipien von OOP, sondern wie man
damit am elegantesten umgeht in Fällen, die man öfters benötigt.

Vielleicht hilft dir folgendes Openbook da eher weiter:
http://www.galileocomputing.de/openbook/oo/
--
Mit freundlichen Grüßen,
Christoph Herrmann

http://dragonprojects.de/
Ingo Leschnewsky
2007-12-12 16:02:53 UTC
Permalink
Hallo Christoph!
Post by Christoph Herrmann
Du solltest zumindest wissen, in welche Richtung du dich grob
spezialisieren willst: Anwendungsentwicklung oder Web-/Serverentwicklung
sind denke ich die beiden größten Themengebiete bei Java. Graphisch im
Bereich Spiele oder Simulationen nimmt man ja eher etwas anderes. :)
Also, Anwendungsentwicklung interessiert mich eigentlich mehr, aber ich
bin da recht offen für alles mögliche. Viel wichtiger als das ist mir,
daß ich mich diesmal auch für das "Produkt" bzw. die Themen der Branche
interessiere, was im Moment leider nicht der Fall ist.

Graphik interessiert mich auch sehr, nur habe ich damit noch überhaupt
keine Erfahrung (außer ein bißchen Povray und Fraktale). Ich sehe mich
auch nicht als Möchtegern-Graphikdesigner, würde aber gerne die Ideen
der Designer in Code umsetzen.
Post by Christoph Herrmann
Post by Ingo Leschnewsky
Ich glaube, ich werde mir erstmal "Entwurfsmuster von Kopf bis Fuß"
bestellen. Auf jeden Fall danke ich Dir (und anderen) für die
Anregungen und Hinweise...
Das Buch erklärt aber weniger die Prinzipien von OOP, sondern wie man
damit am elegantesten umgeht in Fällen, die man öfters benötigt.
http://www.galileocomputing.de/openbook/oo/
Ich werde mal reinschauen. Aber ich habe mich ja, ausgelöst durch diesen
Thread, vorhin mal etwas über Entwurfsmuster informiert. Das ist ja eher
Softwarearchitektur als Programmierung. Um es mal am Beispiel einer
Baustelle zu erläutern: Ich sehe mich weniger in der Rolle eines
Architekten, der ein Gebäude plant, sondern vielmehr als Polier, der mit
seiner Mannschaft versuchen muß, die Ideen des Architekten aus der
Theorie in die Praxis umzusetzen. Ich beschäftige mich daher weniger mit
Entwurfsmustern, als vielmehr mit Idiomen
(http://de.wikipedia.org/wiki/Idiom_%28Softwaretechnik%29).

Gruß,
Ingo

Ingo Leschnewsky
2007-12-12 10:12:20 UTC
Permalink
Hallo Florian!
Post by Florian Diesch
Momentan sieht es ja nicht so ganz schlecht aus für Programmierer...
Sehe ich auch so. Ich bin nur leider schon etwas älter, und habe in den
letzten sechs Jahren auch nichts Neues hinzulernen können. Daher muß ich
mich halt ein bißchen "fortbilden".
Post by Florian Diesch
Post by Ingo Leschnewsky
Und ich vermute, Java ist zur Zeit am meisten gefragt.
Kommt wohl auch auf den Anwendungsbereich an, C++ und PHP sind auch
ziemlich verbreitet. Java zu können ist aber sicher kein Fehler.
Nunja, PHP habe ich zwar nie gelernt, aber schon oft in fremdem Code
herumgewühlt. Das ist von der Syntax her gesehen auch kein Problem. Ich
habe halt nur keinen Überblick über die Möglichkeiten der Sprache. Aber
das ist für meinen Geschmack auch zu spezifisch in Richtung Web.

C++ könnte ich auch mal wieder versuchen zu lernen. Das war bei mir nach
Java gleich die zweite Wahl. Mein Manko bei beiden Sprachen ist bloß,
daß ich mich mit null Jahren Berufserfahrung bewerben muß, auch wenn ich
die eine oder andere in ein paar Monaten gelernt haben werde.
Post by Florian Diesch
Dann schau dir mal was zum Thema "Entwurfsmuster" an; der Klassiker ist
"Design Patterns" von Gamma, Helm, Johnson und Vlissides. Es geht dabei
um Lösungsansätze für oft auftretende Probleme; ist am Anfang sicher
hilfreich um ein Gefühl dafür zu bekommen, wie man ein Problem mit OOP
angeht, und auch später als Ideengeber nützlich.
Danke, das werde ich mir mal anschauen.

Gruß,
Ingo
Jochen Theodorou
2007-12-06 17:37:58 UTC
Permalink
Post by Ingo Leschnewsky
[...]
Ich programmiere ja nun schon länger als 30 Jahre (von Taschenrechnern
über BASIC, PASCAL, C, Assembler, Tcl/Tk, etc.), aber bei Java habe ich
nicht den Eindruck, daß das unter dem Motto "keep it simple" steht. ;-)
Java *ist* oft umständlicher als es gut ist.
Post by Ingo Leschnewsky
Wenn ich z.B. (was ja öfter mal vorkommt) nur eine Datei öffnen möchte,
dann mache ich das in C oder PASCAL mit einem einzigen Befehl, dem ich
dem Dateinamen bzw. Pfad übergebe. Danach kann ich aus der Datei mittels
des Handles, welches ich beim Öffnen erhalte, lesen. In Java habe ich
gerade gelernt, daß ich drei Schritte dazu brauche: Einmal ein
Dateiobjekt anhand des Namens erzeugen, dann damit ein weiteres Objekt
verbinden, und mit diesem wiederum einen "BufferedReader", um dann
endlich etwas aus der Datei lesen zu können.
Der einzige Vorteil, den ich bei der OOP (gegenüber C, nicht jedoch
aber... jetzt nicht den Fehler machen und JAVA mit OOP gleichsetzen.
Java ist eine objektorientierte Sprache, aber nicht unbedingt in allen
Aspekten und für jeden Geschmack die schönste.

Gruss theo
--
Jochen "blackdrag" Theodorou
The Groovy Project Tech Lead (http://groovy.codehaus.org)
http://blackdragsview.blogspot.com/
http://www.g2one.com/
Ingo Leschnewsky
2007-12-07 10:32:26 UTC
Permalink
Hallo Jochen!
Post by Jochen Theodorou
aber... jetzt nicht den Fehler machen und JAVA mit OOP gleichsetzen.
Java ist eine objektorientierte Sprache, aber nicht unbedingt in allen
Aspekten und für jeden Geschmack die schönste.
Sag das mal meinem zukünftigen Arbeitgeber. ;-)

Gruß,
Ingo
Niels Braczek
2007-12-06 20:09:23 UTC
Permalink
Post by Ingo Leschnewsky
Post by Niels Braczek
Das mag daran liegen, dass bei einfachen Problemstellungen idR die
prozedurale Programmierung effizienter ist. OO kann ihre Stärken erst
bei hinreichender Komplexität ausspielen.
Wenn man sich also konsequent an das Motto "keep it simple" hält, sollte
man OOP nicht benötigen... ;-)
Richtig. Manchmal braucht man aber mehr Funktionalität als ein "Hello
World" oder ein Sieb des Erathostenes.
Post by Ingo Leschnewsky
Und die zusätzliche Sicherheit bei der Speicherverwaltung wird dadurch
erkauft, daß keine Speicherarithmetik mehr möglich ist. Auch habe ich in
JAVA bislang vergebens nach einem "free"-Befehl gesucht, um dem Garbage
Collector die Arbeit zu erleichtern. :)
Man braucht ja auch keine Speicherarithmetik. Die setzt nämlich Kenntnis
des zugrunde liegenden (Hardware-, Operating-) Systems voraus. Eines der
wichtigsten Pronzipien in OO ist jedoch, dass jede Klasse nur das kennt,
wöfür sie zuständig ist und (möglichst) keine Annahmen über die
restliche Welt macht. Die Hardware-Nähe, die du von C gewöhnt bist,
solltest du *komplett* vergessen. Das geht dich mit OOP nichts mehr an.

Denk mal an streams. Die können von der Tastatur kommen, aus einer
Datei, über HTTP, von der seriellen Schnittstelle...
Die sind technisch völlig unterschiedlich anzusprechen (betrachte hier
die Assembler-Ebene). Schon in C ist das objektorientiert gelöst, weil
dir hier die Klasse "stream" zur Verfügung steht, mit der du völlig
transparent auf die Daten zugreifen kannst, ohne dich um TCP/IP, Joliet
oder sonstwas kümmern zu müssen. Die Schnittstelle ist vereinheitlicht
und du kannst aus jedem beliebigen Stream mit fgetc() oder fgets() Daten
lesen. *Das* ist OO. Die Notation ( fgetc(stream) vs. Stream->getc ) ist
dabei völlig unerheblich.
Die prozedurale Lösung wären getrennte Funktionen für jeden Streamtyp:
filegetc(), keybgetc(), httpgetc() usw.
Daran ist zu erkennen, welchen immensen Vorteil OO bietet. Dieser
Vorteil ist so groß, dass (fast) alle prozeduralen Sprachen zumindest im
I/O-Bereich OO verwenden.

MfG
Niels
--
| http://www.kolleg.de · Das Portal der Kollegs in Deutschland |
| http://www.bsds.de · BSDS Braczek Software- und DatenSysteme |
| Webdesign · Webhosting · e-Commerce · Joomla! Content Management |
------------------------------------------------------------------
Christoph Herrmann
2007-12-06 22:49:54 UTC
Permalink
Post by Niels Braczek
Man braucht ja auch keine Speicherarithmetik. Die setzt nämlich Kenntnis
des zugrunde liegenden (Hardware-, Operating-) Systems voraus. Eines der
wichtigsten Pronzipien in OO ist jedoch, dass jede Klasse nur das kennt,
wöfür sie zuständig ist und (möglichst) keine Annahmen über die
restliche Welt macht. Die Hardware-Nähe, die du von C gewöhnt bist,
solltest du *komplett* vergessen. Das geht dich mit OOP nichts mehr an.
Das hat absolut nichts mit OOP wirklich zu tun. In C++ hast du nämlich
OOP und sehr wohl Speicherarethmik, weil es ein Bestandteil der Sprache
ist. Das wäre genau so wie wenn du sagst "meine Klasse muss nur PDF
ausgeben können und nicht wissen was eine Schleife ist". Dass bei Java
das ganze mehr außer Acht lassen kannst ist rein wegen der Sprache so,
nicht wegen den Prinzipien der OOP.
--
Mit freundlichen Grüßen,
Christoph Herrmann

http://dragonprojects.de/
Niels Braczek
2007-12-07 00:54:21 UTC
Permalink
Post by Christoph Herrmann
Post by Niels Braczek
Man braucht ja auch keine Speicherarithmetik. Die setzt nämlich Kenntnis
des zugrunde liegenden (Hardware-, Operating-) Systems voraus. Eines der
wichtigsten Pronzipien in OO ist jedoch, dass jede Klasse nur das kennt,
wöfür sie zuständig ist und (möglichst) keine Annahmen über die
restliche Welt macht. Die Hardware-Nähe, die du von C gewöhnt bist,
solltest du *komplett* vergessen. Das geht dich mit OOP nichts mehr an.
Das hat absolut nichts mit OOP wirklich zu tun. In C++ hast du nämlich
OOP und sehr wohl Speicherarethmik, weil es ein Bestandteil der Sprache
ist. Das wäre genau so wie wenn du sagst "meine Klasse muss nur PDF
ausgeben können und nicht wissen was eine Schleife ist". Dass bei Java
das ganze mehr außer Acht lassen kannst ist rein wegen der Sprache so,
nicht wegen den Prinzipien der OOP.
Ich habe mich wohl nicht verständlich genug ausgedrückt. Natürlich wird
man auf der untersten Ebene zur Implementierung von zB. Arrays
Speicherarithmetik benötigen. Auf der Ebene, auf der OOP anfängt Sinn zu
machen, brauchst man das aber nicht mehr.
Du kannst ja auch verdauen, denken und dich bewegen, ohne die dafür
unabdingbaren biochemischen Grundlagen kennen zu müssen.

MfG
Niels
--
| http://www.kolleg.de · Das Portal der Kollegs in Deutschland |
| http://www.bsds.de · BSDS Braczek Software- und DatenSysteme |
| Webdesign · Webhosting · e-Commerce · Joomla! Content Management |
------------------------------------------------------------------
Ingo Leschnewsky
2007-12-07 10:55:19 UTC
Permalink
Hallo Niels!
Post by Niels Braczek
Du kannst ja auch verdauen, denken und dich bewegen, ohne die dafür
unabdingbaren biochemischen Grundlagen kennen zu müssen.
Aber wenn Du sie kennst, kann das manchmal von unschätzbarem Vorteil sein...

Gruß,
Ingo
Niels Braczek
2007-12-07 12:53:30 UTC
Permalink
Post by Ingo Leschnewsky
Post by Niels Braczek
Du kannst ja auch verdauen, denken und dich bewegen, ohne die dafür
unabdingbaren biochemischen Grundlagen kennen zu müssen.
Aber wenn Du sie kennst, kann das manchmal von unschätzbarem Vorteil sein...
Sicher, aber nicht für die genannten Aufgaben. "Nahrung auswählen" zB.
habe ich absichtlich nicht genannt ;-)

MfG
Niels
--
| http://www.kolleg.de · Das Portal der Kollegs in Deutschland |
| http://www.bsds.de · BSDS Braczek Software- und DatenSysteme |
| Webdesign · Webhosting · e-Commerce · Joomla! Content Management |
------------------------------------------------------------------
Florian Diesch
2007-12-08 03:33:26 UTC
Permalink
Post by Niels Braczek
Post by Christoph Herrmann
Post by Niels Braczek
Man braucht ja auch keine Speicherarithmetik. Die setzt nämlich Kenntnis
des zugrunde liegenden (Hardware-, Operating-) Systems voraus. Eines der
wichtigsten Pronzipien in OO ist jedoch, dass jede Klasse nur das kennt,
wöfür sie zuständig ist und (möglichst) keine Annahmen über die
restliche Welt macht. Die Hardware-Nähe, die du von C gewöhnt bist,
solltest du *komplett* vergessen. Das geht dich mit OOP nichts mehr an.
Das halte ich für falsch.
Post by Niels Braczek
Post by Christoph Herrmann
Das hat absolut nichts mit OOP wirklich zu tun. In C++ hast du nämlich
OOP und sehr wohl Speicherarethmik, weil es ein Bestandteil der Sprache
ist. Das wäre genau so wie wenn du sagst "meine Klasse muss nur PDF
ausgeben können und nicht wissen was eine Schleife ist". Dass bei Java
das ganze mehr außer Acht lassen kannst ist rein wegen der Sprache so,
nicht wegen den Prinzipien der OOP.
Ich habe mich wohl nicht verständlich genug ausgedrückt. Natürlich wird
man auf der untersten Ebene zur Implementierung von zB. Arrays
Speicherarithmetik benötigen. Auf der Ebene, auf der OOP anfängt Sinn zu
machen, brauchst man das aber nicht mehr.
OOP macht doch auch auf dieser untersten Ebene Sinn, z.B. wenn ich eine
array-artige Datenstruktur für verschiedene Operationen optimieren will,
z.B. dynamischen Größenänderung, Zugriff auf einzelne Elemente,
Zusammenfügen, Auftrennen, Suchen, Sortieren, ...


Und auch bei prozeduraler Programmierung hat man oft einerseits
Low-Level-Code, und andererseits eine höhere Abstraktionsebene, die auf
diesen Low-Level-Code aufsetzt.


Florian
--
<http://www.florian-diesch.de/>
-----------------------------------------------------------------------
** Hi! I'm a signature virus! Copy me into your signature, please! **
-----------------------------------------------------------------------
Ingo Leschnewsky
2007-12-07 10:53:34 UTC
Permalink
Hallo Niels!
Post by Niels Braczek
Man braucht ja auch keine Speicherarithmetik. Die setzt nämlich Kenntnis
des zugrunde liegenden (Hardware-, Operating-) Systems voraus.
Ähm, genau diese Kenntnisse habe ich doch aber, und zwar gerade auch
deshalb, *weil* ich mich damit zwecks Programmierung befassen mußte. s.u.
Post by Niels Braczek
Eines der
wichtigsten Pronzipien in OO ist jedoch, dass jede Klasse nur das kennt,
wöfür sie zuständig ist und (möglichst) keine Annahmen über die
restliche Welt macht. Die Hardware-Nähe, die du von C gewöhnt bist,
solltest du *komplett* vergessen. Das geht dich mit OOP nichts mehr an.
Das sagst Du so einfach. Da steckt bei mir aber jahrzehntelange
Erfahrung im EDV-Bereich dahinter, und das ist gerade das, was ich zur
Zeit bei meinen Bewerbungen anführen kann. Und es ist ja auch nicht so,
daß es die Hardware nicht mehr gäbe, und Prozessoren auf einmal
abstrakte Hochsprachen verstünden.
Post by Niels Braczek
Denk mal an streams. Die können von der Tastatur kommen, aus einer
Datei, über HTTP, von der seriellen Schnittstelle...
Die sind technisch völlig unterschiedlich anzusprechen (betrachte hier
die Assembler-Ebene).
Jo, das ist aber Sache des jeweiligen Betriebssystems, dafür Interfaces
zur Verfügung zu stellen. Je einheitlicher, desto besser.
Post by Niels Braczek
Schon in C ist das objektorientiert gelöst, weil
dir hier die Klasse "stream" zur Verfügung steht, mit der du völlig
transparent auf die Daten zugreifen kannst, ohne dich um TCP/IP, Joliet
oder sonstwas kümmern zu müssen.
Nein, das gibt es erst seit C++. C (ANSI oder K&R) kennt so etwas noch
nicht.
Post by Niels Braczek
Die Schnittstelle ist vereinheitlicht
und du kannst aus jedem beliebigen Stream mit fgetc() oder fgets() Daten
lesen. *Das* ist OO.
Es wäre aber meiner Meinung nach gerade eine Aufgabe des
Betriebssystems, die Schnittstellen zu vereinheitlichen.
Post by Niels Braczek
Die Notation ( fgetc(stream) vs. Stream->getc ) ist
dabei völlig unerheblich.
filegetc(), keybgetc(), httpgetc() usw.
Daran ist zu erkennen, welchen immensen Vorteil OO bietet. Dieser
Vorteil ist so groß, dass (fast) alle prozeduralen Sprachen zumindest im
I/O-Bereich OO verwenden.
Man könnte auch in prozeduraler Programmierung alles mit einer einzigen
Funktion erschlagen, die halt zur Laufzeit nur unterschiedliche
Parameter übergeben bekommt.

Ich gewinne allerdings mehr und mehr den Eindruck, daß mit wachsender
Abstrahierung gleichzeitig die Kenntnisse der Grundlagen schrumpfen. So
wie die "Mausschubser" irgendwann vergessen haben, daß es da ja auch
noch einen DIR- bzw. ls-Befehl gibt. Was man nicht braucht, lernt man
auch nicht mehr. Das ist ja erstmal nicht weiter schlimm - bis man es
eines Tages doch mal wieder braucht, weil es natürlich nach wie vor zu
den Grundlagen unterhalb der abstrakten Schichten gehört...

Gruß,
Ingo
Niels Braczek
2007-12-07 13:04:33 UTC
Permalink
Post by Ingo Leschnewsky
Post by Niels Braczek
Man braucht ja auch keine Speicherarithmetik. Die setzt nämlich Kenntnis
des zugrunde liegenden (Hardware-, Operating-) Systems voraus.
Ähm, genau diese Kenntnisse habe ich doch aber, und zwar gerade auch
deshalb, *weil* ich mich damit zwecks Programmierung befassen mußte. s.u.
Das spielt aber für OOP keine Rolle. OOP spielt sich idR auf einer
höheren Ebene ab.
Post by Ingo Leschnewsky
Post by Niels Braczek
Eines der
wichtigsten Prinzipien in OO ist jedoch, dass jede Klasse nur das kennt,
wöfür sie zuständig ist und (möglichst) keine Annahmen über die
restliche Welt macht. Die Hardware-Nähe, die du von C gewöhnt bist,
solltest du *komplett* vergessen. Das geht dich mit OOP nichts mehr an.
Das sagst Du so einfach. Da steckt bei mir aber jahrzehntelange
Erfahrung im EDV-Bereich dahinter, und das ist gerade das, was ich zur
Zeit bei meinen Bewerbungen anführen kann. Und es ist ja auch nicht so,
daß es die Hardware nicht mehr gäbe, und Prozessoren auf einmal
abstrakte Hochsprachen verstünden.
Ist ja auch unbenommen. Dafür verwendet man dann aber der Hardware nahe
Sprachen und nicht OOP.
Post by Ingo Leschnewsky
Post by Niels Braczek
Denk mal an streams. Die können von der Tastatur kommen, aus einer
Datei, über HTTP, von der seriellen Schnittstelle...
Die sind technisch völlig unterschiedlich anzusprechen (betrachte hier
die Assembler-Ebene).
Jo, das ist aber Sache des jeweiligen Betriebssystems, dafür Interfaces
zur Verfügung zu stellen. Je einheitlicher, desto besser.
Das ist IMHO das Wesen der OOP.
Post by Ingo Leschnewsky
Post by Niels Braczek
Die Schnittstelle ist vereinheitlicht
und du kannst aus jedem beliebigen Stream mit fgetc() oder fgets() Daten
lesen. *Das* ist OO.
Es wäre aber meiner Meinung nach gerade eine Aufgabe des
Betriebssystems, die Schnittstellen zu vereinheitlichen.
Richtig. Und OOP geht noch weiter. Die zur Verfügung stehenden
Klassenbibliotheken abstrahieren noch weiter. Im Idealfall ist es deinem
Programm egal, ob die Ausgabe auf der Konsole erfolgt, in einer Webseite
mündet oder als PDF-Datei ausgeliefert wird. Wesentliche Teile des
programms werden davon überhaupt nichts wissen (denn darum kümmert sich
ein spezielles Objekt, der Renderer).
Post by Ingo Leschnewsky
Man könnte auch in prozeduraler Programmierung alles mit einer einzigen
Funktion erschlagen, die halt zur Laufzeit nur unterschiedliche
Parameter übergeben bekommt.
Natürlich. In dieser Funktion hast du dann ein switch mit 20 cases und
viel redundantem Code. Oder du hast 20 Klassen, die sich über Vererbung
den gemeinsamen Code teilen.
Post by Ingo Leschnewsky
Ich gewinne allerdings mehr und mehr den Eindruck, daß mit wachsender
Abstrahierung gleichzeitig die Kenntnisse der Grundlagen schrumpfen. So
wie die "Mausschubser" irgendwann vergessen haben, daß es da ja auch
noch einen DIR- bzw. ls-Befehl gibt. Was man nicht braucht, lernt man
auch nicht mehr.
Korrekt. Das ist Sinn und Zweck der Geschichte. Durch die Lösung von
diesen Grundlagen ist der Kopf frei für das eigentliche Problem.
Ich kämpfe mich auch nicht mehr mit Feuerstein und Pyrit ab, sondern
nehme einfach ein Feuerzeug.
Post by Ingo Leschnewsky
Das ist ja erstmal nicht weiter schlimm - bis man es
eines Tages doch mal wieder braucht, weil es natürlich nach wie vor zu
den Grundlagen unterhalb der abstrakten Schichten gehört...
Das ist dann eine ganz andere Baustelle. Es wird sicher darin enden,
dass kaum jemand *beides* kann. Darin liegt aber nichts Falsches.

MfG
Niels
--
| http://www.kolleg.de · Das Portal der Kollegs in Deutschland |
| http://www.bsds.de · BSDS Braczek Software- und DatenSysteme |
| Webdesign · Webhosting · e-Commerce · Joomla! Content Management |
------------------------------------------------------------------
Ingo Leschnewsky
2007-12-07 13:46:21 UTC
Permalink
Hallo Niels!
Post by Niels Braczek
Das spielt aber für OOP keine Rolle. OOP spielt sich idR auf einer
höheren Ebene ab.
Da hast Du wohl Recht.
Post by Niels Braczek
Ist ja auch unbenommen. Dafür verwendet man dann aber der Hardware nahe
Sprachen und nicht OOP.
Genau. Jetzt müßte ich nur noch 'nen Job in dem Bereich finden, dann
bräuchte ich kein JAVA zu lernen... ;-)
Post by Niels Braczek
Richtig. Und OOP geht noch weiter. Die zur Verfügung stehenden
Klassenbibliotheken abstrahieren noch weiter. Im Idealfall ist es deinem
Programm egal, ob die Ausgabe auf der Konsole erfolgt, in einer Webseite
mündet oder als PDF-Datei ausgeliefert wird. Wesentliche Teile des
programms werden davon überhaupt nichts wissen (denn darum kümmert sich
ein spezielles Objekt, der Renderer).
Solange man sich auf diesen Renderer verlassen kann, ist ja alles ok...
Post by Niels Braczek
Post by Ingo Leschnewsky
Man könnte auch in prozeduraler Programmierung alles mit einer einzigen
Funktion erschlagen, die halt zur Laufzeit nur unterschiedliche
Parameter übergeben bekommt.
Natürlich. In dieser Funktion hast du dann ein switch mit 20 cases und
viel redundantem Code. Oder du hast 20 Klassen, die sich über Vererbung
den gemeinsamen Code teilen.
Redundant? Wenn ich einen neuen Fall hinzubekomme, dann versuche ich
entweder, eine bereits vorhandene Routine aufzurufen (die bereits einen
oder mehrere der vorhandenen Fälle "handlet"), oder ich muß halt eine
neue schreiben. So wie ich auch in einer neuen Klasse eine geerbte
Methode durch eine neue überladen oder überschreiben müßte.

Ich packe ja dann nicht sämtlichen Code in diese eine case-Anweisung,
sondern schreibe wiederverwendbaren Code in Form von Funktionen, die
eventuell sogar noch in Module ausgelagert werden.
Post by Niels Braczek
Korrekt. Das ist Sinn und Zweck der Geschichte. Durch die Lösung von
diesen Grundlagen ist der Kopf frei für das eigentliche Problem.
Ich kämpfe mich auch nicht mehr mit Feuerstein und Pyrit ab, sondern
nehme einfach ein Feuerzeug.
Das tue ich auch, schon weil ich von Natur aus faul bin. Aber ich muß
gerade an die Geschichte von dem Studenten denken (stand mal bei SPIEGEL
Online), der durch eine Prüfung gefallen war, weil er beim Verlassen der
Wohnung in der Eile statt des Taschenrechners eine Fernbedienung
eingepackt hatte. Das Traurige an der Geschichte war für mich, daß es
dieser Student anscheinend für selbstverständlich hielt, daß man
deswegen durchfällt - weil er offensichtlich nicht mal auf den Gedanken
kam, daß man auch im Kopf beziehungsweise auf einem Blatt Papier rechnen
kann, wenn es mal sein muß...
Post by Niels Braczek
Post by Ingo Leschnewsky
Das ist ja erstmal nicht weiter schlimm - bis man es
eines Tages doch mal wieder braucht, weil es natürlich nach wie vor zu
den Grundlagen unterhalb der abstrakten Schichten gehört...
Das ist dann eine ganz andere Baustelle. Es wird sicher darin enden,
dass kaum jemand *beides* kann. Darin liegt aber nichts Falsches.
Habe ich auch nicht behauptet. Aber ich behaupte, daß jeder, der auf der
Kommandozeile arbeiten kann, keine Problem damit hätte, auch mal die
Maus zu benutzen. Umgekehrt aber schon...

Gruß,
Ingo
Niels Braczek
2007-12-07 17:19:22 UTC
Permalink
Post by Ingo Leschnewsky
Post by Niels Braczek
Richtig. Und OOP geht noch weiter. Die zur Verfügung stehenden
Klassenbibliotheken abstrahieren noch weiter. Im Idealfall ist es deinem
Programm egal, ob die Ausgabe auf der Konsole erfolgt, in einer Webseite
mündet oder als PDF-Datei ausgeliefert wird. Wesentliche Teile des
programms werden davon überhaupt nichts wissen (denn darum kümmert sich
ein spezielles Objekt, der Renderer).
Solange man sich auf diesen Renderer verlassen kann, ist ja alles ok...
Natürlich. Aufgrund der Kapselung kann der Renderer getrennt getestet
und einsatzfähig gemacht werden. Außer der vereinbarten Schnittstelle
muss der nichts vom Rest des Projektes wissen.
Post by Ingo Leschnewsky
Post by Niels Braczek
Post by Ingo Leschnewsky
Man könnte auch in prozeduraler Programmierung alles mit einer einzigen
Funktion erschlagen, die halt zur Laufzeit nur unterschiedliche
Parameter übergeben bekommt.
Natürlich. In dieser Funktion hast du dann ein switch mit 20 cases und
viel redundantem Code. Oder du hast 20 Klassen, die sich über Vererbung
den gemeinsamen Code teilen.
Redundant? Wenn ich einen neuen Fall hinzubekomme, dann versuche ich
entweder, eine bereits vorhandene Routine aufzurufen (die bereits einen
oder mehrere der vorhandenen Fälle "handlet"), oder ich muß halt eine
neue schreiben. So wie ich auch in einer neuen Klasse eine geerbte
Methode durch eine neue überladen oder überschreiben müßte.
Angenommen, du verarbeitest ursprünglich nur Säugetiere. Um sie zu
bewegen (mit eingebauter Prüfung, ob diese Bewegung möglich ist oder
verweigert wird), hast du eine Funktion move().
Jetzt kommen aus irgendeinem unerfindlichen Grunde Insekten hinzu, die
durch Flugfähigkeit andere bewegungsmuster haben.
Du brauchst dann eine Funktion insectmove() und aus move() wird der
Inlinedokumentaion wegen mammalmove(). Jeder Code, der ein Viech bewegen
will, muss dann auf die neue Situation angepasst werden.

Mit OOP implementiert das Insekt einfach eine eigene Methode move().
Alle Teile des Programmes, die ein Viech bewegen können sollen,
funktionieren sofort ohne Änderung nun auch mit Insekten.
Post by Ingo Leschnewsky
Ich packe ja dann nicht sämtlichen Code in diese eine case-Anweisung,
sondern schreibe wiederverwendbaren Code in Form von Funktionen, die
eventuell sogar noch in Module ausgelagert werden.
Das ist im Ansatz schon OOP. Nur ohne dessen Nutzen (s.o.)
Post by Ingo Leschnewsky
Post by Niels Braczek
Das ist dann eine ganz andere Baustelle. Es wird sicher darin enden,
dass kaum jemand *beides* kann. Darin liegt aber nichts Falsches.
Habe ich auch nicht behauptet. Aber ich behaupte, daß jeder, der auf der
Kommandozeile arbeiten kann, keine Problem damit hätte, auch mal die
Maus zu benutzen. Umgekehrt aber schon...
Dein Fall widerlegt das doch wohl.

MfG
Niels
--
| http://www.kolleg.de · Das Portal der Kollegs in Deutschland |
| http://www.bsds.de · BSDS Braczek Software- und DatenSysteme |
| Webdesign · Webhosting · e-Commerce · Joomla! Content Management |
------------------------------------------------------------------
Florian Diesch
2007-12-08 04:09:27 UTC
Permalink
Post by Ingo Leschnewsky
Post by Niels Braczek
Natürlich. In dieser Funktion hast du dann ein switch mit 20 cases und
viel redundantem Code. Oder du hast 20 Klassen, die sich über Vererbung
den gemeinsamen Code teilen.
Redundant? Wenn ich einen neuen Fall hinzubekomme, dann versuche ich
entweder, eine bereits vorhandene Routine aufzurufen (die bereits
einen oder mehrere der vorhandenen Fälle "handlet"), oder ich muß halt
eine neue schreiben. So wie ich auch in einer neuen Klasse eine
geerbte Methode durch eine neue überladen oder überschreiben müßte.
Ich packe ja dann nicht sämtlichen Code in diese eine case-Anweisung,
sondern schreibe wiederverwendbaren Code in Form von Funktionen, die
eventuell sogar noch in Module ausgelagert werden.
Der Vorteil von OOP ist IMHO auch eher, dass du keine case-Anweisung
mehr hast, die du anpassen musst.
Post by Ingo Leschnewsky
Das tue ich auch, schon weil ich von Natur aus faul bin. Aber ich muß
gerade an die Geschichte von dem Studenten denken (stand mal bei
SPIEGEL Online), der durch eine Prüfung gefallen war, weil er beim
Verlassen der Wohnung in der Eile statt des Taschenrechners eine
Fernbedienung eingepackt hatte. Das Traurige an der Geschichte war für
mich, daß es dieser Student anscheinend für selbstverständlich hielt,
daß man deswegen durchfällt - weil er offensichtlich nicht mal auf den
Gedanken kam, daß man auch im Kopf beziehungsweise auf einem Blatt
Papier rechnen kann, wenn es mal sein muß...
Manchmal ist es besser durchzufallen, als eine schlechtere Note zu
bekommen, weil man zu viel Zeit mit Rechnen verloren hat.
Post by Ingo Leschnewsky
Post by Niels Braczek
Das ist ja erstmal nicht weiter schlimm - bis man es eines Tages
doch mal wieder braucht, weil es natürlich nach wie vor zu den
Grundlagen unterhalb der abstrakten Schichten gehört...
Ich halte es für sehr sinnvoll, sich mal verschiedene
Programmiersprachen und -paradigmen anzuschauen. Viele Ideen lassen sich
nämlich auch in anderen Sprachen sinnvoll nutzen, obwohl sie da erst mal
nicht so naheliegend sind.
Post by Ingo Leschnewsky
Post by Niels Braczek
Das ist dann eine ganz andere Baustelle. Es wird sicher darin enden,
dass kaum jemand *beides* kann. Darin liegt aber nichts Falsches.
Habe ich auch nicht behauptet. Aber ich behaupte, daß jeder, der auf
der Kommandozeile arbeiten kann, keine Problem damit hätte, auch mal
die Maus zu benutzen. Umgekehrt aber schon...
Wer nie eine Maus benutzt hat, braucht erst mal einige Zeit, bis er
damit umgehen kann. In der Zeit kann sich auch jemand, der noch nie mit
einer Kommandozeile gearbeitet hat, mit einer passenden Befehlsliste
einarbeiten. Aber für beide dauert es eine ganze Weile, bis sie mit
der jeweiligen Schnittstelle wirklich effektiv arbeiten können.



Florian
--
<http://www.florian-diesch.de/>
-----------------------------------------------------------------------
** Hi! I'm a signature virus! Copy me into your signature, please! **
-----------------------------------------------------------------------
Stefan Reuther
2007-12-07 07:16:12 UTC
Permalink
Post by Ingo Leschnewsky
Wenn ich z.B. (was ja öfter mal vorkommt) nur eine Datei öffnen möchte,
dann mache ich das in C oder PASCAL mit einem einzigen Befehl, dem ich
dem Dateinamen bzw. Pfad übergebe. Danach kann ich aus der Datei mittels
des Handles, welches ich beim Öffnen erhalte, lesen.
Damit hast du OOP schon teilweise benutzt, nämlich in Form von
Abstraktion / Data-Hiding. 'fopen' gibt dir ein opakes 'FILE*'-Objekt,
welches du mit den Methoden 'fread', 'fprintf', 'fseek' usw. manipu-
lieren und mit 'fclose' zerstören kannst.

Es fehlt in C nun nur noch die Möglichkeit, davon abzuleiten und eigene
'FILE*'-Objekte zu erzeugen, die z.B. die geschriebenen Daten
komprimieren oder über's Netz senden. In Java kannst du dass durch
Austauschen eines der vielen Objekte, die du zum Dateilesen brauchst,
erreichen.
Post by Ingo Leschnewsky
Einmal ein Dateiobjekt anhand des Namens erzeugen, dann damit ein
weiteres Objekt verbinden, und mit diesem wiederum einen
"BufferedReader", um dann endlich etwas aus der Datei lesen zu
können.
Ja, das ist ziemlich umständlich; in C++ ist das IMHO besser gelöst.
Post by Ingo Leschnewsky
Der einzige Vorteil, den ich bei der OOP (gegenüber C, nicht jedoch
Fenster, Buttons und andere Widgets sind natürlich ideale Objekte, bei
denen Vererbung und Polymorphie gewisse Vorteile bieten. Aber wenn dann
diese Sichtweise auch noch auf "die Welt da draußen" übertragen wird,
dann kann ich das kaum noch nachvollziehen.
Beispiel GUI-Entwicklung:
Widget
+-- Button
| +-- PushButton
| +-- CheckBox
| `-- RadioButton
+-- InputWidget
+-- Window
`-- ListBox

Beispiel Betriebssystem:
FileSystem
+-- NTFS
+-- FAT
| +-- FAT12
| +-- FAT16
| `-- FAT32
`-- ext2
`-- ext3

CharacterDevice
+-- Console
+-- SerialPort
+-- ParallelPort
`-- Pipe

Beispiel Kommunikation:
Message
+-- NewsPosting
+-- Mail
+-- Fax
`-- VoiceMail

Beispiele gibt's genug, man muss nur genau hinsehen.
Post by Ingo Leschnewsky
Und die zusätzliche Sicherheit bei der Speicherverwaltung wird dadurch
erkauft, daß keine Speicherarithmetik mehr möglich ist. Auch habe ich in
JAVA bislang vergebens nach einem "free"-Befehl gesucht, um dem Garbage
Collector die Arbeit zu erleichtern. :)
Garbage Collection hat nun mit OOP nicht wirklich viel zu tun.


Stefan
Michael Paap
2007-12-06 11:46:50 UTC
Permalink
Post by Stefan Ram
Schön wäre eben eine Aufgabe und ein konkreter
objektorientierter Quelltext, bei dem so etwas /nicht/ geht.
Beispielsweise etwas, bei dem jede prozedurale (modulare)
Lösung erkennbar komplizierter oder langsamer ist.
Lege klare Merkmale fest, an denen man "komplizierter" erkennt.
Post by Stefan Ram
Es ist nur erstaunlich, daß es so schwierig ist, ein
(möglichst einfaches) Beispielprogramm dafür zu finden.
Ich finde das nicht erstaunlich.

"Bitte zeige - möglichst am Beispiel einer Ich-AG - warum moderne
Methoden der Mitarbeiterführung dem guten alten System von Befehl und
Gehorsam überlegen sind."

Gruß,
Michael
Stefan Ram
2007-12-06 10:19:19 UTC
Permalink
Meine Standard-Uebungsaufgabe fuer Anfaenger
Person hat Liste von Konten
Student ist eine Person
Konto hat eine Person als Inhaber
ist da vermutlich zu gross.
C gilt ja nun nicht als objektorientiert, aber dies kann man
dort auch modellieren:

struct person { struct account * accounts; };
struct student { struct person person; };
struct account { struct student * owner; };

Und dann kommen noch die benötigten Funktionen dazu. Auf den
ersten Blick sieht man noch nicht, was mit objektorientierter
Programmierung in diesem Fall einfacher oder besser geht.
Ingo R. Homann
2007-12-06 10:31:30 UTC
Permalink
Hi,
Post by Stefan Ram
List<String> list=new ArrayList<String>();
Gesucht ist eine konkrete Aufgabenstellung, z.B. »Berechne
alle Primzahlen kleiner als 100« und dann eine vollständige
Lösung in C++ oder Java (ein kompilierbares Programm), welche
diese Aufgabenstellung mit objektorientierter Programmierung
löst.
Dabei soll sich dann ein Vorteil erkennen lassen, den man in
einer nicht-objektorientierten Sprache (wie C oder Modula)
oder unter Vermeidung objektorientierter Programmierung nicht
hätte. Das heißt, wenn man dann dieselbe Aufgabenstellung in
einer prozeduralen Sprache löst, soll es nicht möglich sein,
sie so gut zu lösen, wie in der objektorientierten Sprache.
Bei dem Primzahlen-Beispiel hat OO IMHO keinerlei Vorteil. Aber meine
Aufgabenstellung finde ich nach wie vor gut - hier noch einmal
ausführlicher:

"Erstelle einige Beispiel-Funktionen F1 bis Fn, die auf einer Liste
diverse Operationen durchführen (Bsp.: F1=1000 Elemente einfügen,
F2=Iterieren, F3=1000 Random Acesses, ...). Wende diese Funktionen auf
verschiedene Listen-Typen T1...Tm (Bsp.: T1=LinkedList, T2=ArrayList)
an, um zu sehen, welcher Listen-Typ für verschiedene Anwendungszwecke am
geeignetsten ist."

Ohne OO müsstest Du jede Funktion F_i mehrfach implementieren, nämlich
einmal für jeden Listen-Typ. Ich habe das an meinem Java-Beispiel
versucht deutlich zu machen, indem ich die (nicht sauber OO designte)
Klasse Vector (und deren Methode addElement, die im Interface List nicht
definiert ist) verwendet habe, wo so ein Austausch nicht ohne weiteres
möglich ist.

Ansonsten kann ich mich nur Gerd K. anschließen, 'dass der Mehrwert des
objektorientierten Paradigmas sich nicht beim "Programmieren im Kleinen"
zeigt'.

Ciao,
Ingo
Ingo R. Homann
2007-12-06 10:37:14 UTC
Permalink
Hi Stefan,

BTW finde ich follow-ups in andere Newsgroups etwas unhöflich, weil der
geneigte Antwortende seine eigenen Antworten (und die Antworten anderer
auf sein Posting) nicht mehr sieht. Ich erlaube mir daher (sofern ich es
nicht übersehe), grundsätzlich hier in dclj zu antworten.

Ciao,
Ingo
Volker Glave
2007-12-06 09:11:04 UTC
Permalink
Post by Stefan Ram
Post by Stefan Ram
Das ist offensichtlich viel besser (übersichtlicher,
kürzer, wartbarer, schneller, ...) als es in einer
prozeduralen oder modularen Programmiersprache
(wie Pascal, C oder Modula) je möglich wäre.<<
Dies würde man aufgrund der Vorlage eines Programmes
selbstverständlich weder vernünftigerweise sagen können
noch wollen. (Nicht, dass dir das nicht eh klar wäre.)

Gruß
Volker
Ralf Ullrich
2007-12-06 13:34:38 UTC
Permalink
Post by Stefan Ram
Jemand fragt »wofür OOP denn nun gut sei« und erhält eine
abstrakte Antwort: Beispielsweise »Verbesserung der
Wartbarkeit von Software durch Polymorphie«.
Aber wie kann man solche Behauptungen belegen?
Hierfür wäre ein überzeugendes Beispiel hilfreich.
Am besten ein Beispiel, daß auch für Anfänger verständlich ist.
Was ist das kleinste (kürzeste, einfachste) portable Java-
oder C++-Programm, das etwas zu seinem Vorteil
verwendet, das so nur in der OOP möglich ist?
Erstmal musst du definieren, was OOP überhaupt ausmacht. In C kann man
z.B. mit Zeigern auf Funktionen und structs sehr wohl schon
objektorientiert programmieren, auch wenn einem der Compiler dabei keine
schöne Syntax bietet oder bei der Einhaltung der (selbstgesetzten) Regeln
unterstützt. Auch in Pascal habe ich damals, lange bevor es mit Turbo
Pascal 5 einen objektorientierten Dialekt davon gab, bereits weitgehend
objektorientiert gearbeitet.

Also definieren wir doch mal nicht-objektorientiert, indem wir sagen, was
wir als Java-Programmierer alles nicht mehr dürfen, damit das, was übrig
bleibt, nur noch ein rein prozedurales Paradigma erlaubt:

- Top-Level Klassen sind final, haben nur einen private no-arg Konstruktor und alle Methoden und Variablen darin sind statisch. ==> Damit sind Top-Level-Klassen im wesentlichen darauf reduziert ein Namensraum zu sein, ähnlich z.b. den Units in Pascal. public deklarierte Member sind offizielle Schnittstelle und können aus anderen Moduln/Units benutzt werden. private deklarierte Member sind Implementierung. (==> darin zeigt sich übrigens das Kapselung keine ausschließliche Eigenschaft von OOP ist, sondern schon lange vorher in Gebrauch war.)

- Als Datentypen sind alle primitive Typen und String erlaubt. (Achtung: d.h. auch das Boxing nicht mehr erlaubt ist.)
- Als abstrakte Datentypen sind zunächst Arrays erlaubt. Zusätzlich sind noch statische innere Klassen zu den oben erwähnten Top-Level-Klassen erlaubt, sofern sie die folgenden Regeln einhalten:
- sie sind final und entweder public oder private und es ist nur der vom Java Compiler automatisch erzeugte no-arg Konstruktor erlaubt.
- sie haben keine Methoden und keine statischen Variablen
- alle Variablen sind public.
- sie erweitern AbstractDatatype:
public abstract class AbstractDatatype {
public final Object clone() {
throw new UnsupportedOperationException(); }
public final boolean equals(Object o) {
throw new UnsupportedOperationException(); }
public final int hashCode() {
throw new UnsupportedOperationException(); }
public final String toString() {
return super.toString(); }
}
(Das macht aus den Exemplaren effektiv "Nicht-Objekte"
indem für alle Objects garantierte Funktionalität entfernt
wird. Das soll u.a. praktisch verhindern, dass man sie
in Collections verwendet, )

- Die Verwendung der Java Standard-API ist nur erlaubt, wenn dazu in einer Top-Level-Klasse, die wir SysIO nennen wollen, eine statische Wrapper-Methode geschrieben werden kann, die die obigen Regeln nicht verletzt, also insbesondere nur erlaubte Datentypen entgegennimmt und zurückgibt. java.lang.Object wäre z.B. nicht als Argumentstyp erlaubt, aber selbstverständlich kann SysIO eigene abstrakte Datentypen definieren, was zum Beispiel nötig werden würde, wollte man File-I/O anbieten. In der privaten Implementierung von SysIO werden die Regeln nicht forciert. Der Code in SysIO sollte sich nicht mit der eigentlichen Problemlösung beschäftigen sondern sich darauf beschränken eine prozedurale Schnittstelle zur objektorientierten Java-Umgebung zu liefern. Dafür wird bei einem späteren Lösungsvergleich SysIO nicht beachtet, sondern im Sinne einer auch bei prozeduralen Sprachen ja in der Regel vorhandenen System-Bibliothek als gegeben angenommen.


So, wenn man sich diesen Einschränkungen unterwirft, dann kann man ja mal
als kleine Aufgabe folgendes Problem lösen, und dann danach nochmal als
"normales" Java Programm, also sauber objektorientiert, und dann die
Lösungen vergleichen.

Aufgabe:

Schreibe ein Konsolenprogramm, das ein automatisches Schachbrett
realisiert. Das heißt, die aktuelle Stellung soll ausgegeben werden und
dann der nächste Zug vom Benutzer erfragt werden. Dieser Zug soll anhand
der bekannten Schachregeln auf Zulässigkeit geprüft werden, und nur
angenommen und durchgeführt werden, wenn er erlaubt ist. Das Programm muss
(schon wegen der Prüfung der Züge) Schachdrohungen erkennen, muss aber
nicht unbedingt ein Matt erkennen können.


Vergleicht man am Ende beide Lösungen, wird man IMHO feststellen, dass die
objektorientierte Lösung auf natürliche Weise den Code gemäß den zu
lösenden Teilaufgaben strukturiert, während dies beim prozeduralen
Vorgehen nur passiert, wenn der Programmierer dies selbst herbeiführt.
(Wenn er das aber tut, kann sein Code genauso aufgeräumt und leserlich
wirken, wie der objektorientierte.)

Zusätzlich könnte man auch noch bewerten wie stark die Eingriffe ins
fertige Programm sind, wenn es anschließend so erweitert werden soll, dass
man am Beginn auswählen kann ob man eine Partie normales Schach oder eine
Partie Räuberschach spielen will (und das Programm dann dessen deutlich
andere Regeln forcieren muss).

cu
Michael Paap
2007-12-06 13:53:53 UTC
Permalink
Post by Ralf Ullrich
Erstmal musst du definieren, was OOP überhaupt ausmacht. In C kann man
z.B. mit Zeigern auf Funktionen und structs sehr wohl schon
objektorientiert programmieren, auch wenn einem der Compiler dabei keine
schöne Syntax bietet oder bei der Einhaltung der (selbstgesetzten) Regeln
unterstützt. Auch in Pascal habe ich damals, lange bevor es mit Turbo
Pascal 5 einen objektorientierten Dialekt davon gab, bereits weitgehend
objektorientiert gearbeitet.
Dynamische Methodenwahl wirklich sinnig nachzubasteln, wird da aber
schon etwas lästig, oder?

Gruß,
Michael
Ralf Ullrich
2007-12-06 14:24:37 UTC
Permalink
Post by Michael Paap
Post by Ralf Ullrich
Erstmal musst du definieren, was OOP überhaupt ausmacht. In C kann man
z.B. mit Zeigern auf Funktionen und structs sehr wohl schon
objektorientiert programmieren, auch wenn einem der Compiler dabei keine
schöne Syntax bietet oder bei der Einhaltung der (selbstgesetzten) Regeln
unterstützt. Auch in Pascal habe ich damals, lange bevor es mit Turbo
Pascal 5 einen objektorientierten Dialekt davon gab, bereits weitgehend
objektorientiert gearbeitet.
Dynamische Methodenwahl wirklich sinnig nachzubasteln, wird da aber
schon etwas lästig, oder?
Ich sagte ja, der Compiler bietet einem halt keine schöne Syntax, aber den
virtuellen Methodenaufruf via

mapObject->vtable[5](mapObject, key, value)

kann man ja sauber wrappen in

procedure put(mapObject, key, value)
begin
mapObject->vtable[5](mapObject, key, value);
end

Und natürlich ist es Aufgabe des "Konstruktors" den Zeiger auf die der
Klasse entsprechende vtable korrekt zu setzen.

Aber ja, natürlich ist es lästig, das was eine objektorientierte Sprache
hinter den Kulissen für einen macht nun selbst als sich ständig
wiederholenden Boilerplate-Code machen zu müssen. Man wird sich dabei
natürlich auf die wenigen "Methoden" beschränken die tatsächlich virtuell
sein müssen, was in der Praxis so viele gar nicht sind.

cu
Ingo Leschnewsky
2007-12-06 13:55:58 UTC
Permalink
Hallo Ralf!
Post by Ralf Ullrich
Vergleicht man am Ende beide Lösungen, wird man IMHO feststellen, dass
die objektorientierte Lösung auf natürliche Weise den Code gemäß den zu
lösenden Teilaufgaben strukturiert, während dies beim prozeduralen
Vorgehen nur passiert, wenn der Programmierer dies selbst herbeiführt.
(Wenn er das aber tut, kann sein Code genauso aufgeräumt und leserlich
wirken, wie der objektorientierte.)
Hm, dann ist OOP wohl hauptsächlich etwas für Programmierer, die nicht
von sich aus aufgeräumten und leserlichen Code schreiben. ;-)

(Also für alle außer mir... SCNR)

Gruß,
Ingo
Stefan Ram
2007-12-06 14:23:23 UTC
Permalink
Post by Ralf Ullrich
Erstmal musst du definieren, was OOP überhaupt ausmacht.
0 Ein Versuch dazu:

http://www.purl.org/stefan_ram/pub/begriff_objektorientierte_programmierung_de
Post by Ralf Ullrich
In C kann man z.B. mit Zeigern auf Funktionen und structs sehr
wohl schon objektorientiert programmieren, auch wenn einem der
Compiler dabei keine schöne Syntax bietet oder bei der
Einhaltung der (selbstgesetzten) Regeln unterstützt.
1 Bei meinen heutigen Versuchen, C structs zu schreiben
(vorheriges posting), habe ich schon einen Vorteil einiger
objektorientierter Sprachen kennengelernt: Man kann die
Semantik der Beziehung zweier Typen (Obertyp oder Aggregation)
deutlicher unterscheiden als in C. Allerdings muß das nicht
eine Eigenschaft der objektorientierten Programmierung sein,
sondern kann auch eine »Zugabe« dieser Sprachen sein.
Post by Ralf Ullrich
Auch in Pascal habe ich damals, lange bevor es mit Turbo Pascal
5 einen objektorientierten Dialekt davon gab, bereits
weitgehend objektorientiert gearbeitet.
Wenn man in C gegen die Amiga-API oder Win32 programmiert,
wird man schon mit Dingen konfrontiert, die man als
»objektorientiert« empfindet. Jemand erwähnte vorhin die
Schnittstellen: Da ist es beispielsweise so, daß alle
Amige-Gerätetreiber eine Schnittstelle implementieren, indem
Einträge, die in der Sprungtabelle am Anfang an der gleichen
Stelle stehen dieselbe Bedeutung haben. - Das ist auch auf
der Maschinensprachenebene zu sehen. - Oder »Fensterklassen«
in der Windows-API.
Post by Ralf Ullrich
- Top-Level Klassen sind final,
Also keine Vererbung. Die könnte man durch Aggregation
noch nachbilden, was aber weniger klar wäre.

In Absatz 1 erwähnte ich das schon, allerdings wirft die
Quelle aus Absatz 0 die Frage auf, ob Vererbung zum Kern
der objektorientierten Programmierung gehört.
Post by Ralf Ullrich
haben nur einen private no-arg Konstruktor
Das verhindert Exemplarbildung, die allerdings in
nicht-objektorientierten Sprachen auch möglich ist.

»records« in Pascal, oder in C:

struct example * e = malloc( sizeof( struct example )); if( e ) ...
Post by Ralf Ullrich
und alle Methoden und Variablen darin sind statisch.
Die Bildung von Exemplaren zu record/struct-Typen ist
in Pascal und C auch möglich (vielleicht schon in
Algol 68) und daher vielleicht nicht unbedingt spezifisch
»objektorientiert«.
Post by Ralf Ullrich
==> Damit sind Top-Level-Klassen im wesentlichen darauf
reduziert ein Namensraum zu sein, ähnlich z.b. den Units in
Pascal.
Ja, mir ist schon aufgefallen: Einige Vorteile, die ich
bisher der objektorientierten Programmierung zuschrieb,
gehören zur modularen Programmierung. Die Empfehlungen
für Kohäsion und Kapselung kann man nämlich erst einmal
auch auf Module oder abstrakte Datentypen münzen. Und
entsprechend bestimmte Vorteile der Strukturierung mit
Klassen.
Post by Ralf Ullrich
darin zeigt sich übrigens das Kapselung keine ausschließliche
Eigenschaft von OOP ist, sondern schon lange vorher in Gebrauch
war.
Genau an so etwas dachte ich.

Die Frage ist nämlich, was dann wirklich spezifisch
Objekt-Orientiert ist.
Post by Ralf Ullrich
- Als abstrakte Datentypen sind zunächst Arrays erlaubt.
Die könnte man auch »Behältertypen« nennen, da sie auch eine
Implementation haben - die ein abstrakter Datentyp WIMRE nicht
haben müßte.
Post by Ralf Ullrich
(Das macht aus den Exemplaren effektiv "Nicht-Objekte"
indem für alle Objects garantierte Funktionalität entfernt
wird. Das soll u.a. praktisch verhindern, dass man sie
in Collections verwendet, )
Wobei man vielleicht auch in der prozeduralen Programmierung
zu Datensätzen universelle »toString«- und
»hashCode«-Funktionen schreiben kann.

In C wäre es aber ein Problem, daß ein Datensatz zur Laufzeit
seinen Typ nicht immer kennt - nicht einmal seine Größe.
Das macht solche universellen Funktionen doch unmöglich.

Man könnte daher in die Definition von objektorientierter
Programmierung vielleicht noch aufnehmen, daß
Laufzeittypinformationen (implizit oder explizit) unterstützt
werden und mindestens verwendet werden können, um passende
Programmteile auszuwählen und im allgemeinen auch die Größe
eines Objekts zur Laufzeit implizit oder explizit erfahren
werden kann.
Post by Ralf Ullrich
Schreibe ein Konsolenprogramm, das ein automatisches
Schachbrett realisiert. Das heißt, die aktuelle Stellung soll
ausgegeben werden und dann der nächste Zug vom Benutzer erfragt
werden. Dieser Zug soll anhand der bekannten Schachregeln auf
Zulässigkeit geprüft werden, und nur angenommen und
durchgeführt werden, wenn er erlaubt ist. Das Programm muss
(schon wegen der Prüfung der Züge) Schachdrohungen erkennen,
muss aber nicht unbedingt ein Matt erkennen können.
Das ist nicht ganz so einfach, wie ich erhofft hatte, aber
vielleicht geht es wirklich nicht unter einer gewissen
Komplexität. Wenn ich mehr Zeit habe, komme ich vielleicht
noch einmal auf diese Aufgabe zurück.
Post by Ralf Ullrich
Vergleicht man am Ende beide Lösungen, wird man IMHO
feststellen, dass die objektorientierte Lösung auf natürliche
Weise den Code gemäß den zu lösenden Teilaufgaben strukturiert,
während dies beim prozeduralen Vorgehen nur passiert, wenn der
Programmierer dies selbst herbeiführt. (Wenn er das aber tut,
kann sein Code genauso aufgeräumt und leserlich wirken, wie der
objektorientierte.)
Wenn ich einmal mehr Zeit habe, dann würde ich das gerne
einmal ausprobieren. Ich komme aber nicht gleich dazu.
Post by Ralf Ullrich
Zusätzlich könnte man auch noch bewerten wie stark die
Eingriffe ins fertige Programm sind, wenn es anschließend so
erweitert werden soll, dass man am Beginn auswählen kann ob man
eine Partie normales Schach oder eine Partie Räuberschach
spielen will (und das Programm dann dessen deutlich andere
Regeln forcieren muss).
Ja, das könnte ein Punkt sein.

Ich habe schon einmal versucht, aufzuschreiben, warum die
objektorientierte Programmierung dann vorteilhaft ist, aber
dort fehlt noch ein Beispiel und weitere Ausarbeitung,
weswegen dieser Artikel derzeit vielleicht noch nicht gut
lesbar ist.

http://www.purl.org/stefan_ram/pub/warum-objektorientierte-programmierung
Paul Ebermann
2007-12-08 01:47:12 UTC
Permalink
Post by Stefan Ram
Post by Ralf Ullrich
Erstmal musst du definieren, was OOP überhaupt ausmacht.
- Top-Level Klassen [...]
haben nur einen private no-arg Konstruktor
Das verhindert Exemplarbildung, die allerdings in
nicht-objektorientierten Sprachen auch möglich ist.
struct example * e = malloc( sizeof( struct example )); if( e ) ...
Post by Ralf Ullrich
und alle Methoden und Variablen darin sind statisch.
Die Bildung von Exemplaren zu record/struct-Typen ist
in Pascal und C auch möglich (vielleicht schon in
Algol 68) und daher vielleicht nicht unbedingt spezifisch
»objektorientiert«.
Für Record-Typen hat Ralf ja die "statischen inneren Klassen"
("static nested classes" in der JLS - "inner classes" sind ja
gerade die nicht-statischen "nested classes") vorgesehen, nicht
die Top-Level-Klassen.
Post by Stefan Ram
Post by Ralf Ullrich
Schreibe ein Konsolenprogramm, das ein automatisches
Schachbrett realisiert. Das heißt, die aktuelle Stellung soll
ausgegeben werden und dann der nächste Zug vom Benutzer erfragt
werden. Dieser Zug soll anhand der bekannten Schachregeln auf
Zulässigkeit geprüft werden, und nur angenommen und
durchgeführt werden, wenn er erlaubt ist. Das Programm muss
(schon wegen der Prüfung der Züge) Schachdrohungen erkennen,
muss aber nicht unbedingt ein Matt erkennen können.
Das war eine der Programmieraufgaben, mit denen ich
angefangen hatte - mit DOS-BAT-Programmen, in denen
man nicht wirklich richtig rechnen kann, und eigentlich
nur String-Variablen hat - allerdings kann man mit ein
paar Tricks (wie z.B. Aufruf von Programmen, deren Namen
man aus Variablen zusammensetzt, und in denen dann wieder
andere Variablen gesetzt werden, oder "goto %variable%"
einen gewissen Grad an Pseudo-OO umsetzen :-)

Und dann bin ich an der Überprüfung des Läufers
gescheitert (und habe versucht, das in C auszulagern).

Ich hatte schon ein tolles TUI mit Menüführung etc.,
aber keine Funktion für das Programm :-)


Als ich dann (viel später) mit Java angefangen habe, war
es umgekehrt: ich habe Bibliotheken geschrieben, die nie
von einem Programm genutzt wurden...


Paul
--
Nun ludigxas: : ()
Stefan Ram
2007-12-06 15:41:16 UTC
Permalink
(Versehentliches Mehrfach-Posting.)
Post by Stefan Ram
Was ist das kleinste (kürzeste, einfachste) portable Java-
oder C++-Programm, das etwas zu seinem Vorteil
verwendet, das so nur in der OOP möglich ist?
Hier ein Versuch, meine eigene Frage zu beantworten.

Ich will einen neuen Typ einführen:

class Position
{ int x; int y;
@java.lang.Override
public java.lang.toString()
{ return java.lang.String.valueOf( x ) +
", " + java.lang.String.valufOf( y ); }}

...

final Position position = new Position();

Nun erzeugt

java.lang.String.valueOf( position );

die gewünschte Textdarstellung.

In einer prozeduralen Sprache müßte man dazu wohl den
Bibliotheks-Quellcode einer globalen »toString«-Funktion
(oder einer globalen »StringValueOf«-Funktion) öffnen
und ändern (Verstoß gegen das Offen-Geschlossen-Prinzip).

In einer objektorientierten Sprache kann ich »toString«
erweitern, ohne schon vorhandenen Code verändern zu müssen.
Ralf Ullrich
2007-12-06 18:04:52 UTC
Permalink
Post by Stefan Ram
Nun erzeugt
java.lang.String.valueOf( position );
die gewünschte Textdarstellung.
In einer prozeduralen Sprache müßte man dazu wohl den
Bibliotheks-Quellcode einer globalen »toString«-Funktion
(oder einer globalen »StringValueOf«-Funktion) öffnen
und ändern (Verstoß gegen das Offen-Geschlossen-Prinzip).
In einer objektorientierten Sprache kann ich »toString«
erweitern, ohne schon vorhandenen Code verändern zu müssen.
Der Vorteil ergibt sich aber vor allem, weil er in die objektorientierte
Bibliothek schon eingebaut ist.

Ich würde daher ein Beispiel bevorzugen, in dem das nicht der Fall ist.
sagen wir mal wir wollen Terme mit den vier Grundrechenarten wie "5 / (4 -
3 * 2) + 1" berechnen, dann könnte ein prozedurales Programm (nach meinen
Einschränkungen aus dem anderen Post) so aussehen:

public final class TermCalcProc {
private TermCalcProc() {}

public static Term extends AbstractDatatype {
public char op;
public double number;
public Term left;
public Term right;
}

public static void main(String... args) {
Term t = add(divide(number(5),subtract(number(4),multiply(number(3),number(2))),number(1));
SysIO.println(calc(t));
}

public static Term number(double v) {
Term t = new Term();
t.op = '=';
t.number = v;
return t;
}

private static Term newTerm(char op, Term l, Term r) {
Term t = new Term();
t.op = op;
t.left = l;
t.right = r;
return t;
}

public static Term add(Term l, Term r) {
return newTerm('+',l,r);
}

public static Term subtract(Term l, Term r) {
return newTerm('-',l,r);
}

public static Term multiply(Term l, Term r) {
return newTerm('*',l,r);
}

public static Term divide(Term l, Term r) {
return newTerm('/',l,r);
}

public static double calc(Term t) {
switch (t.op) {
case '=': return t.number;
case '+': return calc(t.left) + calc(t.right);
case '-': return calc(t.left) - calc(t.right);
case '*': return calc(t.left) * calc(t.right);
case '/': return calc(t.left) / calc(t.right);
}
}
}

Macht man das gleiche mit einem objektorientierten Ansatz:

public class TermCalcOOP {
public static void main(String... args) {
Term t = new Add( new Divide(new Number(5), new Subtract( new Number(4),new Multiply(new Number(3),new Number(2))),new Number(1));
System.out.println(t.calc());
}
}

interface Term {
double calc();
}

class Number extends Term {
double number;
Number(double v) {
this.number = v;
}

abstract class Op extends Term {
protected final Term left;
protected final Term right;
Op(Term l, Term r) {
this.left = l;
this.right = r;
}
}

class Add extends Op {
Add(Term l, Term r) {
super(l,r);
}
double calc() {
return l.calc() + r.calc();
}
}

class Subtract extends Op {
Subtract(Term l, Term r) {
super(l,r);
}
double calc() {
return l.calc() - r.calc();
}
}

class Multiply extends Op {
Multiply(Term l, Term r) {
super(l,r);
}
double calc() {
return l.calc() * r.calc();
}
}

class Divide extends Op {
Divide(Term l, Term r) {
super(l,r);
}
double calc() {
return l.calc() / r.calc();
}
}


Zunächst mal sieht man keinen Vorteil, eher den Nachteil, dass das
objektorientierte Programm duch die zusätzlichen Klassen Deklarationen
mehr zu tippen ist, und dass man eine ganze Reihe mehr Datentypen hat, was
das Programm umso komplexer erscheinen lässt. Und ob es nun besser ist den
Berechnungscode an einer Stelle zusammenzuhalten oder auf die Operationen
aufzuteilen, kann man so ohne weiteres nicht entscheiden.

Der Vorteil zeigt sich eben auch hier erst wenn man nicht mehr vom
statischen Programm, das einmal in die Welt gesetzt wird und nie wieder
verändert wird ausgeht, sondern von einem sich ständig weiterentwickelnden
Programm. Und so kann eine fünfte Rechenart, sagen wir das Potenzieren
(z.B. 2^4 = 16), im objektorientierten Programm eingebaut werden, ohne
Gefahr zu laufen in bereits getestete und korrekte Programmteile neue
Fehler einzubauen, weil man deren Quelltexte ändern musste. Und so zeigt
sich dann auch, dass es eben doch ein Vorteil war, die
Berechnungsoperationen aufzuteilen.

Nebenbei zeigt sich auch noch etwas typisches für objektorientierte
Programme: Je mehr Typen desto flexibler. Man hätte ja schließlich auch
analog zum prozeduralen Programm alles in eine Klasse Term packen können,
hätte dann aber bei der Erweiterung die gleichen Probleme gehabt, wie bei
der rein prozeduralen Lösung. Ergo: Objektorientiertheit allein schafft
noch keine Vorteile, erst der sinnvolle Einsatz dieses Sprachmittels
erreicht das.

cu

PS: Wenn du das Schachprogramm schreibst melde dich bei mir, ich bin
erstens gerne Schiedsrichter für die Beschränkungen und würde dann
zweitens auch zwei Varianten von mir beisteuern. Alleine will ichs nicht
machen, weil mich dabei vor allem interessieren würde, wie stark sich die
prozeduralen verschiedener Programmierer unterscheiden und wie stark in
Vergleich dazu die Unterschiede bei den objektorientierten Lösungen sind.
Mit dir und mir wären das schon mal zwei Programmierer und damit das
absolute Minimum, für meine Interessen bei der Angelegenheit.
Ingo Leschnewsky
2007-12-07 11:21:31 UTC
Permalink
Hallo Ralf!
Post by Ralf Ullrich
Der Vorteil zeigt sich eben auch hier erst wenn man nicht mehr vom
statischen Programm, das einmal in die Welt gesetzt wird und nie wieder
verändert wird ausgeht, sondern von einem sich ständig
weiterentwickelnden Programm. Und so kann eine fünfte Rechenart, sagen
wir das Potenzieren (z.B. 2^4 = 16), im objektorientierten Programm
eingebaut werden, ohne Gefahr zu laufen in bereits getestete und
korrekte Programmteile neue Fehler einzubauen, weil man deren Quelltexte
ändern musste. Und so zeigt sich dann auch, dass es eben doch ein
Vorteil war, die Berechnungsoperationen aufzuteilen.
Wenn man sein Programm vernünftig strukturiert, kann man Probleme dieser
Art auch bei der prozeduralen Programmierweise vermeiden.

Das Problem scheint mir eher ein praktisches zu sein, nämlich, daß es
viele einfach nicht tun (gleiches gilt natürlich auch für die
Dokumentation). Aber durch OOP könnten sie mehr oder weniger dazu
gezwungen werden, ihre Programme gut zu strukturieren.

Gruß,
Ingo
Jochen Theodorou
2007-12-07 13:14:12 UTC
Permalink
Post by Ingo Leschnewsky
Hallo Ralf!
Post by Ralf Ullrich
Der Vorteil zeigt sich eben auch hier erst wenn man nicht mehr vom
statischen Programm, das einmal in die Welt gesetzt wird und nie
wieder verändert wird ausgeht, sondern von einem sich ständig
weiterentwickelnden Programm. Und so kann eine fünfte Rechenart, sagen
wir das Potenzieren (z.B. 2^4 = 16), im objektorientierten Programm
eingebaut werden, ohne Gefahr zu laufen in bereits getestete und
korrekte Programmteile neue Fehler einzubauen, weil man deren
Quelltexte ändern musste. Und so zeigt sich dann auch, dass es eben
doch ein Vorteil war, die Berechnungsoperationen aufzuteilen.
Wenn man sein Programm vernünftig strukturiert, kann man Probleme dieser
Art auch bei der prozeduralen Programmierweise vermeiden.
ich sprache in diesem Thread ja schon die Idealvorstellungen an... Man
sollte eher fragen: bin ich bei der OOP flexibler in der
Umstrukturierung? Und meine Antwrot dazu würde "Ja" sein, ganz einfach
weil man abstrakter arbeitet.

Gruss theo
--
Jochen "blackdrag" Theodorou
The Groovy Project Tech Lead (http://groovy.codehaus.org)
http://blackdragsview.blogspot.com/
http://www.g2one.com/
Lesen Sie weiter auf narkive:
Loading...