Ich weiß jetzt nicht, warum du dein (durchaus abwegiges) Beispiel an OOP festmachst. So einen Unsinn kann ich auch in BASIC programmieren.
Kennt dieses BASIC überhaupt Datentypen? In Pascal und Artverwandten, in C und diversen anderen Programmiersprachen MIT Typprüfung geht das dann nicht.
Ja, es kennt Fließkomma, Integer und String.
Und die Typprüfung bei Unterprogrammaufrufen oder Zuweisungen?
Ja da kennt BASIC diverse Fehlermeldungen (zur Laufzeit).
Tja Objekt Orientierung galt lange zeit als das glückseligmachende Konzept mit Garantie für die absolute Lösung.
Das ist imho genauso quatsch wie all dies Hypes.
Ein anderes Problem sich schlicht die Bibliotheken. Sie sind mittlerweile nicht mehr überschaubar und haben teilweise schreckliche Interfaces.
Datentypen sind schon eine feine Sache. Leider machen viele c-Compiler Auto-Konvertierungen. Wenn man die passende Warnung ignoriert -
Ist ja nur warning, können sich Werte recht schnell und unkontrolliert ändern.
Die dabei auftretenden "sporadischen" waren immer wieder ein riesen Spaß
Um es kurz zu machen.
man kann in fast jeder Sprache vernünftig programmieren. Die Toolchain ist eigentlich wichtiger, sollte aber verstanden sein und beherrscht werden.
Andersherum man kann, da bin ich mir sicher auch in jeder Sprache, riesigen Mist programmieren.
- So sehe ich das zumindest
Warum die Software heute so schlecht ist? Weil sie billig sein soll.
...
Leider können auch die besten Tools nicht verhindern, dass eine Pfeife eben eine Pfeife bleibt. (A fool with a tool is still a fool).
Und es ist für den typischen Personalentscheider in einer Firma gar nicht so einfach, die Pfeifen von den anderen zu unterscheiden.
Irgendwelche Belege, dass inzwischen so viele Pfeifen programmieren? Oder sind wir wieder auf dem Stanntisch-Niveau, wo man einfach mal irgendwelche wilden Behauptungen in dem Raum schmeisst?
Ich kann dir gerne Belege liefern. Ich stelle seit Jahren jedes Jahr ein paar Programmierer (viel weniger in DE, sondern hauptsächlich in Indien und Rumänien, weil, siehe oben, und auch weil in diesen Ländern die Fluktuation extrem hoch ist) ein. Hier in Deutschland bekommt man für eine offene Stelle (nach Filterung) in einer Fachabteilung vieleicht 3 oder 4 Kandidaten, in Indien 100 (schön sortiert nach vermeintlicher Qualifikation, damit man die schlechteren 95 gleich beiseitelegen kann). Weil wir (fast) keine Berufsanfänger einstellen, haben alle diese Leute schon eine Laufbahn hinter sich und haben damit auch schon irgendwo "produktiv" Software entwickelt und ihre Spuren hinterlassen. Die Lücken in den Kenntnissen, die sich in unseren Einstellungsgesprächen auftun, sind aber leider (fast unabhängig, wo die Leute herkommen, mit vielleicht einem etwas größeren landestypischen Optimismus, was die eigenenen Kentnisse angeht, in Asien) sind aber trotzdem manchmal riesig. Und nein, in einem ersten Gespräch stelle ich normalerweise nur eine halbe Stunde lang ein paar einfache Fragen und will nur rausfinden ob ein z.B. C++-Experte überhaupt C++ "kann" - Also in keinster Weise da schon "Google-Einstellungstest"-Niveau. Ich bin aber überzeugt davon, dass die Leute, die wir ablehnen, irgendwann irgendwo doch einen Job bekommen.
Das ist aber (ich sags nochmal) absolut keine neue Entwicklung, sondern schon seit bestimmt 20 Jahre und mehr so. Vielleicht ist das "Blenden" heutzutage allerdings ein bißchen einfacher, weil man ja alles im Internet ergooglen kann.
Lass mal hören, wie die Lösung auf all die Softwareprobleme aussieht.
Don't gt him started. 
Kann man woanders nachlesen - es hat was mit so einer Art Metassembler zu tun. Und es klingt noch nichtmal schlecht ...
Hier ist mal noch so ein hübsches Videostück - ca. 15 Sekunden ansehen , bis zum Tee trinken - wo sich eines der "neuen" Problem nett zusammenfaßt.
Irgendwelche Belege, dass inzwischen so viele Pfeifen programmieren? Oder sind wir wieder auf dem Stanntisch-Niveau, wo man einfach mal irgendwelche wilden Behauptungen in dem Raum schmeisst?
Ich kann dir gerne Belege liefern. Ich stelle seit Jahren jedes Jahr ein paar Programmierer (viel weniger in DE, sondern hauptsächlich in Indien und Rumänien, weil, siehe oben, und auch weil in diesen Ländern die Fluktuation extrem hoch ist) ein. Hier in Deutschland bekommt man für eine offene Stelle (nach Filterung) in einer Fachabteilung vieleicht 3 oder 4 Kandidaten, in Indien 100 (schön sortiert nach vermeintlicher Qualifikation, damit man die schlechteren 95 gleich beiseitelegen kann). Weil wir (fast) keine Berufsanfänger einstellen, haben alle diese Leute schon eine Laufbahn hinter sich und haben damit auch schon irgendwo "produktiv" Software entwickelt und ihre Spuren hinterlassen.
Ja, das ist schon komisch. Wie stellen gerne Berufsanfänger und Quereinsteiger ein. Gerade in den letzten 3 Monaten wieder 2 Neue. Die werden nicht nach Qualifikation sondern nach einem Eignungstest ausgewählt.
Und die arbeiten dann in einem Scrum-Team mit anderen erfahrenen Software-Entwicklern zusammen. Mit Code Reviews und allem drum und dran (hatte ich weiter oben schon beschrieben). Nach 6 Monaten sind die dann fitt und können auch komplexere Ticks eigenständig abarbeiten.
Diese Filter der Bewerberdatenbanken sind ein großes Problem. Da werden viele interessante Kandidaten weggefiltert, weil ihnen irgendeine Qualifikation fehlt.
Hier ist mal noch so ein hübsches Videostück - ca. 15 Sekunden ansehen , bis zum Tee trinken - wo sich eines der "neuen" Problem nett zusammenfaßt.
Ja, aber auch keine Lösungsvorschläge.
Hier ist mal noch so ein hübsches Videostück - ca. 15 Sekunden ansehen , bis zum Tee trinken - wo sich eines der "neuen" Problem nett zusammenfaßt.
Wo genau siehst du ein "Problem"? dass man, wenn man viel Software installiert, viel Software installiert?
Tja Objekt Orientierung galt lange zeit als das glückseligmachende Konzept mit Garantie für die absolute Lösung.
Das ist imho genauso quatsch wie all dies Hypes.
Deshalb sind Hybrid-Sprachen wie Delphi (oder auch C++) ja so schön, man kann je nach Projekt mal mit oder ohne OOP Ansatz programmieren. Kleine Projekte machen oft objektorientiert keinen Sinn. Bei größeren Problemen behaupte ich aber mal, ist OOP ungeschlagen, eben weil vieles an Code recycled und geerbt werden kann.
Bei größeren Problemen behaupte ich aber mal, ist OOP ungeschlagen, eben weil vieles an Code recycled und geerbt werden kann.
Ich dagegen behaupte (und weiß es), daß auch größere Projekte völlig traditionell und verständlich in Hochsprachen entwickelt werden können ohne objektorientiertes (wie Java oder C++) einzusetzen. Ich war jahrelang z.B. an einer Modula-2-Entwicklung und in den 1980ern an einer PEARL-Entwicklung beteiligt. Also Pflichtenheft, Lastenheft, Code schreiben, Test, Abnahme. Und kein "agil" und kein "scrum".
Bei größeren Problemen behaupte ich aber mal, ist OOP ungeschlagen, eben weil vieles an Code recycled und geerbt werden kann.
Ich dagegen behaupte (und weiß es), daß auch größere Projekte völlig traditionell und verständlich in Hochsprachen entwickelt werden können ohne objektorientiertes (wie Java oder C++) einzusetzen. Ich war jahrelang z.B. an einer Modula-2-Entwicklung und in den 1980ern an einer PEARL-Entwicklung beteiligt. Also Pflichtenheft, Lastenheft, Code schreiben, Test, Abnahme. Und kein "agil" und kein "scrum".
Bin ich absolut bei dir. Und ich schreibe auch heute gerne noch Code völlig ohne OOP. Vor allem Compiler und Interpreter. Sobald du aber, sagen wir mal irgend was mit einer GUI bauen musst, ist OOP extremst hilfreich. In den Anfangsjahren des Mac hatte ich die Kiste noch ohne Objective Pascal programmieren müssen. Immer erst mal (per Copy Paste - also auch irgendwie Vererbung) die Event-Queue per großer repeat Schleife und case statement auslesen, jedes Fenster umständlich irgendwie auf den Bildschirm zaubern, und, und, und.
Mit Objective Pascal aus dem MPW war das dann alles ein Klax und man konnte sich wieder auf den "wichtigen" Code konzentrieren. So ging es mir dann auch immer unter Windows mit Delphi.
Ich war jahrelang z.B. an einer Modula-2-Entwicklung
Ja, Modula-2 war auch toll. Hab ich auch immer sehr gerne Programmiert. Hab dann nicht verstehen können, wie das bei Oberon dann so ins schlechte abrutschen konnte. Oberon war wirklich keine schöne OOP Sprache, aber auch da darf Mann oder Frau gerne anderer Meinung sein.
Bei größeren Problemen behaupte ich aber mal, ist OOP ungeschlagen, eben weil vieles an Code recycled und geerbt werden kann.
Ich dagegen behaupte (und weiß es), daß auch größere Projekte völlig traditionell und verständlich in Hochsprachen entwickelt werden können ohne objektorientiertes (wie Java oder C++) einzusetzen. Ich war jahrelang z.B. an einer Modula-2-Entwicklung und in den 1980ern an einer PEARL-Entwicklung beteiligt. Also Pflichtenheft, Lastenheft, Code schreiben, Test, Abnahme. Und kein "agil" und kein "scrum".
Klar geht das. Ging ja damals nicht anders - vor 40 Jahren.
Und heute machen alle OOP und Scrum und du bist vermutlich der Einzige, der erkannt hat, dass das nix taugt. Und so wie ich dich verstanden habe, sogar ohne dass du je ein Projekt damit gemacht hast. Respekt! 
Klar geht das. Ging ja damals nicht anders - vor 40 Jahren.
Auch vor 20 Jahren. Und warum geht's heute angeblich nicht mehr? Ok, das war eine rhetorische Frage. Es gibt weiterhin Projekte, die nach Pflichtenheft entwickelt werden.
Und heute machen alle OOP und Scrum und du bist vermutlich der Einzige, der erkannt hat, dass das nix taugt. Und so wie ich dich verstanden habe, sogar ohne dass du je ein Projekt damit gemacht hast. Respekt!
Wenn ich alles auspobieren wollte, was ich für nicht gut halte, käme ich nicht dazu Vernünftiges zu tun. "Man" muß sich entscheiden.
Und heute machen alle OOP und Scrum und du bist vermutlich der Einzige, der erkannt hat, dass das nix taugt. Und so wie ich dich verstanden habe, sogar ohne dass du je ein Projekt damit gemacht hast. Respekt!
Wenn ich alles auspobieren wollte, was ich für nicht gut halte, käme ich nicht dazu Vernünftiges zu tun. "Man" muß sich entscheiden.
Und weil du es nicht für gut hältst, taugt es nichts? Ohne jegliche Erfahrung? Das ist doch absurd.
Ich habe da eine ganz andere Vermutung, weil du gerade gegen die moderne Methoden wetterst und deine 40 Jahre alten Arbeitsweisen so hochhältst. So als wäre früher wirklich alles besser gewesen.
Noch ein Statement zu Scrum: Das sehe ich durchaus kritisch. Denn das hat auch seine Nachteile. Aber eben auch viele Vorteile.
Aber lassen wir's einfach dabei. Hat eben jeder so seine Ansichten und Arbeitsweisen.
Ich habe da eine ganz andere Vermutung, weil du gerade gegen die moderne Methoden wetterst und deine 40 Jahre alten Arbeitsweisen so hochhältst. So als wäre früher wirklich alles besser gewesen.
Man kann neue Verfahren in einer Entwicklungsumgebung besprechen, diskutieren, drüber nachdenken, übrigens gilt das nicht nur für reine Software, und man kann zum Ergebnis kommen, daß damit unnötigerweise eine neue Sau durchs Dorf getrieben werden soll. Zum Geldverdienen von z.B. "Beratern". Man kann sich dafür entscheiden, oder dagegen.
Ich war zwar nicht Entscheider, aber die Diskussion kam bei mir an.
Was "früher war alles besser" angeht: ja, heutige Software ist durchschnittlich übler als das, was ich in den 1990er Jahren benutzte. Siehe der oben verlinkte Kommentar zu 60Jahre Software-Katastrophe und seine Kommentare drunter.
Was "früher war alles besser" angeht: ja, heutige Software ist durchschnittlich übler als das, was ich in den 1990er Jahren benutzte. Siehe der oben verlinkte Kommentar zu 60Jahre Software-Katastrophe und seine Kommentare drunter.
Wo ist da ein Link?
Noch 'ne Ergänzung von mir aus dem USenet (de.alt.folkolore.computer), ein paar Jahre alt:
Joa. Ich lese da aber nix von OOP oder Scrum in dem Artikel. Nur allgemeines Palaver über schlechte Softwarequalität, aber nichts Konstruktives.
Ich mag dagegen Artikel, wo sich Leute Gedanken machen, wie man etwas besser machen kann. Dafür muss man sich nämlich intensiv mit einem Thema beschäftigen.
Du scheinst ja einen richtigen Feldzug gegen OOP zu führen. 
Und wie gesagt, alles ohne persönliche Erfahrungen. Schon beeindruckend.
Aber das bestätigt alles meine Vermutung und deswegen bin ich jetzt endgültig raus aus der OOP Diskussion hier.
Ich sag mal auch was dazu
Das Ergebniss ist entscheidend. Nicht die Sprache.
Die Sprache wird gewaehlt welche am besten geeignet
ist das Problem zu loesen. Was man nicht kennt, kann
man lernen, wenn man denn auch will.......
Ich mag BASIC
Ich liebe BASIC
Ich hab alles erreicht und mehr was ich wollte mit
dem was ich unter BASIC programmiert habe.
Meine Lieblinge :
Windows :
PDS 7.1 / DOS
VB 6 Enterprise / WINDOOF
Anderes :
CBM 8xxx/6xx/7xx
Sharp Basic MZ 80 A/B/K
Wenn es sein muss, manchmal aber auch gerne :
PHP
Viele Gruesse aus dem hohen weitem Nord/Osten.......
Du scheinst ja einen richtigen Feldzug gegen OOP zu führen.
Und wie gesagt, alles ohne persönliche Erfahrungen. Schon beeindruckend.
Betrachte mich als Opfer dieser Software! Ich bin leider gezwungen hin und wieder welche zu benutzen, sowohl modern wie auch vermutlich objektorientiert.
Bei einem Programmpaket kann ich die Unfähigkeit der Macher der Software zsammen mit denen der Umgebung quantifizieren: es handelt sich um MediathekView. Vor ein paar Jahren lief das auf meinem Raspberry Pi Modell 3B, also 1MB RAM. MediathekView holte alle(!) möglichen Senderlisten. Neben diesem Programm lief im Raspi noch ein Web-Browser, vermutlich Chromium. Ich konnte mit dem noch 3-4 Tabs öffnen, ohne daß der Raspi kollabierte. Dann kamen kleine Updates. Zuerst blieb für den Web-Browser kein Platz. Vor einem Jahr zog diese Software um auf einen Raspberry Pi Modell 4B mit 4MB RAM. Jetzt kann ich wieder MediathekView, das Java-Programm, in voller Schönheit laufen lassen, dazu den Firefox. Das geht ungefähr 2-4 Wochen, dann fehlt's dem Raspi an freiem RAM. MediathekView nimmt sich mehr und mehr und mehr. In einer Java-Schulung hörte ich vor sehr vielen Jahren was von automatischer "Garbage Collection" im Java-Interpreter. Zuerst dachte ich, die wollen mich veräppeln. Denn wozu braucht ein Programm immer mehr Speicher, wenn die Aufgabe nicht wächst. Ich lernte dazu: beim objektorientierten Java sei das "nötig", und ich sehe, daß es nicht funktioniert.
Kurz: mit dieser tollen Java-Software wurden in rund 4 Jahren die Hardware-Fortschritte der Raspberry-Pi-Entwickler vernichtet. Warum? Ich erkenne nicht, daß das Programm dem Nutzer heute mehr bietet als vor 5Jahren.
Wie sähe das beispielsweise in Commodore BASIC aus? Man deklariert irgendwelche kryptischen Arrays um die Autos zu beschreiben. Mangels strukurierter Variablen kann man nicht mal die Eigenschaften eines Autos zusammenfassen und muss das über unabhängig Arrays abbilden. Und das jeweilige Auto ist dann eine Index.
Was für ein Krampf! Sorry, das kann mir niemand erzählen, dass das leichter verständlicher sein soll und ein geeigneter Einstieg in die Programmierung ist.
Äh, na und?
1. In Commo-BASIC gibts dann halt ein Feld AutoFarbe, eines AutoMarke$, AutoGeschwindigkeit, und so weiter. Und das Autos Nummern haben lernen die Kinder schon beim Blick auf die Straße. Echt, Strukturierung und Namensräume sind was für Weicheier :))
2. Commodore BASIC ist eine absolute Minimalimplementation und Lichtjahre entfernt von einem BASIC das man für eine derartige Aufgabe verwendet - es geht, es ist aber ungefähr genauso sinnvoll wie Spieleprogrammierung in Excel (Das es geht sagt nur was über den Willen derer die es gemacht haben aus).
3. Ein BASIC das für eine derartige Datenbankaufgabe geeignet ist bietet Wege um genau solche Strukturen zu handhaben - auch ganz ohne das Objektorientiert zu nennen/machen. Von Olivetti bis Wang und MAI konnten alle ernsthaften Implementation das - lange bevor Herr Gates eine 8 KiB Mini-Implementation and Commodore verkauft hat.
Das mal aus dem Weg, Programmieren lernen hat nix mit Objektorentierung zu tun. Im Gegenteil, das verstellt einem nur den Blick auf die Grundlagen. Und Anfänger müssen erstmal das grundlegende Gefühl dafür bekommen, dass man den Rechner was machen lässt und wie das geht. Programmieren ist da nicht anders als jeder andere Handwerksberuf (ja, isses) . Wer was im Metallbereich lernt, der wird steht auch nicht am ersten Tag vor der CNC-Maschine, sondern feilt erstmal 4-6 Wochen U-Stahl. Und dann gehts an die Drehbank und die Fräse, und viel viel später und nach viel zusätzlicher Theorie kommt man dann an der CNC-Maschine an, die später den Beruf ausmachen wird.
Die meisten aktuellen Sprachen Verlangen viel zu viel Aufwand und Wissen, selbst für einfache Aufgaben. Nicht umsonst sind Sprachen wie Perl oder heute Python (nicht nur bei Einsteigern) so erfolgreich. Das ist das BASIC von heute, dass einen schnellen Einstieg ohne viel Lernen ermöglicht.
Ist auch die Grundlage des Wahnsinnserfolgs der Arduinos. Technisch ist der ja nur ein Breakoutboard eines AVR. Der eigentliche Erfolg kommt von der IDE. Und ja, es ist C++, aber es wird dem Anfänger BASIC-artig angeboten. Dabei entsteht natürlich auch Code der bei erfahrenen Programmierern Rant-Attacken auslöst. Aber schönes Programmieren ist da nie das Ziel gewesen. Es geht alleinigst darum Leute die mit Programmieren nix am Hut haben Grundlagen erlernen zu lassen. Und das funktioniert millionenfach. Das halbe Wunderland läuft damit.
Als Vater kann man nicht wissen was die Kinder mal werden (meine sind, trotz viel Computerberührung in der Jugend, dann doch in Verwaltung und Personalmanagement gelandet) . Daher macht es auch wenig sinn sie von Anfang an auf 'richtig' Programmieren zu trimmen. Was sinn macht ist ihnen den Spaß an ein bisschen Code zu vermitteln. Und da ist Arduino, Python und eben auch BASIC genau richtig.
Also historische Interpreter- und Compilersprachen sehr gerne - aus rein nostalgischen Gründen. Aber nicht als heutigen Einstieg in die Programmierung.
Heute genauso wie Damals. Aber halt genauso wie damals mit einem Auge darauf was für ein BASIC. Und Commodore oder Apple BASIC ist halt nie als Sprache für Anwendungen gedacht gewesen. Es ist immer nur eine Zugabe der Hardwarehersteller gewesen. Etwas das sie Eingekauft haben, damit sie Ihre Hardware verkaufen können. Das gilt im Prinzip für fast alle BASIC die damals mit Heimcomputern verkauft wurden. Sie waren nicht Produkte, sondern Vertriebsargumente.
Alle bis auf zwei Ausnahmen:
- TI-99 BASIC, welches von der Idee her ein Downport des Minicomputer BASICs war, ein Produkt, das dort nur gegen zusätzlich Geld zu haben war, also für sich alleine vorher schon erfolgreich war um echte Aufgaben zu lösen. Und natürlich
- BBC-BASIC, da war der Rechner die Zugabe zum BASIC, dass als Vehikel extra für Unterricht dienen sollte.
Letzteres interessant, weil es in England den Wettbewerb der Hersteller von reiner Hardware hin auf den Rechner als Gesamtsystem gebracht hat, was mit
- Locomotive BASIC und QL-BASIC
dann zwei bemerkenswerte Dialekte gebracht hat. Beides keine Business-BASIC, aber weit jenseits von C=BASIC 2.0
Also, wenn wenn man meint Mechanismen für Daten jenseits Commodore BASIC zu brauchen, dann ist ein Business-BASIC erste Wahl :))
Ansonsten: ACAB ... All Compilers Are Beautiful.
1. In Commo-BASIC gibts dann halt ein Feld AutoFarbe, eines AutoMarke$, AutoGeschwindigkeit, und so weiter. Und das Autos Nummern haben lernen die Kinder schon beim Blick auf die Straße. Echt, Strukturierung und Namensräume sind was für Weicheier :))
2. Commodore BASIC ist eine absolute Minimalimplementation und Lichtjahre entfernt von einem BASIC das man für eine derartige Aufgabe verwendet - es geht, es ist aber ungefähr genauso sinnvoll wie Spieleprogrammierung in Excel (Das es geht sagt nur was über den Willen derer die es gemacht haben aus).
Völlig richtig. Ich hatte bewusst Commodore Basic genannt, weil das häufig als optimale Einstiegssprache genannt wird. Wegen der geringen Komplexität. Da bin ich eben anderer Meinung.
Wenn ich z.B. Visual Basic nehme, dann bin ich ja auf dem Komplexitätsniveau anderer modernen Sprachen. Da sehe ich keinen großen Unterschied zu Python, C#, Javascript oder was auch immer.
Tja Objekt Orientierung galt lange zeit als das glückseligmachende Konzept mit Garantie für die absolute Lösung.
Das ist imho genauso quatsch wie all dies Hypes.
Deshalb sind Hybrid-Sprachen wie Delphi (oder auch C++) ja so schön, man kann je nach Projekt mal mit oder ohne OOP Ansatz programmieren. Kleine Projekte machen oft objektorientiert keinen Sinn. Bei größeren Problemen behaupte ich aber mal, ist OOP ungeschlagen, eben weil vieles an Code recycled und geerbt werden kann.
es ist ein Trugschluss zu glauben, man kõnne nur OOP programmieren, wenn die Sprache Vererbung unterstützt. Tatsächlich wird Vererbung oft an den falschen Stellen benutzt. Bei OOP geht es viel mehr um grundsätzliche Prinzipien wie Abstraktion, Delegation und Entkopplung mittels z.B. Kapselung. Das kann ich zur Not auch in C implementieren. Ein sehr schönes Beispiel dafür war Anfang der 90er Jahre OSF/Motif mit seinen Widget-Bibliotheken.
Umgekehrt entsteht aus einer Programmierung, die solche Grundprinzipien nicht berücksichtigt, leicht unwartbarer Spaghetti-Code. Das mag im Kleinen oft nicht auffallen, aber auf lange Sicht und im großen Rahmen ist Strukur Trumpf.
es ist ein Trugschluss zu glauben, man kõnne nur OOP programmieren, wenn die Sprache Vererbung unterstützt.
War auch nicht meine Aussage. Das zu OOP auch Kapselung, Abstraktion, Polymorphie und Wiederverwertbarkeit gehört steht ja nun in jedem Anfängerbuchzu dem Thema, oder frei nach Alexander von Humbold "Überall geht ein frühes Ahnen dem Wissen vorraus".
Trotzdem ist Vererbung das eigendliche Herzstück von Objekt orientierter Programmierung. Zu mindest lehrt das einem SmallTalk. Den ohne Vererbung hast du da garnichts. Jeder einzelne Datentyp wird da aus dem atomaren Grundobjekt zusammengebaut. Erst wenn ich das Konzept verstanden habe, kann ich auch mal auf Polymorphie und Abstraktion schauen, sonst ist es unheimlich schwer das Konzept in seiner Schönheit zu begreifen.
Ich hatte bei Turbo Pascal mit Objekten als Jugendlicher das Konzept auch erst nicht verstehen wollen...kann ich doch alles mit ein paar Pointern auf Records machen... Ja, denn das ist ja auch (vereinfacht) das Konzept von Polymorphie. Geht mit allen Sprachen die den Datentype allgemeiner Zeiger haben. Aber Vererbung ist halt schon der Kern von OOP. Das sieht man auch sehr schön in Sprachen wie GO.
...und jetzt kriegt der Humbold durch Vererbung noch sein t -> Humboldt. Armer Kerl.
es ist ein Trugschluss zu glauben, man kõnne nur OOP programmieren, wenn die Sprache Vererbung unterstützt.
War auch nicht meine Aussage. Das zu OOP auch Kapselung, Abstraktion, Polymorphie und Wiederverwertbarkeit gehört steht ja nun in jedem Anfängerbuchzu dem Thema, oder frei nach Alexander von Humbold "Überall geht ein frühes Ahnen dem Wissen vorraus".
Trotzdem ist Vererbung das eigendliche Herzstück von Objekt orientierter Programmierung. Zu mindest lehrt das einem SmallTalk. Den ohne Vererbung hast du da garnichts. Jeder einzelne Datentyp wird da aus dem atomaren Grundobjekt zusammengebaut. Erst wenn ich das Konzept verstanden habe, kann ich auch mal auf Polymorphie und Abstraktion schauen, sonst ist es unheimlich schwer das Konzept in seiner Schönheit zu begreifen.
Ich hatte bei Turbo Pascal mit Objekten als Jugendlicher das Konzept auch erst nicht verstehen wollen...kann ich doch alles mit ein paar Pointern auf Records machen... Ja, denn das ist ja auch (vereinfacht) das Konzept von Polymorphie. Geht mit allen Sprachen die den Datentype allgemeiner Zeiger haben. Aber Vererbung ist halt schon der Kern von OOP. Das sieht man auch sehr schön in Sprachen wie GO.
Zitat aus "Design Patterns" (dt. Entwurfsmuster):
"Gleichwohl ist unsere Erfahrung, dass Entwickler Vererberung als Technik der Wiederverwendung überstrapazieren.
Entwürfe können durch den verstärkten Einsatz von Objektkomposition häufig einfacher und leichter wiederverwendbar
gemacht werden. Sie werden der Anwendung von Objektkomposition in den Entwurfsmustern wiederholt begegnen."
Klar hat Vererbung auch seinen Platz. Aber gerade da geht C++ viel zu weit z.B. mit seiner Mehrfachvererbung und nicht
umsonst hat Java mit seinem Interface-Konzept bekräftigt, um was es wirklich geht. Im Head-First Buch "Design Patterns" gibt
es dazu ein schönes Beispiel mit einer Enten-Klasse, bei der man Verhalten wie fliegen oder quaken eben nicht vererben sollte,
weil es spätestens bei der Gummi-Ente Probleme erzeugt 
Neben der Vererbung gibt es aber noch einen anderes wunderschönes Konzept in C++ - Die Überladung.
Damit kann man recht interessante Sachen machen leider aber auch sehr viel Probleme mal eben schnell einfügen.
