Buch-Empfehlung zum Einstieg in Java

P

ParachutePie

Neues Mitglied
Hallo liebes Java-Forum 🙂

Ich möchte anfangen Java zu lernen und wollte euch fragen ob ihr mir Buchempfehlungen aussprechen könnt. Habe bisher noch keine Vorerfahrungen in der Programmierung, bin daher ein blutiger Anfänger. Habe mich schon ein bisschen umgeschaut und es scheint ein relatives großes Spektrum an Einstiegslektüre zu geben. Bspw. hat das Buch: "Java von Kopf bis Fuß" sehr gute Rezessionen, jedoch weiß ich nicht wie aktuell dieses noch ist, da es auf Java 5 basiert (2006 veröffentlicht). Nun wollte ich wissen ob ihr mir irgendwelche Quellen empfehlen könntet um Java zu lernen. Bin hochmotivert und würde mich sehr freuen! 🙂

LG
 
Moin,
Nuiton hat gesagt.:
Macht wohl einen riesen Unterschied in diesem Thema welchen Begriff man benutzt
Zum Vergrößern anklicken....
nun ja, umsonst könnte man ja auch als vergeblich interpretieren 😀

Aber dafür halte ich Deinen Link (http://openbook.rheinwerk-verlag.de/javainsel/) für deutlich geeigneter, da er auf das Sprachgrundlagen-Buch verweist und nicht auf das spezielle Handbuch zu den Java SE-Bibliotheken !
Aber zum grundlgenden Einstieg sind die anderen von Dir genannten Bücher vlt. eh' eher geeignet als die die Insel, die IMHO eher ein Nachschlagewerk ist 🙂

Gruß Klaus
 
Ich habe vor kurzem auch mit solchen Büchern angefangen.
Java von Kopf bis Fuß ist nicht leicht zu schaffen (wenn überhaupt) ohne Vorkenntnisse.
Bediene dich da lieber mit dem Buch "Programmieren von Kopf bis Fuß" aus der Oreilly Buchreihe.
Danach kannst du Java von Kopf bis Fuß lernen.

Was in Java von [...] steht, ist zeitlos. Du kannst es in allen Versionen verwenden (laut oreilly.de Mail Support)

Nach Java von Kopf bis Fuß, könntest du der im Buch stehenden Empfehlung folgen und "Entwurfsmuster von Kopf bis Fuß" lesen, danach empfehle ich noch "Der Weg zum Java Profi" von Michael Inden, dpunkt Verlag.

Alles findest du auf Amazon.

PS: Rheinwerk Verlag Bücher mag ich überhaupt nicht. Die sind meiner Meinung nach nicht gut, und kommen an "Top-Bücher" wie Java von Kopf bis Fuß nicht ran.
 
Ist warscheinlich schon zu Spät, aber ich finde "Schrödinger programmiert Java" echt gut 😉
Ist zwar nur was für den Anfang, aber sonst echt super!
 
Hallo,
einige Fragen zum Buch BlueJ:
  • Ist der "Rote Faden" bei diesem Buch erkennbar, bzw. vorhanden?
  • Gibt es Aufgaben zum jeden Kapitel und wenn ja, sind diese mit dem bis zum Kapitel gelernten auch lösbar?
  • Bauen die Kapitel aufeinander auf?
  • Muss man für dieses Buch die Umgebung installieren oder geht es auch mit NetBeans z.Bsp?
  • Was beinhaltet die CD? (Habe gesehen, dass es Bücher mit und ohne gibt)
  • Gibt es ein Forum dafür?
Ich lese mich gerade in das Buch "Java ist auch eine Insel" und wie ich gesehen habe, gibt es
da keine Aufgaben. So suche ich ein Buch, welches das Gelernte anhand Aufgaben festigen soll.
 
Vielen Dank für die Antwort.
Mir sind zwei Punkte sehr wichtig: der rote Faden und die ausführlich dokumentierte Lösungen zu den moderat steigenden Aufgaben.
In welche Richtung will ich mich entwickeln: weniger Spiele, eher Programme wie Kochbuch oder ein Wörterbuch. Soweit ich beurteilen kann, sind dabei Klassen, Arrays, UI und Datenbanken Themen, die wichtig sind. Nun suche ich ein Buch, welches diese Gebiete sehr gut abdeckt, moderater Schwierigkeitsgrad und eben der rote Faden.
Ich finde Java-Insel, bis auf die fehlenden Aufgaben, eigentlich ganz gut. Bin mittlerweile
beim Ende des zweiten Kapitels angekommen, verstehe und kann 99% des gelernten
anwenden. Jetzt kommen Klassen und da wären paar Aufgaben zu den erwähnten Themen wirklich gut. Ein Tutorial ist ebenso herzlich willkommen, wie ein gutes Buch, jedoch habe ich
eher die Erfahrung gemacht, dass der Lernerfolg dabei eher kleiner ist, als bei einem Buch,
bin eine Leserate :-D

LG
 
Muss die Angabe korrigieren:
zum Buch "Java ist auch eine Insel" gibt es wohl Aufgaben samt Musterlösungen.
Für Verwirrung sorgt, es sind mehrere Bücher auf der Seite abrufbar und je nach dem, welche Auflage man
Aufruft, sind auch Lösungen dabei oder auch nicht.
Für die Interessenten:
diese Auflage bietet die Lösungen und Beispielprogramme als Download an.
http://openbook.rheinwerk-verlag.de...tml#dodtp26179a0a-2d10-4e6f-87d0-b41b72952492
 
Empfehlenswert ist ebenso ein Buch Grundkurs: Programmieren in Java http://www.grundkurs-java.de
Habe mir das Buch gekauft und bin bis jetzt bis auf eine Sache zufrieden. Das Buch ist sehr verständlich und einfach geschrieben. Jedes Kapitel hat ein Projekt, welches in diesem verfolgt wird. Zudem gibt es Aufgaben samt Lösungen,
Anzahl derer jedoch vom Kapitel zu Kapitel schwankt. Ebenso gibt es eine Ergänzung zum Buch als Download.
Habe mir das Buch als Bundle gekauft so dass ich ebenso zu PDF-Ausgabe etwas sagen kann. Die Formatierung ist nicht ganz gelungen, weil die PDF mehr in die linke obere Ecke "verschoben" ist. Tut der Sache kein Abbruch, aber ein Schönheitsfehler. Lässt sich mit jedem PDF-Reader öffnen. Das Buch selbst scheint ordentlich verarbeitet zu sein.

Was mich etwas stört: ich bin der Meinung, dass Fachliteratur frei von Genderdreck sein muss!
Ausdrucke wie "Programmierer bzw. Programmier_innen" oder "Entwickler bzw. Entwickler_innen"hatte ich zuhauf in meiner Jugend so dass ich der Meinung bin, dies gehört auf den Mühlhaufen der Geschichte und nicht in ein Fachbuch!
Davon wird die "Programmierer_in" auch nicht schlauer, spart euch die Tinte.
 
Javinner hat gesagt.:
Was mich etwas stört: ich bin der Meinung, dass Fachliteratur frei von Genderdreck sein muss!
Ausdrucke wie "Programmierer bzw. Programmier_innen" oder "Entwickler bzw. Entwickler_innen"hatte ich zuhauf in meiner Jugend so dass ich der Meinung bin, dies gehört auf den Mühlhaufen der Geschichte und nicht in ein Fachbuch!
Davon wird die "Programmierer_in" auch nicht schlauer, spart euch die Tinte.
Zum Vergrößern anklicken....
Überprivilegierter weißer Mann?
 
Auch wenn hier lange nichts mehr kam aber gute Buchempfehlungen grade als Anfänger sind wichtig, wenn ich in meiner Ausbildung gute bekommen hätte wäre wahrscheinlich einiges anders gelaufen. Das mit Abstand Beste für Anfänger ist die Von Kopf bis Fuß Buchreihe, weil sie neben dem reinen Wissen ein didaktisch sehr gutes Konzept.
Ich bin erst kurz vor Ende meiner Ausbildung auf das Buch Java von Kopf bis Fuß gestoßen, bis dato hatte ich die Objektorientierung trotz aller mühen nicht verstanden, nach ein paar Kapiteln in dem Buch war das kein Problem mehr. Mit ein wenig Übung danch habe ich diese dann im Tiefschlaf gekonnt.
Daher meine Empfehlung für Anfänger die Von Kopf bis Fuß Buchreihe. Allerdings wer jetzt anfängt dem würde ich von vornerein nicht mehr Java , sonder Kotlin von Kopf bis Fuß empfehlen. Anschließend evtl. auch noch Scala. Das ist die Zukunft!
Java wird nach und nach niemand mehr brauchen.
 
LimDul hat gesagt.:
Sicher? Ich sehe es anders - Kotlin oder Scala ist mir im Job noch nicht untergekommen 🙂
Zum Vergrößern anklicken....
Naja aber es ist faktisch so das sich speziell mit Kotlin (wenn man es kann) schneller Ergebnisse erziehlen lassen. Kotlin und Scala sind ja auch voll kompatibel mit Java-Code, weil letztlich wird alles in Java-Bytecode umgewandelt. Somit kann man auch ein bestehendes Java-Programm einfach mit Kotlin und Scala weiterentwickeln. Auch kann man Java Bibliotheken, von denen es ja mehr gibt, ohne Probleme einbinden.

Von daher hat es für die Praxis die vorteile das grade Kotlin leichter zu lernen ist, man keine Performance einbußen hat und man nicht eine Zeile seines bestehen Java Codes ändern muss. Und Kotlin ist die vorrangige Programmiersprache für Android Apps geworden.
Man kann sagen Kotlin hat alle Vorteile von Java, reduziert aber die Nachteile.
 
Ich sage nicht das Kotlin schlecht ist - nur so verbreitet ist es nicht. Insbesondere der größte Teil von Enterprise Anwendungen ist Plain Java - ohne Kotlin. Deswegen halte ich die Aussage für sehr gewagt.
 
Insbesondere wenn z.B. mal einigermaßen unabhängige Statistiken anschaut: https://www.jetbrains.com/de-de/lp/devecosystem-2023/languages/
Da stagniert die Kotlin Nutzung seit 2019 auf einen durchaus signifikanten Niveau - aber es gibt keine Anzeichen dass es irgendwann in den nächsten Jahren deutlich wachsen wird - genauso wenig wie es Anzeichen gibt, dass Java deutlich sinken wird.

Bei sowas gibt es viel mehr Faktoren als "Ich finde es besser". Da dreht sich die Welt langsamer - insbesondere hat Enterprise Software Lebenszyklen von 10+ Jahren - und neue Projekte werden da in Java gestartet.
 
LimDul hat gesagt.:
Ich sage nicht das Kotlin schlecht ist - nur so verbreitet ist es nicht. Insbesondere der größte Teil von Enterprise Anwendungen ist Plain Java - ohne Kotlin. Deswegen halte ich die Aussage für sehr gewagt.
Zum Vergrößern anklicken....
Gut ich bin mit Enterprise Anwendungen weniger vertraut, aber wenn ich es richtig weiß kann man auch bspw. wenn man das Java-EE oder Jakarta Framework nutzt auch trotzdem dann mit Kotlin aufsetzten, da wird man dann sehr wahrscheinlich beide Sprachen können müssen.

Ja die Aussage mit Kotlin ist vermutlich gewagt, aber wenn man in die Fachwelt schaut stehe ich damit nicht allein. 😉
Was auch für Endanwendungen große Marktanteile in Zukunft übernehmen dürfte FlutterFlow mit Dart als Programmiersprache sein, und Rust als C++ Ersatz/Ergänzung.
Algemein dürften speziell im Privatkundenbereich Desktopanwendungen zunehmend an Relevanz verlieren, immer mehr Haushalte haben gar keinen klassichen Desktop PC mehr.
 
TomBombadil hat gesagt.:
Gut ich bin mit Enterprise Anwendungen weniger vertraut, aber wenn ich es richtig weiß kann man auch bspw. wenn man das Java-EE oder Jakarta Framework nutzt auch trotzdem dann mit Kotlin aufsetzten, da wird man dann sehr wahrscheinlich beide Sprachen können müssen.
Zum Vergrößern anklicken....
Genau das passiert aber nicht. Siehe die Statistik oben. Die Nutzung von Kotlin stagniert seit 4 Jahren. Und warum soll eine Firma mit 50 Java Entwicklern ihre Software auf Kotlin anpassen? Das kostet erstmal massenhaft Geld.

Ja die Aussage mit Kotlin ist vermutlich gewagt, aber wenn man in die Fachwelt schaut stehe ich damit nicht allein. 😉
Zum Vergrößern anklicken....
Das wage ich zu bezweifeln. Ich finde auch andere Aussagen: https://shiftmag.dev/kotlin-vs-java-2392/

Nicht falsch verstehen - Auf Kotlin setzen ist mit Sicherheit nicht falsch. Aber ich sehe immer noch keine Belege, dass es Java in irgendeiner Weise gefährlich wird.
 
LimDul hat gesagt.:
Insbesondere wenn z.B. mal einigermaßen unabhängige Statistiken anschaut: https://www.jetbrains.com/de-de/lp/devecosystem-2023/languages/
Da stagniert die Kotlin Nutzung seit 2019 auf einen durchaus signifikanten Niveau - aber es gibt keine Anzeichen dass es irgendwann in den nächsten Jahren deutlich wachsen wird - genauso wenig wie es Anzeichen gibt, dass Java deutlich sinken wird.

Bei sowas gibt es viel mehr Faktoren als "Ich finde es besser". Da dreht sich die Welt langsamer - insbesondere hat Enterprise Software Lebenszyklen von 10+ Jahren - und neue Projekte werden da in Java gestartet.
Zum Vergrößern anklicken....
Die Übersicht die du geschickt hast ist echt cool, Danke!
Ich bin halt schon immer wieder ganz schön am schauen wo die Reise hin geht. Gehe dabei auch oft von dem Potenzial das ich in der einen oder anderen Technologie erkenne aus, daher dann so sachen wie

  • Kotlin voll Java kompatibel, starke Weiterentwicklung, Plattformübergreifend
  • Dart einmal entwickelt lässt es sich für alles kompilieren, native Desktopanwendung, virtual Maschine, Smartphone und webapp alles mit einer Entwicklung abgedeckt
  • Rust das viele altlasten von C++ behebt und in C++ integrierbar ist, sehr hohe performance grade für systemlastige Anwendungen hat

Das scheinen mir sehr vielversprechende Zukunftstechnologien zu sein

Rust und Dart sind grade erst im kommen, daher natürlich aktuell noch keine nennenswerte Verbreitung
Auch die Verbreitung von Java ist verständlich da viele Projekte darauf umgesetzt wurden, logisch es ist ja auch schon eine alte aber eben auch robuste Sprache.

Als ich meine Ausbildung gemacht habe war grade noch das letzte Jahr wo die Ausbildungsstätte Java unterrichtet hat , danach wurde auf C# umgestellt, weil es hieß Java braucht niemend mehr C# wird die Zukunft. Wenn man jetzt den Vergleich den du geschickt hast anschaut ist C# im vergleich Java nichts.
Man muss sehen wo es in der Praxis hingeht, da kommen ja noch mehr Parameter hinzu.
 
Also c# ist in meinen Augen sehr stark. Und im Projektgeschäft ist dies immer mehr am kommen was ich so bei unseren Kunden sehe. So haben wir jetzt auch .Net KnowHow bei uns aufgebaut.

Vor allem macht Microsoft hier einiges, was ich total vermisse:
  • Du hast auch die Cross Platform - nur eben ohne diese GraalVM / JPackage Problematik.
  • Das die Microservices dann plötzlich so gekommen sind, hat mich massiv lachen lassen. Das war von Anfang an das, was Microsoft propagiert hat. Da gab es dann WCF und so. Da. brauchte man nicht den ganzen "Mist" mit AppServer und so...
  • Total genial: .Net läuft auch im Browser. Wenn ich das richtig verstanden hatte, hatte da ein Besucher einer .Net Konferenz sowas einfach mal an einem Abend. gebaut als ersten Proof of Concept. Das ist ganz interessant und bringt dann tolle Möglichkeiten mit Blazor & MAUI und so.

Und technologisch ist .Net durchaus "up to date". Java rennt da massiv hinterher bei der Entwicklung und es tut sich nur sehr langsam was. Wobei da jetzt auch gute Sachen kommen. Die virtuellen Threads sind besser als dieses async / await das sich außerhalb der Java Welt ja durchgesetzt hat ...

TomBombadil hat gesagt.:
Java braucht niemend mehr
Zum Vergrößern anklicken....
Das sind immer lustige Aussagen. COBOL braucht bestimmt auch niemand mehr 🙂

Sorry, aber der Markt ist einfach da. Aber selbst das muss man nicht zu sehr beachten. Was bedeutet das denn?
Wenn etwas einen großen Marktanteil hat, dann bedeutet das doch nicht nur, dass es da viele Projekte oder Stellen gibt, sondern es gibt auch entsprechend viele Leute, die das bedienen.
Bei anderen Sprachen ist evtl. die Anzahl der Stellen kleiner, aber dafür machen das auch deutlich weniger Leute...
Daher drängt sich mir die Frage auf: Wo ist der wirklich relevante Punkt?

Und egal, was man macht: Du lernst objektorientierte Entwicklung. Egal, welche Sprache du nutzt: Du solltest in der Lage sein, jede andere Sprache schnell zu lernen. Die Konzepte sind doch alle gleich! Da ist es egal, ob ich Java, Kotlin, dart, C#, ... mache.
 
KonradN hat gesagt.:
Und egal, was man macht: Du lernst objektorientierte Entwicklung. Egal, welche Sprache du nutzt: Du solltest in der Lage sein, jede andere Sprache schnell zu lernen. Die Konzepte sind doch alle gleich! Da ist es egal, ob ich Java, Kotlin, dart, C#, ... mache.
Zum Vergrößern anklicken....

Leider fehlt mir auch bisschen die praktische Projekterfahrung, daher kann ich immer nur mit dem arbeiten was ich so recherchiere. Der Austausch der sich hier grade ergibt ist super!

Und prinzipiell ist es richtig wenn man eine Sprache kann bekommt man andere recht schnell auch hin. Ich habe aus Gründen des Betriebes in dem ich war VB und Lotus-Script gelernt . VB um Excel Makros zu entwickeln da der Kunde es gerne auf Excel-Basis haben wollte. Aber auch das hat geklappt, wobei ich in die VB-Objektorientierung nicht so sehr eingestiegen bin, die finde ich ist recht umständlich.

Was ich allerdings auch immer wieder lese ist das die Objektorientierung algemein nicht mehr so gefragt sein soll und mehr durch funktionale Ansätze als auch Microservices ersetzt werden soll?
KonradN hat gesagt.:
Sorry, aber der Markt ist einfach da. Aber selbst das muss man nicht zu sehr beachten. Was bedeutet das denn?
Wenn etwas einen großen Marktanteil hat, dann bedeutet das doch nicht nur, dass es da viele Projekte oder Stellen gibt, sondern es gibt auch entsprechend viele Leute, die das bedienen.
Bei anderen Sprachen ist evtl. die Anzahl der Stellen kleiner, aber dafür machen das auch deutlich weniger Leute...
Daher drängt sich mir die Frage auf: Wo ist der wirklich relevante Punkt?
Zum Vergrößern anklicken....

Bei den Betrieben und Stellenausschreibungen die ich so sehe werden meist Java, Kotlin, C# uvm. Spezialisten gesucht, sprich man bekommt meist keine Zeit zugestanden das für den Betrieb relevante noch zu lernen. Und einfach mal alles zu lernen ist praktisch nicht möglich.
Der relevante Punkt scheint das was grade verlangt wird gut bis perfekt zu können, keine Zeit für Einarbeitung. So mein Eindruck bei meiner Stellensuche.
 
TomBombadil hat gesagt.:
Was ich allerdings auch immer wieder lese ist das die Objektorientierung algemein nicht mehr so gefragt sein soll und mehr durch funktionale Ansätze als auch Microservices ersetzt werden soll?
Zum Vergrößern anklicken....
Hier muss man aufpassen, dass man Dinge nicht durcheinander wirft.

In der Aufzählung hast Du zwei Programmier-Paradigmen: Objektorientiert und Funktional:
Generell haben die (modernen) objektorientierten Sprachen alle auch funktionale Ansätze. Lambda Expressions und so sind einfach Standard und gehören dazu. Aber Du hast halt weiterhin die Objektorientierung und die bildet die Basis. Prinzipiell braucht man das nicht - riein imperativ ginge es auch. Ich meine go geht so einen Weg, oder?

Microservices ist dem gegenüber aber einfach ein Ansatz bei der Architektur. Das ist also eine andere Thematik.

TomBombadil hat gesagt.:
Bei den Betrieben und Stellenausschreibungen die ich so sehe werden meist Java, Kotlin, C# uvm. Spezialisten gesucht, sprich man bekommt meist keine Zeit zugestanden das für den Betrieb relevante noch zu lernen.
Zum Vergrößern anklicken....
Ja, das ist durchaus richtig. Aber niemand hindert Dich daran, Dich weiter zu bilden. Ganz im Gegenteil: Ohne ständige Weiterbildung hast Du in diesem Marktbereich keine Chance. Zum einen musst Du Dein Themengebiet meistern (und da kommt ja auch ständig irgendwas Neues!) und zum anderen kannst Du Dich verändern.
 
TomBombadil hat gesagt.:
Objektorientierung ... funktionale
Zum Vergrößern anklicken....
Unabhängig vom Paradigma soll(te) man den Code so konzipieren, dass das Lesen / Verstehen / (häufige(re)) Ändern (Anm.)/ Erweitern (Anm.) / ... des Codes aus menschlicher Sicht erleichtert wird. Eine Sprache bis ins letzte (Leistungs-)Detail zu kennen, ist da eher sekundär (wenn auch nicht falsch).

(Anm.) diese Aktivitäten -egal ob rein menschlich ("agile Methodik") oder (komplett) automatisiert (z.B. via CoPilot) durchgeführt- können (im Schnitt und aus Vogelperspektive) aber auch zu einer schlecht(er)en Code-Qualität führen. Quellen: Bericht bei Heise // Bericht bei dotnetpro
 
M.L. hat gesagt.:
Eine Sprache bis ins letzte (Leistungs-)Detail zu kennen, ist da eher sekundär (wenn auch nicht falsch).
Zum Vergrößern anklicken....
Hier bin ich zwiegespalten.

Natürlich macht es keinen Sinn, Sprachfeatures auf Zwang zu nutzen. Ich denke, da müssen wir nicht diskutieren, weil da Einigkeit besteht.

Aber die Sprachfeatures gibt es ja aus gutem Grund. Diese sollen Code in der Regel vereinfachen und damit eben lesbarer machen.

Daher hindert man sich selbst daran, guten Code zu schreiben durch eine Form der Ignoranz (So nenne ich es einfach einmal).

Gerade in der Software Entwicklung ist es ein ständiges Lernen. Ein ständiger Austausch. Das macht den Beruf so interessant. Und die Sprachfeatures sind die absolute Grundlage, auf der wir arbeiten. Die sollte man schon kennen.
(Wobei manche Details, die wirklich eigentlich nie vorkommen, evtl. vernachlässigbar sind. Was hatten wir mal im Forum? Eine Innere Klasse innerhalb einer Methode? Das hatte ich damals nicht auf dem Schirm 🙂 )
 
TomBombadil hat gesagt.:
Ja die Aussage mit Kotlin ist vermutlich gewagt, aber wenn man in die Fachwelt schaut stehe ich damit nicht allein. 😉
Zum Vergrößern anklicken....
Ich arbeite in einem Weltweit tätigen Konzern. Wir haben fast unsignifikant viele Kotlin Projekte. Meist gerade um zu prüfen, ob das sinnvoll ist oder nicht.

Wenn ich nun so ein Enterprise Projekt ansehe: Da möchte ich auch gerne die Anzahl verwendeter Sprachen auch so klein wie notwendig halten. Die Kosten für solche komplexen Projekte würden deutlich steigen. Und am Ende ist es Byte code.

Würde mich auch technisch kaum überzeugen. Hat mich bisher auch keiner versucht zu überzeugen weder aus Business noch technischer Sicht.

Die gezeigten Statistiken sagen: Man sollte es kennen, beobachten und ggf. Bereit sein es anzuwenden.

Aber Java ist extrem verbreitet. Und ich denke auf dem absteigenden Ast ist da nix.
TomBombadil hat gesagt.:
Was ich allerdings auch immer wieder lese ist das die Objektorientierung algemein nicht mehr so gefragt sein soll und mehr durch funktionale Ansätze als auch Microservices ersetzt werden soll?
Zum Vergrößern anklicken....
Ich finde es extrem verwirrend woher solche Aussagen kommen. Ich bin jetzt stark Java fixiert. Und habe auch seit über 8 Jahren kein Profi Java entwickelt.

Aber ich denke ohne OOP geht es nicht. Habe dafür keine Statistik. Aber dafür sehe ich was in den Projekten gemacht wird. Und das auch in einer tiefen technischen Weise.
 
Bzgl. OOP. Was sich mittlerweile als Einsicht durchgesetzt hat, ist glaub ich "Composition over Inheritance". Das heißt, dass man lieber "Objekte" zusammensteckt, als größere Ableitungshierarchien zu bauen. In der Hinsicht kann man sagen, ist OOP "weniger" geworden - sofern man OOP auf Ableitungen reduziert. Die anderen Grundsätze von OOP - wie Kapselung von Informationen, Kommunikation nach außen nur über definierte Schnittstellen sind aktueller denn je. Denn wenn man sich mal eine Microservice Architektur anschaut - was hab ich da? Komponenten die über definierte Schnittstellen miteinander kommunzieren. Genau das, was man mit Klassen im kleinen bei OOP genau so macht. Es gibt halt Stellen, wo durch die funktionalen Aspekte, die Gott sei Dank in Java mit reingekommen sind, man weniger Klassen braucht (ich denke da vor allem an die funktionalen Interfaces).

Von daher würde ich OOP immer noch für hochaktuell halten - nur sind manche Aspekte von OOP in den Hintergrund getreten (Ableitungen) und dafür andere stärker in den Vordergrund (Entkoppelung).
 
Marinek hat gesagt.:
Aber ich denke ohne OOP geht es nicht. Habe dafür keine Statistik. Aber dafür sehe ich was in den Projekten gemacht wird. Und das auch in einer tiefen technischen Weise.
Zum Vergrößern anklicken....
Ich fürchte wir entfernen uns hier recht stark vom eigentlichen Topic und evtl. wird es Zeit, dass ich mal schaue, wie ich Posts abtrennen kann in einen eigenen Thread 🙂

Aber wozu braucht man noch OOP? Wenn ich mir so eine typische Spring Anwendung in diversen Blogs ansehe, dann ist da nichts, wo zwingend OOP verwendet werden müsste:
Da ist ja die Aufteilung meist etwas wie:
  • Entities - das könnten auch Strukturen sein. Wirkliches Verhalten gibt es da meist nicht mehr.
  • Controller - das ist halt eine Außenschnittstelle - das braucht kein OOP was man ja auch erkennt, wenn da nur eine Annotation auf der Klasse ausreicht...
  • Services - die Business Logik ist hier ja schon oft getrennt. Das ist also eigentlich schon eine Art Anti Pattern. Etwas, das man nicht machen soll. Die Services sind eine Art "Controller, die Entities von außen steuern". Das Verhalten ist also nicht mehr objektorientiert in den Entities sondern es ist herausgezogen. Du hast damit also etwas wie "Gott Klassen". Nicht die Klasse User bestimmt, was für ein Verhalten der User hat, sondern der UserService, der macht alles. Der bestimmt, dass ein Passwort eine gewisse stärke haben muss oder so ....

Und man mus shier nur go / golang ansehen, welches sich von OO auch sehr gut entfernt hat:

Frequently Asked Questions (FAQ) - The Go Programming Language

go.dev go.dev
 
KonradN hat gesagt.:
Services - die Business Logik ist hier ja schon oft getrennt. Das ist also eigentlich schon eine Art Anti Pattern. Etwas, das man nicht machen soll. Die Services sind eine Art "Controller, die Entities von außen steuern". Das Verhalten ist also nicht mehr objektorientiert in den Entities sondern es ist herausgezogen. Du hast damit also etwas wie "Gott Klassen". Nicht die Klasse User bestimmt, was für ein Verhalten der User hat, sondern der UserService, der macht alles. Der bestimmt, dass ein Passwort eine gewisse stärke haben muss oder so ....
Zum Vergrößern anklicken....
Spannender Punkt, insbesondere wenn ich da mal auf unsere Anwendung schaue. Den sehe ich Teile, die deine Aussage stützen und teile die ihr widersprechen 🙂

Unsere Entitäten werden tatsächlich zum Großteil über Operations von außen gesteuert. Das heißt, sie haben selber kein Verhalten.
Auf anderen Seite stellt sich die Frage "müssen" sie ein Verhalten haben? Ist dieses Verhalten überhaupt eine Eigenschaft die an die Entität gehört? Oder ist nicht nur die Kombination aus Operation + Entität das Tupel, was das Verhalten definiert? Was unsere Entitäten aber haben, ist die Möglichkeit selber Grenzen und Konsistenz zu definieren. Jede Entität definiert selber, wann sie konsistent ist. Das heißt z.B. sie definiert welche Wertebereiche Attribute haben, welche Einschränkungen gelten müssen etc. Die Operations müssen nun selber sicherstellen, dass diese Konsistenz erreicht wird. Ist das noch OOP? Ich weiß es nicht, aber es fühlt sich gut an. Insbesondere hält es die Klassen handlebar - den ansonsten würden die Entitäten code-technisch explodieren.

Wenn ich mir unsere UI-Elemente anschaue, dann sind die klassisch OOP. Die definieren komplett ihr Verhalten und Zustand (Was wird angezeigt, wann wird es angezeigt, wie wird es angezeigt).

Ich glaube die Grenzen verschwimmen zunehmend - was per se erstmal weder gut noch schlecht ist. Ich mag keine dogmatischen Regeln - am Ende will ich ein wartbare, testbare & verständliche Anwendung haben.
 
LimDul hat gesagt.:
Spannender Punkt, insbesondere wenn ich da mal auf unsere Anwendung schaue. Den sehe ich Teile, die deine Aussage stützen und teile die ihr widersprechen 🙂
Zum Vergrößern anklicken....
Ja, ich habe das (absichtlich) sehr einseitig und auch etwas provokant ausgedrückt.

Hier geht es ja um eine Anwendung, die sich auf die Daten konzentriert. Diese Entities sind unter dem Strich ja nur DTOs. Da will man oft auch kein wirkliches Verhalten haben.
Das, was man als Verhalten von Entities sehen kann, kann man auch schlicht anders sehen: Als reine Business Logik. Und diese wird dann natürlich auch entsprechend implementiert. Die Sichtweise ist also tatsächlich mehr auf den Business Regeln. Und diese sind sehr oft Entity übergreifend. Es gibt also auch oft aus fachlicher Sicht eine ganz andere Sichtweise und es wird da sehr selten wirklich "objektorientiert" geschaut.

Schlechtes Beispiel, da ich jetzt von der Daten-Zentrierten Anwendung weg gehe, aber es macht es evtl. dennoch deutlich:
Ein Ingenieur, der einen Motor baut, der wird Bauteile sehen, aber der wird denen kein eigenes Verhalten zuordnen. Dann wird das Ventil von außen gesteuert. Sei es, dass eine Motorsteuerung ein Signal zur richtigen Zeit gibt und dieses Signal dann irgendwas bewirkt oder dass da eine Kette bei der Bewegung der Kurbelwelle dann auch die Ventile betätigt.

Das kann man dann (meiner Meinung nach) auch etwas bei Microservices sehen. Man hat dann ja Microservices für irgendwas. Also einen Microservice für A, einen für B und einen für C. Die verwalten diese und ich kann CRUD Operationen darauf machen. Es gibt minimale Logik also vermutlich nur, dass bei A der Name nicht null sein darf oder so in der Art.
Darauf gibt es dann Services, die mit den Services von A, B und C etwas machen. Wenn also ein bestimmter Auftrag von außen kommt, dann wird geschaut: Was gibt es bei A, was gibt es bei B. Dann wird evtl. ein C neu angelegt und es werden die Elemente in A und B angepasst. Es gibt halt da eine klare Business Regel, was da passieren soll. Und das kann hier ja nur außerhalb liegen. Das kann (oft) kein Verhalten sein, dass bei A, B oder C implementiert ist. Denn es gibt halt die entsprechende Trennung weil A, B und C sind evtl. Services von unterschiedlichen Abteilungen und die Business Regel oben drüber kommt von einer Fachseite, die nur auf diese Basis aufsetzt .... Macht das etwas Sinn? Oder rede ich hier wirr und bin evtl. auf dem ganz falschen Dampfer auf dem Weg zum nächsten Eisberg?
 
LimDul hat gesagt.:
Unsere Entitäten werden tatsächlich zum Großteil über Operations von außen gesteuert. Das heißt, sie haben selber kein Verhalten.
Zum Vergrößern anklicken....
Entities sind schlicht Datenstrukturen, deren einzige Aufgabe darin besteht, Daten zu halten. Mischt man nun Methoden rein, die fachlich relevanten Code enthalten, bekommt man m. E. das, was RCM in Clean Code als "Hybrid" bezeichnet: "Such hybrids make it hard to add new functions but also make it hard to add new data structures. They are the worst of both worlds."
 
KonradN hat gesagt.:
Denn es gibt halt die entsprechende Trennung weil A, B und C sind evtl. Services von unterschiedlichen Abteilungen und die Business Regel oben drüber kommt von einer Fachseite, die nur auf diese Basis aufsetzt .... Macht das etwas Sinn? Oder rede ich hier wirr und bin evtl. auf dem ganz falschen Dampfer auf dem Weg zum nächsten Eisberg?
Zum Vergrößern anklicken....
Das Thema finde ich spannend. Hast Du da mal ein Beispiel? Ich glaube, ich habe da eine völlig andere Sichtweise 😲
 
mihe7 hat gesagt.:
Das Thema finde ich spannend. Hast Du da mal ein Beispiel? Ich glaube, ich habe da eine völlig andere Sichtweise 😲
Zum Vergrößern anklicken....
Ich habe das mal in ein Gespräch verlagert, da ich gewisse Dinge nicht direkt öffentlich machen möchte, die ich Dir als Details nenne.

(Edit) Die Idee ist dabei, ggf. eine kurze Zusammenfassung dann am Ende auch wieder im Thread zu posten - so in dem Gespräch interessante Punkte aufkommen.
 
Ich ignoriere TomBombadil mal kackedreist (nichts für ungut, tschuldigung) und schreibe hier weiter, irgendwann wird KonradN ja bestimmt mal herausgefunden haben wie man Threads auseinanderschnippelt.

LimDul hat gesagt.:
Von daher würde ich OOP immer noch für hochaktuell halten - nur sind manche Aspekte von OOP in den Hintergrund getreten (Ableitungen) und dafür andere stärker in den Vordergrund (Entkoppelung).
Zum Vergrößern anklicken....
Ich habe es leider selber noch nicht ausprobieren können, sondern weiß es nur von einem Kollegen, aber Rust geht da einen recht interessanten Weg. Typische Klassen gibt es da, so habe ich es jedenfalls verstanden, nicht mehr.
Wenn man in Rust dann z.B. eine "Dateninstanz" (oder wie auch immer die das genannt haben) einer Methode als Parameter übergeben will, definiert man in der Methode nicht von welcher Art diese Dateninstanz sein soll, sondern welche Eigenschaften sie haben muß.

Also nehmen wir beispielsweise mal an, man habe (in Java) eine Klasse für Landfahrzeuge wie Car, Truck, und Bycicle. Nun übergebe man einer Methode wie z.B. void move(Landvehicle vehicle) ein Landvehicle-Objekt.
In Rust würde man eine Methode dann so deklarieren daß man ihr alles übergeben kann, was man bewegen kann. Keine Ahnung wie das deklariert wird, ich habe mich damit wie gesagt noch nicht befassen können, kann es aber kaum erwarten es mal zu probieren. C macht wirklich keine Freude, und C++ auch nicht.

Interessanterweise fehlt zumindest in der deutschen Wikipedia 'objektorientiert' in der Paradigmenauflistung:
de.wikipedia.org

Rust (Programmiersprache) – Wikipedia

de.wikipedia.org de.wikipedia.org
 

Aktuelle Jobs

Neue Themen

Ähnliche Themen

[Empfehlung gesucht] Einstieg für 2D Spieleprogrammierung
Antworten: 6
java buch empfehlung
Antworten: 4
Empfehlung Java Buch für Programmdesign
Antworten: 7
Buch empfehlung?
Antworten: 10
[Suche] Buch Empfehlung für JUnit
Antworten: 4

Zurück
Oben