Hallo, da ich JAVA erlernen will hab ich mir das Buch "Handbuch der JAVA Prog." (Guido Krüger) gekauft und die allgemeinen Kapitel schon einigemale durchgearbeitet. (Bis jetzt hab ich nur ASM programmiert) Aber irgendwie steh ich mit diesem ganzen objektorientierten Programmierstil auf der Leitung bzw. mit dem syntax in dem die Sprache arbeitet. Irgendwie gelingt es mir nicht einmal eine ordentliche Frage zu meinem Problem zu stellen um hier eine Antwort zu erhalten. Also allgemein Formuliert hat wer einen Tipp für mich damit ich mich besser zurechtfinde in der neuen Welt. Michael
Also ich fand das Buch "Java 2 - in 21 Tagen" o.Ä. ganz brauchbar. Direkt Tipps um den "objektorientierten Programmierstil" verstehen zu lernen hab ich nicht. Wenn man sich genügend lange damit beschäftigt macht es einfach "Klick". Ist jedenfalls meine Meinung.
Also ich finde zuerst sollte man ganz normal programmieren ohne Objektorientiert Programmierung. OOP ist nicht zwingend aber sicher gut. Je mehr du dann kannst desto mehr kommst du dann automatisch in diese Technik hinein. Gruss Weihnachtsmann
Nein, das ist ein beliebtes Missverständnis. Die Programmiersprache hat erst mal überhaupt garnichts damit zu tun, ob man objektorientiert programmiert oder nicht. Es gibt nur einige Programmiersprachen, die einem das objektorientierte Vorgehen einfacher machen als andere. In Assembler ist es halt deutlich komplizierter und erfordert sehr viel Disziplin von Seiten des Programmierers, während Java und ähnliche Sprachen teilweise die Disziplin durch ihren Aufbau erzwingen. Dennoch: Auch in Java ist rein prozedurales Programmieren möglich - und ich lehne mich wahrscheinlich noch nicht mal sonderlich weit aus dem Fenster, wenn ich behaupte, daß ein Großteil der ach so objektorientierten Java-Programme, die so geschrieben werden, tatsächlich gar nicht objektorientiert sind, sondern klassische prozedurale Programme in einer dünnen Objektverpackung. Um tatsächlich objektorientiert vorzugehen, ist es meiner Ansicht nach erforderlich, erst mal überhaupt prozedural programmieren zu können, um die Vorzüge der objektorientierten Vorgehensweise auch nur ansatzweise verstehen oder gar schätzen zu können. Frei von programmiersprachen weiht beispielsweise das Buch "The Tao of Objects" in die Denkkonzepte der OO ein - aber man muss halt schon wissen, was es heisst, zu programmieren, um diese Konzepte auf reale Probleme anwenden zu können.
....heißt das einfach ausgedrückt ich kann entweder mit mit meinen Variablen mich wohin verzweigen lassen und dann dort die z.B. Berechnungen durchführen (Proz. Prog.) oder in der OOP definiere ich mir in der Klasse meine Methoden für meine Obj. d.h. im Programmfluß kommt dann nurmehr der Aufruf der Methode vor ?? Kann ich mir das so (lainhaft) vorstellen. ??? Worin liegt dann eigentlich der vorteil der OOP. warum verwenden das alle Programmierer so als wärs eine Modeerscheinung. Danke für Eure Antworten Michael
Anders ausgedrück: Ich programmiere ein komplexes Objekt. Nun brauche ich das Objekt 10 mal. Mit OOP programmiere ich es 1x und kreiere es dann 10x. Du musst es nicht 10x programmieren. Und wenn ich es 500x brauch kreiere ich es eben 500x. Jetzt wird dir auch klar werden warum OOP so gut ist. Gruss Weihnachtsmann.
Bitte -wenn möglich- das "Au weia" aufklären (so das es ein Anfänger versteht).. Danke
wenn du eine funktion 500 mal brauchst, rufst du sie eben 500 mal auf. wo ist jetzt der unterschied? der vorteil von oop liegt imo eher in der vererbbarkeit und der damit möglichen doppeltnutzung von methoden wenn probleme die gleiche (programmtechnische) basis haben. ausserdem schaffen voneinander vererbte klassen einheitlicher definierte schnitstellen wenn man sich dran hält
Ich wollte damit nicht eine Funktion erklären sondern eben ein Objekt. Anderes Beispiel. Ich mache ein Verkehrsymulationsprogramm das den Strassenverkehr einer Stadt simuliert. Ich mache ein Objekt Auto. Mit verschiednen Eigenschaften. Langsamer Fahrer, Normal Fahrer, schneller Fahrer usw. Wenn ich jetzt 500 Autos brauche muss ich nicht jedes einzeln programmieren. Sondern ich mache eine 500x Kopien von dem Auto(Objekt) das ich erstellt habe und weise jedem einzelnen Objekt dann die Gewünschten Eigenschaften zu. Wie Langsamer Fahrer usw. Gruss Weihnachtsmann
Hallo Michael,
ich hatte das gleiche Problem:
Nach 15 Jahre langer (prozeduraler) Programmier-Abstinenz (FORTRAN,
CLIPPER, PASCAL) begann ich im Januar 2004, mir die objektorientierte
Programmentwicklung in JAVA zu erschließen.
Das erstgekaufte, in der Buchhandlung nur flüchtig durchblätterte
JAVA-Buch neuesten Erscheinungsdatums (das gleiche, das Du nanntest)
legte ich bald zur Seite, ich kam damit keinen Schritt voran. Ich legte
eine längere JAVA-Lernpause ein.
Nach Suche im Internet stieß ich dann auf ein online wie offline
verfügbares Buch eines sympathischen Verlags mit sympathischem Autor,
das ich dann ebenfalls käuflich erwarb ("Java ist auch eine Insel")
Leider wollte sich nach Studium der Anfangskapitel auch hier kein
Verständnis für JAVA und vor allem für OO-Programmentwicklung
einstellen. Ich fand die dort aufgeführten Beispiele wie
"Socken"-Objekte total daneben. So legte ich wieder eine längere
JAVA-Lernpause ein.
Über den Jahreswechsel habe ich mir dann in der Buchhandlung genügend
Zeit genommen, ein paar Bücher genauer anzuschauen. Ich suchte nach
bildlichen Darstellungen - wir Menschen denken nun mal in Bildern. Und
ganz einfach nach Darstellung von Algorithmen in einem mir von früher
vertrauten Planungsystem, dem Nassi-Shneidermann-Diagramm.
So kam ich auf das Buch Programmieren in JAVA von Fritz Jobst, Hanser
Verlag, und ich habe es nicht bereut, es "läuft" mir garadezu
"hinein", ich beginne endlich zu verstehen. Wenn man Kapitel 1-3
durcharbeitet und versteht, vor allem Kapitel 3, erschließt sich einem
auf einmal der OO-Ansatz - unter der genannten Bedingung, bereits
prozedural programmieren zu können.
Gruß
Michael
"erschließt sich einem auf einmal der OO-Ansatz - unter der genannten Bedingung, bereits prozedural programmieren zu können." O ja.
An der OOP ist mehr dran, als man so einfach in diesen Beitrag erklären könnte. Stichworte sind: Klassen, Instanzierung, Vererbung ,Kapselung, Überschreiben von Methoden usw. Die OOP sollte dem Menschlichen denken näher kommen als die Prozedurale Programmierung (PP). Sie ist im weitesten Sinne der Realität nachempfunden. (Dem richtigen Leben) B.s.p. Stell Dir einen Tisch vor mit einem Bleistift drauf. Der Tisch ist ein Obj. und der Bleistift ist eines. Jedes der Obj hat Eigenschaften (Form, Farbe, Material usw.) Jedes der Obj hat Methoden Funktionen (Bleistift: Schreiben ,Tisch: verrücken z.B.) Instanzieren: bedeutet ein Obj. ins Spiel bringen. In unseren B.s.p. einen Spitzer um durch die Methode anspitzen (obj. Spitzer ) nutzen zu können. Wenn wir also den Spitzer auf den Tisch legen ähnelt das dem instazieren eines Obj.(Bleistift) im übergeordneten Obj.(Tisch) Eine Bibliothek oder (Klassensammlung, Obj. sammlung, Framework wie auch immer) währe in unseren Fall ein Federmäppchen, welches die Schreibwerkzeuge(Objekte) beinhaltet. Schritt für Schritt bei Übungsprojekten: 1. Was will ich machen? (eine einfache Übung für den Anfang) (Schreiben) 2. welche Obj. brauche ich dazu. (die Werkzeuge in der Bibliothek Federmäppchen) 3. Federmäppchen einbinden (auf den Tisch legen) 4. Welches Werkzeug speziell solls den sein. (Bleistift) 5. Bleistift instazieren (aus dem Federmäppchen nehmen)* 6. Methode Schreibe aufrufen und als Parameter Text angeben Methoden sind Funktionen(ähnlich pascal, basic, usw.) die in einem Objekt enthalten sind. Der zugriff drauf wird aber durch Public, Private usw. bestimmt (stark vereinfacht ausgedrückt). Eigenschaften sind plump gesagt an Objekte gebundene Variablen, deren werte können In java mit GETirgendwas SETirgendwas Methoden verändert oder gelesen werden. * in Wirklichkeit wird eine Kopie vom Prototypen (Bleistift erstellt) eine art Clon der aber die Eigenschaften (und Methoden ) des eigentlichen Obj. hat. Bei weitem nicht komplett und um 2.30 verfasst. Lex
@Rufus: "Nein, das ist ein beliebtes Missverständnis. Die Programmiersprache hat erst mal überhaupt garnichts damit zu tun, ob man objektorientiert programmiert oder nicht. Es gibt nur einige Programmiersprachen, die einem das objektorientierte Vorgehen einfacher machen als andere." [x] Du kennst Smalltalk nicht.
Ja, gebe ich offen zu. Hat Smalltalk ausserhalb akademischer Hochburgen auch nur irgendeine realitätsnahe Anwendung? Gar auf Microcontrollern?
"Hat Smalltalk ausserhalb akademischer Hochburgen auch nur irgendeine realitätsnahe Anwendung?" Ja. Du hast offensichtlich noch nicht in der freien Wirtschaft gearbeitet. "Gar auf Microcontrollern?" Keine Ahnung. In der Tat ist aber Deine Aussage bezüglich der Objektorientierung falsch. In Smalltalk ist das nämlich anders. Fakt ist allerdings, dass Deine Aussage überhaupt nicht stimmt, selbst wenn Smalltalk nicht umfassend in der freien Wirtschaft genutzt würde.
Ich arbeite in der freien Wirtschaft (Automatisierungsbranche), habe
etwa 15 Jahre Berufserfahrung als Entwickler und Smalltalk wird hier
nirgends eingesetzt. Wirklich nirgendwo.
Könntest Du diese etwas gewagte Aussage
"Fakt ist allerdings, dass Deine Aussage überhaupt nicht stimmt,
selbst wenn Smalltalk nicht umfassend in der freien Wirtschaft
genutzt würde."
irgendwie erklären?
a) Was ist für Dich "die freie Wirtschaft"?
b) Anwendungsbeispiele für ernstgemeinte Anwendungen für Smalltalk
c) was hat die freie Wirtschaft damit zu tun, ob Programmiersprachen
objektorientierung erzwingen oder nicht?
d) Oder bezieht sich Deine Aussage auf meine Frage? Bist Du Dir im
klaren darüber, daß eine Frage nicht "nicht stimmen" kann?
e) Den Begriff "realitätsnah" kennst Du auch?
Trotzdem bleibe ich dabei, daß eine Programmiersprache nicht
objektorientiertes Entwickeln per se mit sich bringt.
Es ist möglich, in Assembler objektorientierte Programme zu schreiben
(auch wenn das sehr viel Disziplin von Seiten des Programmierers
erfordert), ebenso, wie es möglich ist, in C++/Java/Delphi oder was
auch immer traditionelle prozedurale Programme zu
schreiben/verbrechen.
Und warum Code* wie
servoCounter := 250.
[
self clearWatchdogTimer.
servoCounter = servoOnePosition
ifTrue: [ServoPort clearBit: Servo1Pin]]
repeatWhile: [servoCounter decrementSkipIfZero].
ServoPort clearBit: Servo1Pin
per se objektorientiert sein soll, das mag eine Definitionsfrage sein.
Halt 'ne andere Syntax, mit wahrscheinlich auch ganz "mächtigen"
Sprachkonstrukten, aber auch in dieser Sprache wird man klassisch
prozedural vorgehen können.
*) stammt von dem Typen, der Smalltalk auf PICs implementiert hat
Um dem OP mal ein wenig weiterzuhelfen: Ich persönlich fand das Java-Tutorial von Sun selbst äußerst hilfreich, da hab ich einen gewissen Durchblick in den Sinn der OOP erhalten. Und nochmal ein praktisches Beispiel, wo einem das Arbeit erspart: Ich hatte mal vor, ein Lochraster-Layoutprogramm zu schreiben, und dafür brauchte ich dann natürlich irgendwelche kleinen mausverschiebbaren Symbole, die die Bauteile darstellen. Bei Java kann man dann ganz einfach ein schon existierendes Objekt hernehmen (bei mir JPanel) und all dessen Eigenschaften erstmal übernehmen, die die einem nicht passen kann man mit eigenen überschreiben, und man kann weitere hinzufügen. So sind z. B. die Funktionen zur Größenänderung, zur Rahmenseinstellung, zur Sichtbarmachung etc. alle noch vorhanden, und ich kann mir z. b. noch eine dazuschreiben die wahlweise ein Kondensator- oder Widerstandssymbol draufzeichnet. Dadurch hat man sich natürlich jede Mene Zeit gespart im Vergleich zu einem kompletten Neuentwurf.
Hallo Ich war mal vor vor ca. 15 Jahren auf einem Einführungsvortrag zur Objektorientierung der von einem exzellenten Fachmann exzellent vorgetragen wurde! Nach dem Vortrag hatte der einladende Prof. (Informatik) die Größe den Vortragenden zu fragen "Was ist eigentlich Objektorientierte Programmierung und was ist der Vorteil". Das war etwas provokant aber durchaus ernst gemeint. Die "vielen" Anwesenden haben erleichtert gelächelt, weil der Vortrag für Sie zu "hoch" war. Der Vortragende hat folgendes geantwortet, was ich damals als Unverschämt empfunden habe, da lauter "prozeduralen" Fachleute da waren: "Wer in dieser Denkweise nicht drin ist, dem kann man das auch nicht in einem Vortrag erklären". Heute denke ich ==> Der Fachmann hatte damals Göße gezeigt und ist unsinnigen Fachdiskussionen sowie Glaubenskriegen aus dem Wege gegangen. Heute könnte ich Seinem Vortrag bestimmt besser folgen! Trotzdem der Versuch einer kurzen Erklärung: Ein Auszug aus dem Vorwort eines "Object-Oriented Data Analysis Framework" ROOT (root.cern.ch) zwar in C++, aber kurz und plausibel erklärt. Darüber sollte mann keine Glaubenskrieg entfachen, sonder mal darüber meditieren. Why Object-Oriented? Object-Oriented Programming offers considerable benefits compared to Procedure-Oriented Programming: Encapsulation enforces data abstraction and increases opportunity for reuse. Sub classing and inheritance make it possible to extend and modify objects. Class hierarchies and containment hierarchies provide a flexible mechanism for modeling real-world objects and the relationships among them. Complexity is reduced because there is little growth of the global state, the state is contained within each object, rather than scattered through the program in the form of global variables. Objects may come and go, but the basic structure of the program remains relatively static, increases opportunity for reuse of design. MfG Achim
@Rufus: "Ich arbeite in der freien Wirtschaft (Automatisierungsbranche), habe etwa 15 Jahre Berufserfahrung als Entwickler und Smalltalk wird hier nirgends eingesetzt. Wirklich nirgendwo." Ich habe 16 Jahre Erfahrung, allerdings überwiegend im Sektor Banken und Finanzdienstleistungen. Dort findet man eigentlich überall Smalltalk. "Könntest Du diese etwas gewagte Aussage "Fakt ist allerdings, dass Deine Aussage überhaupt nicht stimmt, selbst wenn Smalltalk nicht umfassend in der freien Wirtschaft genutzt würde." irgendwie erklären? a) Was ist für Dich "die freie Wirtschaft"? b) Anwendungsbeispiele für ernstgemeinte Anwendungen für Smalltalk c) was hat die freie Wirtschaft damit zu tun, ob Programmiersprachen objektorientierung erzwingen oder nicht? d) Oder bezieht sich Deine Aussage auf meine Frage? Bist Du Dir im klaren darüber, daß eine Frage nicht "nicht stimmen" kann? e) Den Begriff "realitätsnah" kennst Du auch?" Zu a) Ich schrieb es schon: Banken/Finanzen b) Da verweise ich am besten auf eine prominente Seite: http://www-306.ibm.com/software/awdtools/smalltalk/casestudies/ c) Nichts, aber Du hast ja durchklingen lassen, dass Smalltalk "ausserhalb akademischer Hochburgen" keine Anwendung fände d) - e) Klar. Sonst würde ich nicht Smalltalk programmieren :) "Trotzdem bleibe ich dabei, daß eine Programmiersprache nicht objektorientiertes Entwickeln per se mit sich bringt. Es ist möglich, in Assembler objektorientierte Programme zu schreiben (auch wenn das sehr viel Disziplin von Seiten des Programmierers erfordert), ebenso, wie es möglich ist, in C++/Java/Delphi oder was auch immer traditionelle prozedurale Programme zu schreiben/verbrechen." Und genau da liegst Du komplett falsch. Du kennst halt keine objektorientierte Sprache. Das entscheidende an Smalltalk ist, dass alles ein Objekt ist, selbst Klassen. Sämtliche Operationen in Smalltalk bestehen aus Meldungen an Objekte. Es gibt keine syntaktischen Schleifen- oder Bedingungskonstrukte, so etwas wird durch Meldungen abgebildet. Für erfahrene Java- oder C++ Entwickler ist das vielleicht ungewohnt, für einen Einsteiger allerdings - im Gegensatz zu Deiner Meinung - eine grosse Erleichterung. Gerade die Konsistenz der Sprachkonzepte sowie die sehr einfache Syntax zeichnen die Sprache als Einsteigersprache aus. Ein Riesenproblem bei Java, C++ und auch allen anderen statisch typisierten Sprachen ist doch, dass der Typ eines Objektes zur Kompilierzeit bekannt sein muss, damit es nicht zur Laufzeit zu Typfehlern kommt. Genau deshalb finden sich in jeder typischen Java oder C++ Anwendung die üblen Typ-Casts. Wenn dann sich in einem grösserem Projekt mal was ändert, so muss der Entwickler (oder schlimmer noch: das ganze Team) erst mal alle diese Stellen finden und ändern. Das da Fehler vorprogrammiert sind, muss ich nicht erwähnen (schon mal die diversen Posts zum Thema Casting in diesem Forum gelesen?) In Smalltalk dagegen ist nicht der Typ entscheidend, sondern das Protokoll, also die Menge der Meldungen, die ein Objekt versteht. Man kann also z.B. ganz einfach über eine Menge heterogener Objekte iterieren und an alle dieselbe Meldung verschicken, wenn alle dieselbe Methode implementiert haben. In C++ oder Java beispielsweise müssten all diese Objekte vom selben Typ abstammen oder auf denselben Typ gecastet werden, um dieselbe Funktion zu implementieren. Schon alleine für dieses Casten braucht man eine Kontrolle, etwa ein if-try-catch, für den Fall, dass etwas schiefgeht. Das alleine ist eine grosse Fehlerquelle. Des weiteren kennt Smalltalk nur fünf reservierte Schlüsselwörter, deren Bedeutung systemweit eindeutig und nicht veränderlich ist. Ausserdem kennt Smalltalk grundsätzlich keine Operatoren wie in anderen Sprachen. Das sind ganz einfache, normale Methoden, die man jederzeit überschreiben kann. Insgesamt zwei Ausnahmen gibt es (:= für die Zuweisung und ^ für die Werterückgabe). Das war es. Einsteigerfreundlicher geht es nicht mehr. Dagegen sind C++ und Java geradezu gespickt mit Ausnahmen. In C++ gibt es etwa 50 reservierte Wörter, ausserdem unterscheiden sowohl C++ als auch Java zwischen Objekten und Basistypen. Das macht Softwareentwicklung unnötig komplex. Diverse Studien bestätigen dass übrigens auch. Im Durchschnitt erzeugt ein Smalltalk-Entwickler bei der Implementation derselben Funktionalität nur ein Drittel der Fehler, die ein Java-Programmierer macht und nur ein Sechstel der eines C++ Programmierers. Ich kann Dir jedenfalls die echte objektorientierte Programmiersprache Smalltalk jedenfalls nur empfehlen... ;)
Für den sanften Eninstieg, versuch mal VB6. VB6 ist zwar Objektorientiert aber nicht besonders streng. Wenn du Zeit hast und Rom nicht in einem Tag erbauen willst, kann dir VB6 weiterhelfen.
Jetzt muß ich einfach noch einmal eingreifen,, nachdem ich lese, was hie
so alles geschrieben wird.
Generell kann ich Rufus nur beipflichten, er hat offensichtlich Ahnung,
von was er schreibt.
Man kann
- mit einer prozedural konzipierten Hochsprache (unter großen Umständen
auch mit Assembler) objektorientiert programmieren. Dafür stehen Bjarne
Stroustroup und C++, was so entstanden ist.
- mit manchen OO-Sprachen nahezu (99,999%, beliebig nach hinten
verlängerbar, je nach Umfang des Codes) prozedural programmieren, das
weiß ich aus eigener Erfahrung. Man packt in eine oder wenige Klassen
einfach unzählige Methoden und setzt sich mit OO einfach nicht
auseinander. Viellleicht deswegen, weil man es nicht bessser weiß.
Das letzte Wort über das bessere Konzept (man könnte es auch
geschwollenermaßen mit "Paradigma" ausdrücken) ist noch nicht
gesprochen.
Theoretisch ist der OO-Ansatz unserer natürlichen, objektorientierten
Anschauung näher als der abstrakte, prozedurale Ansatz.
Aber - abstrahiert nicht der Mathematiker ebenso Probleme durch z.B.
LaPlace-Transformationen oder einfach Logarithmen ("mal" wird zu
"plus")und kommt so schneller zu Lösungen?
Und sind "schlaue" Algorithmen (z.B. Quicksort) nicht eher etwas
Prozedurales?
Die Wiederverwendbarkeit von Objekten hat nicht dazu geführt, daß auf
einmal der neu entwickelte Code abnahm zugunsten bereits vorhandenen
Codes, den man (zum Teil) wiederverwendete - au contraire!
Ich glaube an eine Renaissance der prozeduralen Programmierung, gerade
in der Lehre und Forschung. In der Praxis lebt z.B. COBOL ohnehin immer
noch, wenngleich viele betriebswirtschaftliche Applikationen als solche
nur nicht mach außen so erkennbar sind: Unten COBOL, oben JAVA oder
C++.
Nach meiner bisherigen Erfahrung, die zwar noch nicht umfassend, jedoch
einschlägig ist, ist z.B. JAVA eine Ressourcenfresser. Erstens wegen des
OO-Ansatzes (z.B. die Polyphormie bläht zwangsläufig das Compilat auf),
zweitens - speziell bei JAVA - durch Fehlen der EXE.
Somit erwarte ich für die Zukunft eine Koexistenz von prozeduraler und
OO Programmierung.
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.