www.mikrocontroller.net

Forum: PC-Programmierung JAVA - Anfänger


Autor: Michael (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Christian (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Weihnachtsmann (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Michael (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
... ich dachte in JAVA kann man NUR Ob.Or. Programmieren ???

Michael

Autor: Weihnachtsmann (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Nein


Gruss

Weihnachtsmann

Autor: Rufus T. Firefly (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Michael (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
....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

Autor: Weihnachtsmann (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Rufus T. Firefly (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Au weia.

Autor: Michael (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Bitte -wenn möglich- das "Au weia" aufklären (so das es ein Anfänger
versteht)..

Danke

Autor: Tobi (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Weihnachtsmann (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: michael schmiady (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Rufus T. Firefly (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
"erschließt sich einem auf einmal der OO-Ansatz - unter der genannten
Bedingung, bereits prozedural programmieren zu können."

O ja.

Autor: Lex (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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 soll’s 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

Autor: Joachim (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@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.

Autor: Rufus T. Firefly (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ja, gebe ich offen zu.
Hat Smalltalk ausserhalb akademischer Hochburgen auch nur irgendeine
realitätsnahe Anwendung? Gar auf Microcontrollern?

Autor: Jochen (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
"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.

Autor: Jochen (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Lustig ist das:

http://www.huv.com/uSeeker/smalltalk/index.html

Für wahre Fans ;)

Autor: Rufus T. Firefly (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Thomas Faust (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Achim (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Dieter (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@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...
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... ;)

Autor: waldi (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: michael schmiady (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.
Hinweis: der ursprüngliche Beitrag ist mehr als 6 Monate alt.
Bitte hier nur auf die ursprüngliche Frage antworten,
für neue Fragen einen neuen Beitrag erstellen.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.