Seitdem ich euren Kanal entdeckt habe, kann ich nicht mehr aufhören eure Videos zu schauen :D Das liegt glaube ich vor allem an Ihnen Herr Roden, Ihre ruhige, fachlich kompetente, aber kurze und knackige Art Sachen zu erklären! Auch begrüße ich die Philosophie Ihrer Firma, mit Software etwas gutes zu tun und den Alltag von Menschen zu erleichtern, sehr! Zu Ihrer Frage: Ich kann das voll und ganz unterschreiben, dass z.B. in der Ausbildung OOP als der heilige (und einzige) Gral dargestellt wird. Wir hatten hauptsächlich JAVA und noch ein bischen C++ auf dem Lehrplan. Es war genau so wie in diesem Video beschrieben. Man sollte sich alles als Objekt bzw. Klasse vorstellen (erklärt an unseren Tischen und Stühlen), vererben, überladen und so weiter. Das schlimme ist, dass ich damals das Gefühl hatte, dass das alles absolut Sinn ergibt und ich bin an jedes Problem so ran gegangen und mir hat das sogar großen spaß gemacht. Ich habe damals gesagt JAVA ist meine Lieblingsprogrammiersprache und OOP ist das Beste! Jetzt, wo ich mehrere Jahre in einer IT-Firma arbeite, kann ich nur sagen: Hahahaha, was war ich jung und dumm :D Wir haben z.B. eine Desktop Anwendung mit .NET (C#) entwickelt und wir haben uns am Tag mehr gedanken über Klassennamen, Überladung, Vererbung oder Kapselung gemacht und tausende von Methoden/Klassen in der Standardlib nach etwas gewünschtem durchsucht, als unseren Code zu schreiben. Mittlerweile entwickeln wir Desktopanwendungen mit einer Eigenentwicklung wo ich (noch) nicht drüber sprechen darf, aber ich kann sagen, dass wir KEINE OOP mehr verwenden :) Wo ich ein bisschen mehr sagen kann ist z.B. bei der Serverseitigen Entwicklung. Dort haben wir eine Zeit lang auch mit .NET (C#) entwickelt und was uns neben dem Overhead bei OOP entwicklung auch noch aufgefallen ist: diese heiligen Gral OOP Sprachen wie C# und JAVA sind bis zu hunderten MB groß und aufgrund ihres JIT-compilers nicht die schnellsten bei z.B. der startup time. Und eine VM muss der Kunde auch noch installieren, absolute HÖLLE! Ja es gibt auch OOP Sprachen wie C++, welche AOT compiled werden und wie C nur wenige MB groß sind (wenn überhaupt) aber C++ ist unserer Meinung nach einer der schlimmsten Sprachen überhaupt (massiv überladen, veraltet, makefile, kurz -> nicht spaßig). Long story short: Auf der serverseitigen Entwicklung waren unsere Bedingungen für die neue Sprache der Zukuft: AOT, single file executables, einfache crosscompilation, KEIN OOP, gutes Tooling, Spaß, einfach zu lernen. Und so sind wir nun bei GO (Golang) gelandet, sehr zufrieden und das beste Maskotchen der Welt gabs sogar noch kostenlos obendrauf :D P.S: Es kann kein Zufall sein, dass neue Hypesprachen wie Go und Rust (fast) komplett auf OOP paradigmen verzichten!

@thenativeweb

Жыл бұрын

[gr] Vielen Dank für Deine ausführliche Schilderung Deiner Erfahrungen! 😊 Deinem PS kann ich nur zustimmen - und unabhängig davon ist es amüsant, dass Ihr mit sehr ähnlichen Argumenten wie wir auf Go gestoßen seid. Unsere Gründe / Argumentation findest Du übrigens unter kzread.info/dash/bejne/qZdpw8auZpafZqQ.html 😉

Grandioser Content - dieser Kanal ist krass unterbewertet

Lieber Golo und liebes Team bei the native web, erst einmal vielen, vielen Dank für eure Videos - ihr seid tief im Thema drinnen, man merkt, dass ihr verinnerlicht habt, das hohe interne Codequalität ein wichtiges (oder gar das wichtigste) Merkmal von hoher wahrgenommener Softwarequalität ist. Man kann eigentlich jedes eurer Videos empfehlen. Zum Thema: du hast vollkommen Recht, wir haben ein großes Problem bei der Ausbildung von neuen Softwareentwicklern. Viele wichtige, fortgeschrittene Themen wie "wo und wie setze ich Vererbung und Polymorphie ein, damit ich daraus einen Mehrwert bekomme, anstatt am Ende bei einer schwierig zu wartenden Codebasis mit hunderten, wenn nicht tausenden von Interfaces zu landen" kommen weder bei der Ausbildung von Anwendungsentwicklern noch im Studium an Unis und Hochschulen gezielt vor. Als Arbeitgeber lassen wir Coding Challanges von Bewerberinnen und Bewerbern machen, weil wir nur so herausfinden, wie die entsprechenden Personen Code einsetzen und ob sie gar "ideologisch" in einem gewissen Programmierstil gefangen sind. Wir können uns nicht darauf verlassen, dass solche Sachen explizit und im ausreichenden Umfang gelehrt werden. Das Wichtigste, was man jungen Entwicklern kurz und prägnant mit auf den Weg geben sollte: alles ist nur ein Tool. Widersetze dich Hypes von neuen Technologien, Libraries/Frameworks, Programmiersprachen. Studiere unterschiedliche Dinge genau und nimm sie in deinen Werkzeugkasten mit auf. Wenn du dann vor einem (wahrscheinlich nicht trivialen) Problem stehst, setze aus deinem Werkzeugkasten genau die Teile ein, die dir eine möglichst einfache Lösung ermöglichen. Wichtig: lerne dabei, wie die Dinge intern funktionieren, auf die du aufbaust (Programmiersprachen und Compiler, Runtimes und deren Komponenten wie GC/JIT, Frameworks und Libraries), damit du mit Ihnen und nicht gegen sie entwickelst.

@devchannel5232

2 жыл бұрын

Wahnsinn, über Kenny's Vorlesungen habe ich Programmieren angefangen xD danke dafür!

@IAmFeO2x

2 жыл бұрын

@@sven2529 Wir haben interne Schulungen, Code Reviews und Retrospektiven als Mechanismen, bei denen Mitarbeiter sich weiterbilden können. Nichtsdestotrotz sollte sich jeder Entwickler auch an der Ehre gepackt fühlen, sich selbst weiterzubilden und weiterzuentwickeln. Weiterbildung sollte nicht nur von der Unternehmensseite ausgehen. Weiterhin arbeiten wir in einem Metier, dass deutlich über dem normalen Einkommensniveau liegt. Gerade Absolventen von Unis und Hochschulen wollen direkt mit einem hohen 5-stelligen Gehalt einsteigen - warum sollten wir dann nicht über Coding Challenges sicherstellen, dass sie eine bestimmte Basis an Wissen und Lösungsfähigkeit mitbringen? Wer in andere hochrangige, gut bezahlte Stellungen will, muss z.T. mehrtägige Assessment Centers meistern.

@VitalijMik

2 жыл бұрын

@@IAmFeO2x einerseits finde ich es richtig dass ein Entwickler sich auch in seiner Freizeit fortbilden soll, auf der anderen Seite finde ich es im Vergleich zu anderen Berufen Unfair. Meine Frau arbeitet im Öffentlichen Dienst, nur weil die eine Software Umstellung hatten, wurden die erstmal schön an die Ostsee eingeladen und mussten eine Woche über die Neurungen lernen. Eine Bekannte arbeitet bei der Versicherung, auch die hatten eine Fortbildung übers Wochenende in einem schicken Hotel. Ich hatte zwar auch Konferenzen besucht und hier und da paar tools kennengelernt aber es gab halt nie wirklich so eine Konkrete Schulung die wirklich was mit der Arbeit zu tun hatte. Meistens nur irgendwas allgemeines. Irgendwie heißt es in unserem Beruf Friss oder Stirb. Als ich Jünger war habe ich auch gerne mich nach der Arbeit hingesetzt und neue Tools und Frameworks kennengelernt und paar kleinere Projekte umgesetzt, wenn man aber irgedwann Familie und Häusliche Pflichen hat ist es dann schon schwieriger. Leider wird diese Information an neue Entwickler nicht weitergegeben. Man zeigt nur auf wie Cool es doch ist ganzen tag zu "Proggen" :D

@marcusreinicke

2 жыл бұрын

@@VitalijMik ich denke, dass wir als Softwareentwickler einen Job haben, wo lernen Pflicht ist. Und das bis ins hohe Alter. Wir haben uns den Job ausgesucht. Mir war von Anfang an klar, dass es so ist. Es ist anders als im öffentlichen Dienst. Da muss man Grundfertigkeiten eines Berufs mitbringen und das Unternehmen kennen lernen. Bei uns Entwicklern ist es anders. Die Fertigkeiten müssen auf dem Laufenden gehalten werden und alles was mit der Firma zu tun hat. Daher kann man das schlecht vergleichen. Was mir im Moment aufgefallen ist, ist, dass die Schlagzahl sich erhöht hat. Die Frequenz der neuen Frameworks und Spracherweiterungen hat zugenommen.

@VitalijMik

2 жыл бұрын

@@marcusreinicke ich rede nicht über Lernen vs nicht lernen. Lernen ist ja ein Spektrum. Als ich noch 25 war, konnte ich mich nach der Arbeit noch hinsetzen und an eingenen Projekten arbeiten und neue Sprachen und Tools kennen lernen. Als ich ein Haus gebaut habe, blieb da kaum noch zeit zu. Mit Kindern muss man das auch gößtenteils einschränken. Mit dem Alter hast du auch andere Prioritäten. Was ist wichtiger? Das neue Framework? oder deine Kinder zu erziehen und zeit mit ihnen Verbringen? Und das empfinde ich als Unfair in unserem Beruf. Selbst wenn wir schulungen zu einem Tool kriegen würden, ist die schulung nie gezielt so dass es uns direkt auf der Arbeit was bringt. Dann fragt man sich ob man so eine Schulung in erser Linie überhaupt braucht. Bis ins hohe Alter lernen wird man sowieso, das tut man auch in anderen Berufen, auch im öffentlichen Dienst, die Gesetze verändern sich ja auch von Jahr zu Jahr und somit auch die Arbeitsweise. In allen Berufen muss man immer up-to-date sein. Der Unterschied ist dass die Unternehmen in anderen Berufen gezielt helfen während bei uns nur allgemein. (Ah hier auf YT 80 Minuten Docker Video, nun stelle unsere komplette infrastruktur um in einer woche :D und es soll sicher sein ohne bugs und downtimes) Und mir war das so nicht klar. 2004 Kannte ich keinen einzigen IT-ler in meiner Umgebung ich konnte mit niemanden Reden und selbst wenn jemanden hätte, dann hätte er auch keine 10 Jahre Berufserfahrung um über den Beruf zu sprechen aus langjähriger Sicht.

Kenntnisse von vielen Paradigmen haben und abwägen können... PERFEKTE EMPFEHLUNG Leute nimmt euch seine Worte zu Herzen. Ich bin großer "OOP-Fan" und muss mir viel unsinnige Kritik zu OOP anhören, aber was Golo erzählt sind definitiv konstruktive und korrekte Kritikpunkte und Empfehlungen. Das ist keines von diese: "Darum ist OOP schlecht und unbrauchbar" Videos. Es ist immer wichtig abzuwägen und begründen können warum man dieses oder jenes Paradigma, Pattern oder Sprache für das AKTUELLE Problem auswählt. Es ist dabei nicht mal wichtig immer die perfekte Auswahl zu treffen, das zu versuchen ist wiederum ein Fehler. Es ist wichtig bewusst zu wählen, zu reflektieren und aus den Problemen zu lernen. Wer ultimative Antworten hat, der liegt ultimativ daneben.

Ich verfolge eure tollen neuen Konzepte seitdem ich aus meinem betrieblichen Dornröschenschlaf in das Neue gekommen bin. Und Du spricht mir aus der Seele, wg. OOP war auch Speicherplatz /Performance. Da werden aber keine neuen Framework gehimmelt.

Als erfahrener Java Entwickler stimme ich dem zu. Gerade die neuen Java Versionen entfernen sich mehr und mehr von der Vererbung oder führen neue Konstrukte ein um dieses "Problem" besser in den Griff zu bekommen. Siehe Sealed Classes. In modernen Web Applikationen erstellt heute keiner mehr Klassenhierarchien. Alles muss klein, zustandslos, funktional sein. Aus Performance- und Speichergründen. Weiterer Punkt gegen Vererbung ist die Undurchsichtigkeit. Es macht überhaupt keinen Spaß Code zu debuggen, der auf zig Ebenen verteilt ist. Vererbung findet hauptsächlich im Framework-Code seine Existenzberechtigung. Und die, die Framework Code schreiben, wissen meist auch richtig damit umzugehen.

@j.metzger1730

2 жыл бұрын

Ich find nur interessant, wie viele Videos neuerdings auftauchen und mit absoluter Überzeugung meinen, OOP ist generell schlechter als funtional o.ä.. Nicht dieses Video jetzt hier und auch nicht du, aber trotzdem beobachte ich es. Aber wenn man dann sich etwas komplexere Software anschaut, fast jede library usw., benutzt OOP (selbst C Code, wo natürlich mehr selber gemacht werden muss). Die Videos kritisieren immer diese simplen "hallo-world" ähnlichen Programme, wie ein geometrisches Objekt. Ja haben wir auch im Studium so gelernt, weil es ein einfaches Beispiel ist, sich an OOP zu gewöhnen. Es hat aber keiner im Studium gesagt, dass OOP immer brauchbar ist. Ich würde mir mal ein Video wünschen, wo mal eine komplexere Software angeschaut wird, bei der OOP mit funktional verbunden wird und Hand in Hand arbeiten und daran zeigt wann OOP genutzt werden sollte und wann funktional usw. Aber nochmal, dieses Video war sehr balanciert, eine Seltenheit bei OOP vs. Funktional Diskussionen.

Super Video! 👍Das Problem ist, dass in der Schule/Uni meistens nur OOP gelehrt wird und zudem als DER Weg beschrieben wird. Viele Programmiersprachen wie C# oder Java sind schon so konzipiert, dass man sinnvoll nur objektorientiert entwickeln kann. Mich hat die aus meiner Sicht recht bescheidene, prototypbasierte Vererbung von Javascript zu Composition over Inheritance gebracht und erst mal die Augen geöffnet, dass es noch andere Paradigmen gibt.

@thenativeweb

2 жыл бұрын

[gr] Danke schön 😊

Like allein schon für den Titel des Videos

@thenativeweb

9 ай бұрын

Haha 🤣

Ihr habt einem Gefühl von mir eine Erklärung gegeben 👍

@thenativeweb

2 жыл бұрын

[gr] Das freut mich, vielen Dank 😊

@markuslink4282

2 жыл бұрын

@@thenativeweb Dem kann ich mich nur anschließen. Ich fände tatsächlich ausführlichere Videos gut zu den Schwächen von Vererbung und den Alternativen. Ich fühle mich so halb angesprochen als Student, dem Vererbung als "das nutzt man halt immer"-Tool beigebracht wurde.

Klasse Video. Ich habe mich anfangs mit OOP sehr schwer getan den Vorteil gegenüber der Funktionalen programmierung überhaupt zu sehen. Inzwischen nutze ich auch OOP habe bisher Vererbungen weitestgehend vermieden, da es mir zu unflexibel erschien, eine Klasse an eine andere zu koppeln, wodurch größere Änderungen an der vererbenden Klasse immer unvorhersehbare Einflüsse auf die erbenden haben kann.

@thenativeweb

2 жыл бұрын

[gr] Danke schön 😊

Ein super Video, ich stimme dir absolut zu.

@thenativeweb

2 жыл бұрын

[gr] Danke 😊

Ich habe das Programmieren mit Sinclair Basic (Sinclair ZX-81) gelernt... Auf dem C64 dann auch mit Assembler. Und dann kam primär auf dem PC mit .Net der absolute Kulturschock. Ich wurde mit OO in vollem Umfang konfrontiert... Ich für meinen Teil liebe OO. Aber ich würde dennoch nicht auf die Idee kommen eine Klasse für eine einfache Berechnung zu verwenden... Aber zum Thema Vererbung. Daran ist nichts schlimmes. Auch wenn ich Klassenvererbung relativ wenig verwende, verwende ich sie bei Interfaces oft, gerne und auch mehrfach (und ja. Bei Interfaces erlaubt .Net Mehrfachvererbung). Ich verwende diese Konstrukte um komplexe Konstrukte zu vereinfachen. Ein Beispiel. Ich habe einen Worker in verschiedenen Ausprägungen (z.B. in der gleichen App Dom, in einer anderen App Dom oder in einem Childprozess. Die Steuerung der Worker ist immer die gleiche Schnittstelle. Wenn ich diese Typen aber alle gemeinsam verarbeiten will, ist es von Vorteil eine Basisklasse für die Basisangelegenheiten zu bauen. und Ableitungen für die Spezialitäten. Da das in Klassen aber oft zu unschönem Code führt, verwende ich dafür lieber Interfaces. Ein Basisinterface und Spezial Interfaces die vom Basisinterface abgeleitet sind... Aber wie immer. Das ist meine Meinung und meine Arbeitsweise. Die hat sich so in über 20 Jahren hauptberuflichen Softwareentwickelns gebildet.

Erstmal tolles Video! Ich stimme den Argumenten in dem Video größtenteils zu. Manchmal ist Vererbung zwar sinnvoll, aber meistens sollte man Komposition bevorzugen. Die unter anderem wichtigste Punkt des Videos ist die Kritik an der Art und weiße wie die Konzepte und Paradigmen gelehrt werden. Zum Thema funktionale Programmierung. Funktoren, Monaden, Monoiden etc. sind eigentlich nicht unbedingt die Kernelemente einer funktionalen Sprache, auf diese stößt man eher in einer Sprache wie Haskell. Viel wichtiger sind Konzepte wie Pattern Matching, Continuations, Higher-Order-Functions, Currying, Partial Application und Co. Es gibt genug funktionale Sprachen, in denen Monaden im Haskell Stil nur schwer umzusetzen sind, z. B. Erlang/Elixir, Elm etc. Auch hier kommt es darauf an, wie es gelehrt wird.

@thenativeweb

2 жыл бұрын

[gr] Danke schön - das freut mich alles sehr 😊

Ein gutes Video und gut erklärt Ich selber stelle oft fest, das zuviele Programmierer dein angesprochenes " Scheuklappendenken" haben. Es MUSS alles in Klassen und Objekt gepackt werden sonst ist der Code schlecht. Oft sehe ich das ein OOP Code z.B. aus 20 Zeilen besteht was aber auch in einem 2-Zeiler gehen würde. Vererbung ist oft Sinnvoll aber auch oft nicht nötig.

@thenativeweb

2 жыл бұрын

[gr] Danke für Dein Feedback 😊

Manchmal ist es halt so: Für den, der als Werkzeug nur den Hammer kennt, ist jedes Problem ein Nagel 🙂

@thenativeweb

Жыл бұрын

[gr] Und wer nur Schrauben kennt, fragt sich, warum sich diese "gestreiften Nägel" so schlecht mit dem Hammer einschlagen lassen 😉

Starker Content.

@thenativeweb

2 жыл бұрын

[gr] Vielen lieben Dank 😊

stimme ich zu.. wir wurden auch mit vererbung in java gequaelt in der uni ;-) habe ich danach aber nie wieder verwendet nach dem modul.

Danke dir!

Vielen Dank!

@thenativeweb

2 жыл бұрын

[gr] Ich danke Dir 😊

Also wenn es um POCOs u. Modelle geht, würde ich heute auch keine extra Basisklasse (z.B. "Person" für Name, Vorname, GebDat, etc.) definieren, nur weil ein anders Objekt ähnliche Personendaten speichert. Da nehme ich das bisschen Redundanz in Kauf - dafür bleibt man sauber, einfach, autark und vermeidet Abhängigkeiten. (erspart auch eine weitere Klasse).

Ich mag deinen Kanal und finde die meisten Videos sehr gut und schön differenziert ausgearbeitet - ich sag nur tdd - vielen Dank dafür. Dieses Video gefiel mir allerdings nicht so wirklich. Ehrlich gesagt, bei deinem Hintergrund, etwas unaufrichtig. Das Anti-Pattern "Vererbung als Code-Kopieren" als Ziel der Vererbung zu darzustellen finde ich unehrlich. Ebenfalls das Thema "Composition over Inheritance" viel zu vereinfacht darzustellen finde ich genauso unangebracht. Das letztgenannte Konzept wird im GOF Buch eingeführt und trotzdem benutzen die meisten Design Patterns mit gutem Grund Vererbung. Und Duck-Typing als eine schöne Weise Polymorphie umzusetzen - also bitte - das sollte doch schon explizit gemacht werden. Und nur weil ein Konzept häufig falsch gelehrt wird (und ich sehe dein Argument bzgl. Kohäsion) ist es nicht automatisch falsch. Ich sehe in der Praxis viel mehr das Problem, dass mir Leute erzählen, dass ihr "Code" natürlich "objekt-orientiert" ist, weil sie das Schlüsselwort class verwenden....

@thenativeweb

2 жыл бұрын

[gr] Danke für Deinen Kommentar und das Lob 😊 Ich habe jetzt zwei Tage überlegt, wie ich antworte, weil mich das Wort "unehrlich" sehr gestört hat - aber das habe ich vermutlich einfach nur in den falschen Hals bekommen, denn Dein Kommentar ist ja durchaus auf die Sache bezogen. Ich kann Deinen Punkt verstehen, möchte dem aber entgegnen, dass ich das Haupt-Argument für OOP schlechthin noch nie wirklich bestätigt gesehen habe: Nämlich die vermeintlich ach so tolle Wiederverwendbarkeit. Abgesehen von UI-Komponenten gilt das praktisch nie. Das ist aber zumindest in meinem Fall DAS Argument gewesen, mit dem uns OOP in der Uni eingebläut wurde, und für dieses Versprechen holt man sich einen ganz schönen Rattenschwanz an Themen und Dingen, auf die man achten muss, ins Haus - nur der versprochene Effekt bleibt meistens aus. Insofern bin ich tatsächlich kein großer Freund von OOP, und dass es dann oft noch falsch vermittelt wird, und deshalb falsch eingesetzt wird, das macht es leider nicht besser (klar, das ist nicht unbedingt die "Schuld" von OOP, aber es hängt damit zusammen …).

Frage, wenn ich eine Funktion erstelle die mir ein Array ausgibt mit Lambdas, ist das dann nicht schon ein Objekt? :D Wenn OOP ein Paradigma ist, ist der Schlüsselwort class und interface einfach nur eine Unterstützung der Programmiersprache aber nciht eine Notwendigkeit für OOP ? Ein Interface kann ja in form von Kommentaren und Ducktyping auch gelöst werden. Kapselung kann man umsetzen indem man variablen in Funktionen definiert und lambdas in einer Funktion aufruft(private methoden) und lambdas nach außen gibt (public methoden) . Vererbung kann man durch das stumpfe rüberkopieren (wie fürher in JS) anwenden. Im Grunde kann man mit Funktionen einen Objekt Orientierten Code schreiben, ohne Objekte aber dafür mit anderen Datenstrukturen.

Code Newbie: Ist die Vererbung stärker? Golo: Nein, nein, nein. Schneller, leichter, verführerischer.

„Wer als Werkzeug nur einen Hammer hat, sieht in jedem Problem einen Nagel.“

Vielen Lieben Dank für das Video! Ein Punkt den ich noch interessant finden würde, ist der der Performance. Z.B. in Hinblick auf Datenbankzugriffe. Ich habe das Gefühl, dass die OOP dazu führt, dass eine Vielzahl einzelner Datenbankzugriffe erzeugt wird. Beispielsweise wenn das Objekt gebaut wird, oder ein Mapping pro Objekt durchgeführt wird etc. Dies führt- zumindest bei uns - in der Massenverarbeitung zu großen Performanceproblemen, da tausende von einzelnen SELECT Abfragen generiert wird, wobei es auch eine getan hätte. Wie siehst du das?

@thenativeweb

2 жыл бұрын

[gr] Ich lehne mich jetzt mal sehr weit aus dem Fenster und sage, dass ich das a) genauso sehe und (unter anderem) aus diesem Grund O/R-Mapper für eine ziemlich blöde Idee halte … OOP und relationale Datenbanken sind zwei Paar Schuhe, und die lassen sich in nicht-trivialen Fällen nicht ganz so einfach verbinden.

Ganz profan ausgedrückt versuche ich bei Domänenobjekten weitestgehend auf Vererbung zu verzichten. Eine PickListe ist eine PickListe und keine Spezialisierung eines BusinessDocument. Wo ich Vererbung aber gut und sinnvoll finde, ist der rein technische Bereich von bspw. Frameworks oder Libraries: seien es nun Logger, Datenbankkontexte oder UI-Elemente. Da ist es schlicht sehr sinnvoll diese vorgefertigte Funktionalität über Vererbung in meine eigenen Implementierungen zu "laden".

@thenativeweb

2 жыл бұрын

[gr] Ja, da stimme ich Dir zu - ich sage ja auch nicht, dass man *nie* vererben sollte, ich sage nur, man sollte es nicht so gießkannenartig ohne Nachdenken machen.

Ich dachte ohnehin, daß die Blüte des OO-Paradigma vorbei ist und durch das Paradigma des Funtional Programming ersetzt wurde. OOP sehe ich eigentlich nur wirklich geeignet für Grafik und 3D Anwendung wie z.B. das in Python programmierte 3D Werkzeug Blender (Open Source 3D Editor).

Wieder schön provokativ. Ja, aber genau so soll es sein. Auch nach all der Zeit, sollte man sich immer hinterfragen und über den Tellerrand gucken. Ist das wirklich die beste Lösung oder macht man das nur, weil man es schon immer so gemacht hat? Die meisten Programme sind aber meist nicht wirklich objektorientiert geschrieben. Ich bin ja auch den Einstieg mit Basic/Pascal damals gegangen und vieles was man so gesehen hat, ist zwar C#/Java, aber an sich doch recht prozedural. Was ja auch nicht falsch sein muss. Das mit der Vererbung ist halt eine Erfahrung, ein langer Hype gewesen. Ich denke aber, Du erwartest hier etwas zu viel von den Schulen/Universitäten. Es gehört einiges an Erfahrung dazu, wann es nun angebracht ist und wann eben nicht. In den klassischen UI Frameworks hat es meiner Meinung nach immer noch seinen Platz. Das Grundproblem hast Du ja angesprochen. Es geht darum doppelten Code zu vermeiden und das ist ja an sich eine gute Sache. Leider gilt eben die Umkehrung nicht und hier beginnt eben der Fehler. Wenn es einen Einsatz gibt für Vererbung, dann bekomme ich quasi gratis auch noch weniger zu pflegenden Quellcode. In der Praxis wird (oder hoffentlich wurde) oft andersherum gedacht. Also wenn ich irgendwo 2x den gleichen Code habe, dann kann ich die doch über Vererbung zusammenfassen. Diese nur aus diesem Zweck gebauten Veerbungen funktionieren eine ganze Weile, bis dann neue Anforderungen kommen und man erkennt, dass eben der Code auseinanderlaufen muss...

OOP in nutshell: man erbt von Kreis, Quadrat, Person und Materialien, um einen Rollstuhl abzuleiten. Um dann festzustellen, dass keine der Klassen Methoden und Eigenschaften Besitz die nötig sind, für mein Anliegen. Also erzeugt man eine neue, im Grunde nutzenfreie Einzelfall-Klasse. Ram,Garbage collector und Debugger hassen diesen Trick.

Das Thema gut auf den Punkt gebracht. Leider wird der Fehler nicht nur in der Ausbildung gemacht, sondern auch zum Teil in den Universitäten, die vieles vermurksen. Als ich mit meinem Informatikstudium anfing, haben wir zwar zu Anfang gleich mit Java gearbeitet, aber die Sprache eben nicht als Objektorientiert kennen gelernt, sondern wurden explizit damit zu einer imperativen Programmierweise angeleitet. Die Objektorientierung wurde dann irgendwann mal im zweiten Semester grob erklärt, aber nicht wirklich intensiv an Beispielen behandelt. Der Fokus lag halt auf Algorithmen verstehen und nicht auf einer guten Vermittlung von Programmierparadigmen. Im dritten Semester kam auch funktionales Programmieren dran, aber dafür wurde dann Haskell genutzt anstatt aufzuzeigen, dass das auch mit Java geht. Ergebnis war, dass dann der Großteil aus dem Studiengang auch in den folgenden Projekten viel mit Java programmierten, aber die meisten die Sprache gar nicht effizient zu verwenden wussten. Ich habe das auch erst nach dem Studium langsam angefangen zu verstehen.

@VitalijMik

2 жыл бұрын

Ich glaube das Problem liegt daran dass nicht Programmierer, Programmieren beibringen ;) Ein Programmierer ist eben kein Dozent in einer Uni. Und ein guter Programmierer kann auch automatisch nicht der beste Lehrer sein. Es ist wirklich nicht einfach da eine Balance zu finden und so wird mal schlechter und mal besser was erklärt

@BenjaminWagener

2 жыл бұрын

@@VitalijMik Das Problem war eher das Programmieren an sich eigentlich nicht so wirklich geschult wurde, sondern viel mehr nur das nötigste um die gestellten Aufgaben zu lösen. Das Programmieren am sich sollten wir eigentlich selbst lernen wozu man aber nur wenig Zeit hatte und dann eben auch nicht zwingend gute Grundlagen zum Lernen hatten, sodass sich da einige ziemlich miese Arbeitsweisen angewöhnt haben.

@thenativeweb

2 жыл бұрын

[gr] Oje … über mein Studium will ich da auch erst gar nicht anfangen zu reden 😉 Aber mir kommt einiges von dem, was Du geschrieben hast, leider *sehr* bekannt vor. Aus Neugier: Wo hast Du studiert (bei mir war's die TU Kaiserslautern)?

@VitalijMik

2 жыл бұрын

@@BenjaminWagener Sollte man selbst lernen? Ich weiß es nicht. Wenn ich mir andere Berufe anschaue, die kriegen alle Schulungen während der Arbeitszeit. Wenn eine neue Software in Unternehmen eingeführt wird, dann gibt es erstmal eine Woche Schulung. Und bei uns Entwicklern? 8 Stunden Arbeiten und dann nach der Arbeit sich hinsetzen und noch mehr lernen obwohl es nciht auf der Arbeit notwendig ist. Ein wenig unfair ist es schon. Aber hey wir sind ja die "Nerds" und haben spaß daran großteil unserer Zeit mit Lernen und ARbeiten zu verbringen, wir sind ja eh Sozial komisch und haben keine Freunde :D ach .. ich habe puls.. 300.. fast :D

@BenjaminWagener

2 жыл бұрын

@@thenativeweb Universität Bremen

Ich glaube ein Problem ist, dass die meisten Bücher über Programmiersprachen nicht auch gleichzeitig Bücher über Softwaredesign sind. Erstere listen natürlich alle Features auf und weniger, wie sie verwendet werden sollten.

@thenativeweb

2 жыл бұрын

[gr] Das ist, denke ich, ein guter und wichtiger Punkt 😊

Ich spüre einen gewissen Groll gegen Leute, die Vererbung im OOP anpreisen. Ich würde OOP allgemein immer dann verwenden, wenn ich in einer OOP Umgebung programmiere. Also z.B. wenn ich an einer Symfony - App arbeite - dann fange ich sicher nicht an, imperial zu coden :D. Und ob ich nun Vererbung brauche oder lieber neue Objekte erstelle, die dann weitere Funktionen erfüllen, liegt auch an der jeweiligen Aufgabe. Das Problem liegt nicht an der Vererbung, sondern am Gebrauch der Vererbung, wo sie nicht gut geeignet ist. Vererbung ist außerdem eines der wichtigsten Prinzipien des OOP. Ich stelle mir vor, ich könnte z.B. meine Printer Klasse nicht weitervererben und müsste für jede Methode eine eigene Klasse erstellen und ggf. mit Komposition einbinden. Man muss halt immer gut nachdenken und ggf. auch Code optimieren und umstrukturieren, wenn man merkt, dass man etwas besser hätte machen können.

@thenativeweb

2 жыл бұрын

[gr] Lass es uns doch so formulieren: Ich hege einen gewissen Groll gegen Leute, die ein Paradigma einseitig und als allein glückselig machendes anpreisen. Ob das nun OOP, FP oder sonstwas ist, spielt dabei eigentlich keine so große Rolle. Mich stört einfach, dass Dinge / Ideen / Konzepte / … viel zu häufig als alternativlos dargestellt werden, als wären sie das Einzig wahre.

@michaelbrauner5320

2 жыл бұрын

​@@thenativeweb Jop. Oft ist es so, dass das mit einem solchen Nachdruck gemacht wird, weil diese Leute nichts anderes können. In unserer Firma wird auch überall Drupal hergenommen - obwohl ein CMS eigentlich nur verwendet werden sollte, wenn es um ContentManagement geht. Das ist aber wirklich nur so, weil hier niemand was anderes gelernt hat. Deshalb hast du schon recht, wenn man mit OOP anfängt, dann fehlt da was. Aber man muss irgenwo anfangen. Die Leute sind nur allzuoft zufrieden damit, was zu können und wollen nicht weiter lernen. Also liegt es aus meiner Sicht nicht unbedingt an den Lehrern und Büchern. Schlimmer ist es, wenn man prozedual anfängt und sich niemals OOP aneignet. Ich weiß das aus Erfahrung - da schreiben dann Devs mit jahrzehntelanger "Erfahrung" den grauslichsten Code, den ich schon vor 10 Jahren als fast unbrauchbar befunden hätte.

1. Kapselung ist keine OOP-Erfindung. Im Gegenteil sogar. In C hast du perfekte Kapselung, da du dort immer nur .h-files in deinen Code einbinden kannst. Dadurch waren die verschiedenen Module perfekt gekapselt. OOP hat das eher kaputt gemacht, denn plötzlich brauchtest du public, private, protected-Keywords um die Kapselung wieder herstellen zu können - und selbst die lassen sich umgehen. 2. Vererbung wird in der Tat überbewertet. Insbesondere ist sie nicht für "Code-Sharing" geeignet. Sie ist sinnvoll für Spezialisierung in kleinen, eng umfassten Spezialfällen des Programms. Leider wird Vererbung immer genetisch erklärt (EIn Hund IST-EIN Tier, Ein Quadrat IST-EIN Rechteck). Das fühlt zu einem systematischen Missverständnis, denn eigentlich Modellieren wir mit Klassen nicht Dinge ("Objekte") sondern Verhalten ("Rollen"). Und ein Quadrat "verält" sich nunmal anders als ein Rechteck. 3. Polymorphie ist ebenfalls keine OOP-Erfindung. In C bspw. kannst du problemlos Polymorphie mit Hilfe von Pointer auf Funktionen umsetzen. Aber du hast Recht: Die Art, wie OOP vermarktet und gelehrt wird ist extrem kontraproduktiv. Wir mussten an der Uni einen Anforderungstext lesen, Substantive herausfiltern und aus diesen Klassen machen. Das Ergebnis war ein aus meiner heutigen Sicht völlig untaugliches Klassenmodell. Aber so wurde in der Designphase wohl mal vorgegangen. Ein völlig anderer Aspekt, der an OOP problematisch ist, ist dass der Code extrem langsam ist, weil er zu einer hohen Fragmentierung im Arbeitsseicher führt, der dann auf Prozessor-Ebene viele sog. Cache-Misses verursacht. (zur Veranschaulichung der Auswirkung von Cache-Misses kann man sich mal ein 100x10.000.000 Elemente großes 2D-Array bauen und einmal Zeilenweise jeden Wert um eins erhöhen und einmal spaltenweise jeden Wert um eins zu erhöhen. Dann jeweils die Zeit messen). Den Performance-Verlust, den man mit OOP erleidet, kriegt man mit keiner Optimierung innerhalb von OOP aufgeholt, da er durch OOP (und den Garbage Collector) verursacht wird.

@pinkeHelga

2 жыл бұрын

Beim Include muß ich mal widersprechen. Du kannst jede beliebige Datei einbinden. Nur meistens ist der Code im Projekt so konzipiert, daß es Probleme gibt, wenn man die Implementation statt der reinen Deklaration einbindet (uneindeutige Mehrfachimplementation). Man kommt aber auch ganz ohne Header-Dateien aus. Ich sage jetzt nicht, daß es sinnvoll in größeren Projekten wäre, aber es gibt die technische Hürde nicht. Man kann #include auch nicht mit anderen Einbindungskonzepten höherer Sprachlevels vergleichen. #include ist eine reine Präprozessoranweisung, die eine komplette Datei (ebenfalls vom Präprozessor überarbeitet) als Resultat wie es ist in den Ausgabestrom einfügt. Du könntest die Inhalte ebenso gut direkt in die Datei hineinkopieren. Einbindung auf höheren Sprachlevels automatisiert die Schritte der Aufteilung in Deklaration und Implementation und daraus folgend die bekanntgabe der Signatur und die Informationen fürs spätere Linken einzelner Objektcodes zum fürs Betriebssystem ausführbaren Programm.

Wer dieses Video schaut, weiß vielleicht noch nicht was der Begriff "Kohäsion" hier in der Programmierung bedeuten soll. Allen, die über die Naturwissenschaften in die Programmierung gekommen sind, hätten da anschauliche Beispiele für starke bzw. schwache Kohäsion vermutlich geholfen. Zumindest ein Link auf das Video vom 23.11.2020 zu diesem Thema kzread.info/dash/bejne/nYuElpVroLu2Xbg.html wäre ganz gut gewesen. Ansonsten alles super erklärt.

@thenativeweb

2 жыл бұрын

[gr] Wenn Du beim Video rechts oben auf die Infokarten achtest beziehungsweise mal auf das eingeblendete Info-i klickst, wirst Du feststellen, dass wir genau das Video, das Du vermisst, bereits verlinkt hatten.

Das mit der Vermittlung ist halt ein schwieriges Thema. Wer soll das Vermitteln? Ein Programmierer mit mehreren Jahren Berufserfahrung wird nicht als Dozent in einer Uni arbeiten. Ein Dozent auf einer Uni programmiert nicht 8 Stunden am Tag um das Problem in Praxis kennen zu lernen. Ein Programmierer der 8 Stunden am Tag arbeitet versteht vielleicht das Problem, kann es aber nicht erklären. Und Frameworks unterstützen das zu gerne. Die bieten eine menge an Basis Componenten an die Grundlegende Arbeit anbieten und man muss "nur" noch ableiten.

@thenativeweb

2 жыл бұрын

[gr] Ich gebe jetzt mal eine bewusst böse Antwort 😉 "Wer soll das Vermitteln? Ein Programmierer mit mehreren Jahren Berufserfahrung wird nicht als Dozent in einer Uni arbeiten." Und warum nicht? Ganz einfach: Weil die Verdienstmöglichkeiten im akademischen Umfeld im Vergleich zur freien Wirtschaft völlig indiskutabel und unterirdisch sind. Und warum ist das wiederum so? Weil zwar alle davon reden, wie wichtig doch Bildung sei, aber niemand bereit ist, dafür angemessen zu bezahlen (und damit meine ich *nicht* die Studentinnen und Studenten, sondern den Staat: Ich (als Staat) kann nicht erwarten, gut ausgebildete und erfahrene Leute als Dozenten an die Hochschulen zu bekommen, wenn ich nicht einmal ansatzweise bereit bin, angemessene Sätze zu zahlen. Ich habe selbst schon mehrere Vorlesungen gehalten, und ich hab's prinzipiell auch gerne gemacht, aber so einen Blödsinn wie "bitte achten Sie darauf, einen Parkschein zu ziehen, die 2,50 Euro können wir leider nicht stellen" machst Du halt auch nur einmal mit … Und da geht es mir nicht um die 2,50 Euro an sich, sondern um die Geste: Es scheitert schon an so Kleinigkeiten wie einem Parkticket? Dann scheint die Wertschätzung insgesamt ja unglaublich hoch zu sein … nicht 😉

@VitalijMik

2 жыл бұрын

@@thenativeweb genau das. Es lohnt sich finanziell halt nicht.

moment.. hat C nicht structs? ..@variable vor/nachname haben null bezug zu einander in c

Ich muss ganz ehrlich sagen, ich stimme bei dem Faktor mit der Vererbung nicht zu. Es gibt diese Probleme eigentlich nur dann wenn man in der Entwicklung die gesamte Klasse viel zu Groß gestaltet bzw. an sich Fehler gemacht hat. Also klar, wir müssen nicht für alles Objekte bauen. Wir müssen nicht für alles Vererbung nutzen. Aber in gewissen fällen ist es einfach ein mächtiges feature was benutzt werden sollte.

@thenativeweb

2 жыл бұрын

[gr] Natürlich gibt es Fälle, wo Vererbung sinnvoll ist - das will ich auch nicht bestreiten. Mich stört aber, dass es zu unkritisch und damit vor allem viel zu oft ohne Nachzudenken genutzt wird.

@erkancimen7787

2 жыл бұрын

@@thenativeweb Da gebe ich dir absolut Recht!

Hey, fehlt da nicht die Abstraktion? Ich kenne die vier Säulen der OOP und lerne bei uns im Unternehmen Java. VG

@IAmFeO2x

2 жыл бұрын

Abstraktion ist ein allgemeines Konzept, das man nicht nur der OOP zurechnen kann. Abstraktion heißt im Wesentlichen, dass das Wichtige in den Vordergrund gestellt wird und das Unwichtige versteckt wird. Und das kann man z.B. auch ganz simpel mit einer Methode/Funktion machen, die einem eine bestimmte Aufgabe abnimmt, die notwendigen Parameter entgegen nimmt (das Wichtige), dem Aufrufer aber verbirgt, wie genau die Parameter für eine Berechnung genutzt werden. Abstraktion ist letztendlich mit vielen unterschiedlichen Mechanismen von Programmiersprachen möglich (z.B. Interfaces, die Members in den Vordergrund stellen, die für den Aufrufer wichtig sind).

@peterzwegat2744

2 жыл бұрын

@@IAmFeO2x Hey, danke für die Antwort. Was Abstraktion technisch ist weiß ich natürlich. Habe ich ausgiebig gelernt😅. Es hat mich nur gewundert, dass es hier nicht aufgezählt worden ist. Es wird natürlich nicht nur bei der OOP angewendet, ist aber ein wesentlicher Bestandteil der OOP. VG

@IAmFeO2x

2 жыл бұрын

@@peterzwegat2744 Richtig, ich denke aber, dass Golo in diesem Video auf die Alleinstellungsmerkmale von OOP eingehen wollte - und da gehört Abstraktion nicht dazu.

@marcusreinicke

2 жыл бұрын

@@IAmFeO2x hey Kenny, ich habe lang keine Videos mehr von Dir gesehen. Die waren immer recht lehrreich🤗🤗🤗

@IAmFeO2x

2 жыл бұрын

@@marcusreinicke Ich treibe mich eher in User Groups oder auf Konferenzen rum und schreibe viel Open Source Software. Themen hätte ich allerdings viele für Videos. kzread.info/dash/bejne/kXiYs5uOcsjgqrQ.html kzread.info/dash/bejne/mIZ5rshpn7uaorg.html adc.ms/22/

Kann mir jemand ein Beispiel geben, wie das Problem der Vererbung praktisch aussieht? Bzw. wo das Problem bei folgendem Beispiel liegen kann: Wir haben ein Spiel, bei dem erhält der Spieler Einheiten (Siedler Klasse, bzw. Objekt mit zufällig festgelegten Fähigkeiten wie Stärke, Schnelligkeit, Intelligenz, etc.). Diese Objekte/Einheiten können nun trainiert werden für einen Beruf wie Tischler, Jäger, Bauer, Steinmetz, usw. Die der Einheit zufällig zugeteilten Werte für Fähigkeiten sollten dabei erhalten bleiben, die vererben sich, egal zu was das Objekt bzw. die Einheit gemacht wird: Handwerker, Soldat, Beamter, usw. Sie alle sind Objekte der Klasse Siedler, deren Grundwerte (Name, Maße, Fähigkeitswerte, Vorlieben) sich vererben. Wo kann jetzt dabei ein Problem auftreten?

@MrWisenice

2 жыл бұрын

Überlege dir, was passiert, wenn dein Code sich weiter entwickelt und neue Anforderungen hinzu kommen. Am Anfang sieht alles noch gut aus, aber dann sagt der:die Spieledesigner:in, dass noch Klonenkrieger hinzukommen sollen. Dann macht deine ursprüngliche Basisklasse vielleicht keinen Sinn mehr (Klonenkrieger haben zum Beispiel keine Namen). Was jetzt? Soll der Klonenkrieger nicht von der Basisklasse erben? Muss eine Zwischenklasse eingezogen werden? Muss die ursprüngliche Basisklasse geändert werden?

@thenativeweb

2 жыл бұрын

[gr] Das lässt sich relativ einfach konstruieren (ich kenne ja nun Euer Spiel nicht, daher ist es logischerweise nur ein konstruiertes Beispiel): - Du hast geschrieben, Ihr habt Stärke und Schnelligkeit. - Nun erschafft Ihr einen neuen Typ Siedler (also eine neue Unterklasse), deren besondere Eigenschaft ist, dass ihre Stärke und Schnelligkeit identisch sind (frag mich nicht, warum das so sein sollte, wie gesagt, konstruiertes aber denkbares Beispiel). - Nun hast Du (nehme ich an) zwei Methoden, "steigereStärke" und "steigereSchnelligkeit". Die funktionieren in der abgeleiteten Klasse nicht mehr wie gehabt, weil sie ja nur jeweils eine Eigenschaft verändern. Das lässt sich aber lösen, indem Du beide Methoden so überschreibst, dass sie eben beide Eigenschaften gleichermaßen verändern. Und genau da hast Du nun das Problem geschaffen: Überall dort, wo Du bislang einen Siedler erwartest (also die Basisklasse), werden die bisherigen Annahmen verletzt, nämlich dass die beiden Werte unabhängig sind. Stell Dir vor, Du hast eine Funktion, dass die Spielerin oder der Spieler gelegentlich X Punkte geschenkt bekommt und die frei verteilen kann. Für bisherige Siedler funktioniert das wie erwartet: Spieler:in bekommt 10 Punkte und vergibt die entweder für Stärke oder für Schnelligkeit. Für diesen neuen speziellen Typ funktioniert das nun aber nicht mehr, denn erhöhst Du eine der beiden Eigenschaften um 10, hast Du insgesamt 20 zugelegt. Das heißt, Du hättest nur um maximal 5 pro Eigenschaft erhöhen dürfen, was die Methode aber nicht wissen kann, da sie ja nur den abstrakten Siedler kennt. Das heißt, langer Rede kurzer Sinn, die spezialisierte abgeleitete Klasse verletzt Eigenschaften der Basisklasse, da sie sich nicht mehr analog verhält und damit die "is a"-Beziehung verletzt. Einziger Ausweg: Du passt die beiden Funktionen nicht an. Dann verhält sich der neue Siedler-Typ analog zur Basisklasse, also erwartungskonform - nur verletzt Du dann den Constraint der Subklasse, dass beide Eigenschaften immer gleich sein sollen. Egal, wie Du es drehst und wendest, hierfür gibt es keine (saubere) Lösung.

@wolfwinter2024

2 жыл бұрын

@@MrWisenice Ja, das war mir schon klar, das Klasse und Objekt nicht beliebig von einander abweichen können. Also man relativ viele Klassen braucht, oder aber nicht viele Variationen schaffen kann. Im Grunde habe ich die Klasse eher als einen Prototyp gesehen, aus dem sich ein Objekt generieren lässt. Allerdings ging ich davon aus, das das Objekt danach eigenständig ist. Ich denke das mit dem Namen ließe sich ja regeln, denn der Name wird einem Namensliste oder einem Namensgenerator entnommen. Für den Klonkrieger könnte man dann eine Ausname hinzufügen, die einen "leeren" Namen erzeugt. Klar wird das dann immer schwieriger, aber es wird doch auch nicht einfacher, jedes Objekt einzeln aus einer Auswahl an Methoden usw. abzuleiten.

@wolfwinter2024

2 жыл бұрын

@@thenativeweb Also die Fähigkeiten sollten sich nicht ändern, es sind Grundwerte. Werkzeuge, Level, usw. addieren dann beim ausführen einer Methode entsprechend Werte hinzu. Am Objekt ändert sich damit nichts, seine Skills werden extra verzeichnet. Die Grundwerte stellen eine Eignung dar, die mit der Zeit durch Training relativiert werden, oder aber unterstützen was trainiert werden soll. Überrascht bin ich trotzdem - ich nahm an, ein Objekt generiert sich aus der Klasse, und seine Werte können danach geändert werden, weil das Objekt nach seiner "Entstehung" eigenständig ist. Oder wird es forlaufend aus der Klasse generiert in einem andauernden Prozess? So wie das Bild auf meinem Bildschirm? Ich dachte, das Objekt wird als das was es ist in die Datenbank gespeichert und "existiert" dann, kann also auch "bearbeitet" werden. EDIT: Mir fällt noch was ein... Ich habe Klasse Siedler, Objekt Siedler Meier. Siedler können nichts Spezielles. Auch gibt es z.B. die Klasse Bogenschütze. Meier soll Bogenschütze werden, dazu bekommt er Waffen (ggf. auch Objekte) und wird trainiert. Er wechselt dann die Klasse. Geht das überhaupt? Oder muss der Bogenschütze auch als Objekt erstellt werden? Bzw. ich dachte es mir so, das das alte Objekt durch ein neues ersetzt wird, das sich teils aus dem vorherigen ableitet. Ein anderes Beispiel bzw. Frage: Automobil - Sportwagen - Tesla - Model Gurke. Jetzt haben wir Klasse und Objekt. Was wird/kann als Klasse definiert, was als Objekt, bzw. was unterscheidet ein Objekt und eine Instanz? Kann aus einer Klasse eine Unterklasse oder aus einem Objekt ein spezifisches Objekt geschaffen werden? Und wenn ich jetzt an dem Objekt "Tesla Model Gurke" tune, ändert es teilweise seine Eigenschaften. Selbes Problem? Geht das jetzt mit OOP oder gibt das schwere Probleme? Ich frage so doof, denn wenn Java's OOP kein Vorteil bei der Sache ist, kann ich Javascript nehmen. Ich wollte nicht gleich 2-3 Sprachen auf einmal lernen, das kriege ich nicht auf die Reihe. ("Wir haben ein Spiel" war nur gemeint als hypothetische Überlegung, ich bin kein Entwickler. ;))

Die beste Programmiersprache zum Lernen ist Julia

@guelakais1438

2 жыл бұрын

Nein, es ist Python! ;)

@L4rsTrysToMakeTut

2 жыл бұрын

@@guelakais1438 python ist ein komplettes Chaos 😂

@Oetzek38

2 жыл бұрын

Balsam für die Lisp Seele

Das Konzert heisst nicht Vererbung sondern Spezialisierung. Spezialisierung wird implementiert durch Vererbung. Ein Dackel ist ein Hund, weil er die Eigenschaften eines Hundes hat.

@thenativeweb

2 жыл бұрын

[gr] Nein, das Konzept heißt "Vererbung" und Spezialisierung ist eine der beiden Seiten der Vererbung - die andere ist die Generalisierung. Ich zitiere mal Wikipedia, aus dem Artikel "Vererbung (Programmierung)", siehe de.wikipedia.org/wiki/Vererbung_(Programmierung): "Die Vererbung (englisch inheritance) ist eines der grundlegenden Konzepte der Objektorientierung […] Den Vorgang des Erbens nennt man meist Ableitung oder Spezialisierung, die Umkehrung hiervon Generalisierung, […]"

Ein Vektor hat keinen Ursprungspunkt

@BinGanzLieb

2 жыл бұрын

Das ist total am Thema vorbei

@thenativeweb

2 жыл бұрын

[gr] Ja, da hast Du recht.

Mal wieder ein Video nur für Senior Entwickler. Denn nur diese verstehen vielleicht das viele Blabla. Kein einziges konkretes Beispiel im Video, nix. Wie soll man sich da ne eigene Meinung bilden können als Programmieranfänger, mit keinen 20 Jahren Code Erfahrung?

JavaScript ist auch völlig überbewertet.

@stefans.6858

2 жыл бұрын

@@internet4543 Da spricht ein wahres Wunderkind.

Ich habe schon einiges programmiert als hobby. Ich habe mir mal die Erklärungen und tutorial von OOP angeguckt. Ich war echt enttäuscht, das kein einziger Deutscher mal erklärt wo Variablen sind was diese Eigenschaften sind. Was die Technik ist. Man konnte nur sagen Auto und Auto haben Motoren und Türen und das sind alles Eigenschaften, aber was es mit Programmieren zu tun hat, will keiner erklären. Ich gebe dir recht es überwertet und absolut hirnlos. Die Leute die es verstehen wollen es nicht einmal erklären und machen dann noch so einfach das es keinen Sinn für mich ergibt.