NG Programmiersprache?

[Dravere]

~john schrieb:

• eine Art von Precompiler, der alle Typen der Sprache kennt und Typsicher Programmcode aus einem Metaprogramm herauserzeugen kann.

Das wäre definitiv sehr interessant. Wenn wir von zum Beispiel C++ ausgehen, dann die Makros und Templates rausschmeissen, dafür in die eigentliche Sprache hinein eine Code-Generator Sprache implementieren. Ich habe mir sogar schon mal Gedanken darüber gemacht, eine Sprache zu entwickeln, welche nur als Code-Generator dient. Man programmiert dann ein Programm, welches vom Kompiler ausgeführt wird, damit daraus ein Programm zum Übersetzen in die Maschinensprache entsteht.
Leider fehlt mir ein wenig die Zeit, diese Gedanken mal besser zu ordnen und niederzuschreiben.

thatway schrieb:

~john schrieb:

[*]Mehrfachvererbung

Wozu brauchst du das?

Gegenfrage: Wieso sollte man es verbieten? Und komm mir bitte nicht mit der Begründung, weil der Programmierer zu dumm ist, dieses Konzept vernünftig anzuwenden, denn dann darfst du ihn erst gar nicht programmieren lassen

Grüssli

[thatway]

Dravere schrieb:

thatway schrieb:

~john schrieb:

[*]Mehrfachvererbung

Wozu brauchst du das?

Gegenfrage: Wieso sollte man es verbieten? Und komm mir bitte nicht mit der Begründung, weil der Programmierer zu dumm ist, dieses Konzept vernünftig anzuwenden, denn dann darfst du ihn erst gar nicht programmieren lassen

Grüssli

Weil man es nicht braucht. Keiner konnte mir bisher einen Fall nennen bei dem es vernünftig ist Mehrfachvererbung zu verwenden und es sonst keine bessere Lösung gibt.

[mehrfach]

Wie löst du denn das wenn du Methoden und/oder Eigenschaften von zwei Basisklassen brauchst ohne irgendwas neu implementieren zu müssen?

Beispiele wurde hier schon genannt und jedem fällt da bestimmt auch noch was ein, außer dir anscheinend. Also entweder willste nicht oder kannst nicht, such es dir aus.

Mir würde noch einfallen der Fleisch- und Pflanzenfresser. Der Mensch würde dann aus beiden Klassen erben.

[wortmeldung]

Wahrscheinlich ist er so ein nur Virtuell-Maschine Programmierer oder halt ein Script-Kiddie oder halt einfach ein Troll der von nix eine Ahnung hat. Bitte gebt sowas keine Bühne hier, das ist das einzige Forum in deutsch wo die wirklichen Profis zu finden sind.

[thatway]

mehrfach schrieb:

Wie löst du denn das wenn du Methoden und/oder Eigenschaften von zwei Basisklassen brauchst ohne irgendwas neu implementieren zu müssen?

Beispiele wurde hier schon genannt und jedem fällt da bestimmt auch noch was ein, außer dir anscheinend. Also entweder willste nicht oder kannst nicht, such es dir aus.

Mir würde noch einfallen der Fleisch- und Pflanzenfresser. Der Mensch würde dann aus beiden Klassen erben.

Ja, immer so schöne Beispiele wie wir sie doch immer programmieren. Ich kann mich noch gut an mein letztes fliegendes Auto das von einem Fleischfresser gesteuert wurde errinnern. Es kommen immer nur so Anfängerbeispiel bei denen ein "Mensch" oder ein "Amphibienfahrzeug" programmiert wird. Vorher wurde "ein GUI-Button der mit Klicks und Gesten zurechtkommt" erwähnt, aber nicht wieso man da Mehrfachvererbung braucht.

wortmeldung schrieb:

Wahrscheinlich ist er so ein nur Virtuell-Maschine Programmierer oder halt ein Script-Kiddie oder halt einfach ein Troll der von nix eine Ahnung hat. Bitte gebt sowas keine Bühne hier, das ist das einzige Forum in deutsch wo die wirklichen Profis zu finden sind.

Das Gefühl hab ich auch, dass es hier nur darum geht, dass C++ Mehrfachvererbung hat und die Leute es deswegen toll finden. Komischerweise finde ich in unserem C++ Code nur sehr selten Mehrfachvererbung und dann nur solche Stellen bei denen was zusammengehackt wurde.

[player4245]

In Java z.B. wäre Mehrfachvererbung auch nicht schlecht, zumindest für diesen Fall:

public class MyFrame extends JFrame implements MouseListener, KeyListener
{
  // viele leere Methoden
  // bei mehrfachvererbung könnte man schreiben extends MouseAdapter, KeyAdapter
}

Oder bei meinem letzten Projekt mit C++ musste ich auch sowas schreiben:

class Window : public wxFrame, public irrklang::ISoundStopReceiver
{
  // ...

Zeige mir doch bitte eine Alternative ohne Mehraufwand die das selbe macht.
Also so unnötig ist Mehrfachvererbung gar nicht.

[thatway]

Genau das macht man mit Mehrfachvererbung, immer diese Klassen die alles sind, weil man da ja so schön wenig Tipparbeit hat und alles lustig auf alles zugreifen kann. Warum muss ein Fenster irgendwelche Logik für SoundStop enthalten?

Wie schon anfangs gesagt. Has-A vs. Is-A.
Einfach mal das lesen: http://www.c-plusplus.net/forum/viewtopic-var-p-is-532117.html

[player4245]

Das Fenster beinhaltet die entsprechenden Objekte um Sounds abzuspielen. Also warum sollte nicht auch der Listener in der Fensterklasse sein?
Der Übersichtlichkeit des Codes dient es jedenfalls nicht, wenn ich extra für den Listener eine extra Klasse hernehme. Das wäre nix weiter als ein frickeliger Workaround. Frei nach dem Motto: Warum einfach wenns auch kompliziert geht? Zu bedenken ist auch das ich dieser Klasse dann noch eine Referenz auf das Fenster mitgeben müsste.
Alles in allem wäre das Programmier- und Speicheraufwändiger als meine Lösung. Also WARUM sollte man es tun??
Der einzige der es so lösen würde wäre eins dieser "OOP ist die Lösung aller Informatikprobleme"-Opfer die sowieso keine Lösung "elegant" genug finden.

P.S. Auf mein Java-Beispiel bist du gar nicht eingegangen.

[Antoras]

player4245 schrieb:

In Java z.B. wäre Mehrfachvererbung auch nicht schlecht, zumindest für diesen Fall:

public class MyFrame extends JFrame implements MouseListener, KeyListener
{
  // viele leere Methoden
  // bei mehrfachvererbung könnte man schreiben extends MouseAdapter, KeyAdapter
}

Das würde man mit anonymen Klassen machen. Dein Bsp. macht absolut kein Sinn, da das Frame sowieso noch Komponenten hat, auf die die Listener viel besser zugeordnet werden können. Im schlechtesten Fall erhält das Frame sowieso nie den Fokus, die Listener würden also nie aufgerufen werden.

player4245 schrieb:

Der Übersichtlichkeit des Codes dient es jedenfalls nicht, wenn ich extra für den Listener eine extra Klasse hernehme.

Genau dafür gibt es anonyme Klassen. Diese sind übersichtlicher. Weil man damit genau feststellen kann welcher Listener zu welcher Komponente gehört.

Scala löst Mehrfachvererbung durch traits, die dem Prinzip der Linearisierung folgen. Das heißt, wenn es mehrere gleichnamige Methoden gibt, dann werden diese nacheinander aufgerufen und deren Werte werden weitergereicht.

[thatway]

player4245 schrieb:

Das Fenster beinhaltet die entsprechenden Objekte um Sounds abzuspielen.

Das ist ja schon der Fehler. Modularisierung. http://de.wikipedia.org/wiki/Model_View_Controller . Das Fenster ist nicht der Controller für Sound.

P.S. Auf mein Java-Beispiel bist du gar nicht eingegangen.

Weil alles das gleiche Problem ist. Du machst eine Klasse zur Superklasse die für alles verantwortlich ist, statt zu modularisieren.

[player4245]

Antoras schrieb:

player4245 schrieb:

In Java z.B. wäre Mehrfachvererbung auch nicht schlecht, zumindest für diesen Fall:

public class MyFrame extends JFrame implements MouseListener, KeyListener
{
  // viele leere Methoden
  // bei mehrfachvererbung könnte man schreiben extends MouseAdapter, KeyAdapter
}

Das würde man mit anonymen Klassen machen. Dein Bsp. macht absolut kein Sinn, da das Frame sowieso noch Komponenten hat, auf die die Listener viel besser zugeordnet werden können. Im schlechtesten Fall erhält das Frame sowieso nie den Fokus, die Listener würden also nie aufgerufen werden.

OK das Fenster hat noch Komponenten. Alles klar:

public class MeinPanel extends JPanel implements MouseListener
{
  // ..
}

Anonyme Klassen sind vielleicht auch eine Lösung, aber besonders in diesem Beispiel lang nicht so übersichtlich.
Nun was C++ angeht, diese Sprache besitzt dieses Feature ja nicht, also ist Mehrfachvererbung dort dann doch noch der Weisheit letzter Schluss.

[*john 0]

thatway schrieb:

Das führt immer nur zu diesen Superklassen die alles sind anstatt das die Funktionalität aufgeteilt wird.

Eben dies ist nicht der Fall. Der Klassiker ist wohl das Problem der Serialisierung. In den meisten Programmiersprachen wird dies per Interface gelöst, welches dann von jeder konkreten Klasse implementiert werden muß. Das ist ganz klassisch eine "ist-ein"-Beziehung. Und es gibt keinen wirklichen Grund das ganze auf Interfaces zu beschränken, echte Klasse funktionieren genauso gut.

[Antoras]

Vererbung sollte man möglichst umgehen, da man sich nie sicher sein kann ob man die Superklasse vllt. nicht doch noch mal ändern muss.

class InheritanceTest extends JFrame {
	public InheritanceTest() {
		setDefaultCloseOperation(EXIT_ON_CLOSE);
		setSize(x, y);
		setVisible(true);
	}
}

Was wenn du irgendwann feststellst, dass ein JPanel als Superklasse besser wäre? Das bekommst du dann nur unter enormen Aufwand refactored. Bei einer Assoziation hingegen musst du nur wenig ändern.

class AssociationTest {
	public AssociationTest() {
		JFrame f = new JFrame();
		f.setDefaultCloseOperation(JFrame.EXIT_ON_CLOSE);
		f.setSize(x, y)
		f.setVisible(true);
	}
}

Und dabei kann dir die IDE helfen. Im besten Fall musst du einfach nur die Erzeugung von Objekten umschreiben und brauchst den bestehenden Code des JFrames gar nicht zu ändern.

[thatway]

~john schrieb:

thatway schrieb:

Das führt immer nur zu diesen Superklassen die alles sind anstatt das die Funktionalität aufgeteilt wird.

Eben dies ist nicht der Fall. Der Klassiker ist wohl das Problem der Serialisierung. In den meisten Programmiersprachen wird dies per Interface gelöst, welches dann von jeder konkreten Klasse implementiert werden muß. Das ist ganz klassisch eine "ist-ein"-Beziehung. Und es gibt keinen wirklichen Grund das ganze auf Interfaces zu beschränken, echte Klasse funktionieren genauso gut.

Dein Argument geht voll an meiner Aussage vorbei. Warum sollte eine Klasse jetzt nicht so eine Monsterklasse werden, wenn sie auch noch für die Serialisierung zuständig ist? Was machst du dann wenn du ein Objekt auf verschiedene Arten serialisieren willst? Implementiert die Klasse dann XMLSerializable, BinarySerializable, DBSerializable... und dann hoffst du das die nicht alle eine gleiche Methode "serialize" wollen?

[player4245]

Naja wenn du diese Meinung vertrittst solltest du vielleicht auf OOP verzichten. Vererbung ist nun mal ein Konzept der OOP und bewährt sich ja ganz gut.
Und mal ganz im Ernst: wenn man jede Form von Aufwand scheut sollte man nicht Programmieren.
Bei deinem Beispiel verstehe ich das Problem auch nicht wirklich. Auch wenn man den JFrame durch ein JPanel ersetzt muss man nicht viel ändern, in beiden Fällen nicht. Denn wenn man schon auf die Idee kommt das ganze auszutauschen, dann wird man die Klasse wohl kaum als spezielles Fenster betrachten, und dann auch nur Methoden nutzen die beide Klassen (JFrame und JPanel) von der Oberklasse geerbt haben (wo wir wieder bei der Nützlichkeit von Vererbung wären ^^).

[Michael E.]

player4245 schrieb:

Naja wenn du diese Meinung vertrittst solltest du vielleicht auf OOP verzichten. Vererbung ist nun mal ein Konzept der OOP und bewährt sich ja ganz gut.

Vererbung wird viel zu oft missbraucht an Stellen, wo andere Mittel besser wären. Wenn man dann keine Vererbung benutzen willst, wird einem direkt vorgeworfen, man würde nicht objektorientiert programmieren

Mit der Meinung steh ich auch nicht allzu alleine da. Mal das erstbeste Buch aufschlagen: Exceptional C++.

Vererbung wird sogar von erfahrenen Entwicklern häufig zu oft benutzt.

Bevorzugen Sie Aggregation ("Komposition", "Layering", "HAT-EIN", "Deligierung") gegenüber Vererbung. Drücken Sie IST-IMPLEMENTIERT-MIT immer durch Aggregation und nicht durch Vererbung aus.

[*john 0]

thatway schrieb:

Dein Argument geht voll an meiner Aussage vorbei.

Nein, Du verstehst das Problem wohl eher nicht.

thatway schrieb:

Warum sollte eine Klasse jetzt nicht so eine Monsterklasse werden, wenn sie auch noch für die Serialisierung zuständig ist?

Nein, das ist nicht der Fall.

thatway schrieb:

Was machst du dann wenn du ein Objekt auf verschiedene Arten serialisieren willst?

Ein brauchbares Framework entwerfen, was das kann. Das ist im aktuellen C++ mangels dynamic dispatching eher ein Quahl (daher die Featureliste von mir), aber es geht trotzdem.

thatway schrieb:

Implementiert die Klasse dann XMLSerializable, BinarySerializable, DBSerializable...

Nein, wenn Du das machst, hast Du einen heftigen Designfehler gemacht. Das Frameworks muß wissen, wie es die integralen Datentypen auf das jeweiligen Backend serialisiert. Die Applikation muß dann nur das Backend auswählen, und jede konkrete Klasse muß sagen welche Dinge serialisiert werden müssen. Daher kann auch nur die konkrete Klassen "wissen" was zu serialisieren ist. Aus diesem Grund kommt eine Dekomposition auch nicht in Frage.

Schau Dir doch einfach mal ein entsprechendes Framework in einer Sprache an, die dynamic dispatching hat und entsprechend flexibel ist.

[Antoras]

player4245 schrieb:

Und mal ganz im Ernst: wenn man jede Form von Aufwand scheut sollte man nicht Programmieren.

Genau das ist der springende Punkt. Vererbung ist eben kein Aufwand. Es ist viel einfacher zu erstellen als komplizierte Beziehungsgeschichten.

player4245 schrieb:

Bei deinem Beispiel verstehe ich das Problem auch nicht wirklich. Auch wenn man den JFrame durch ein JPanel ersetzt muss man nicht viel ändern, in beiden Fällen nicht. Denn wenn man schon auf die Idee kommt das ganze auszutauschen, dann wird man die Klasse wohl kaum als spezielles Fenster betrachten, und dann auch nur Methoden nutzen die beide Klassen (JFrame und JPanel) von der Oberklasse geerbt haben (wo wir wieder bei der Nützlichkeit von Vererbung wären ^^).

Weißt du jetzt schon ob du deinen Code in einem Jahr noch erweitern / wiederbenutzen willst? Oft eben nicht und Vererbung ist eben nicht allgemein - sie bindet. Bei den paar Zeilen Beispielcode sieht man das noch nicht so, aber du hast da schnell mal ein paar Tausend Zeilen Code zusammen. Spätestens wenn du zu den Methoden noch Attribute aus der Oberklasse nutzt gibt es praktisch keine Möglichkeit mehr den Code wiederzuverwenden.

Du darfst nämlich nicht vergessen, dass nicht nur die Superklasse zur Wiederverwendung dienen soll, sondern auch eine Unterklasse.

[thatway]

~john schrieb:

thatway schrieb:

Dein Argument geht voll an meiner Aussage vorbei.

Nein, Du verstehst das Problem wohl eher nicht.

thatway schrieb:

Warum sollte eine Klasse jetzt nicht so eine Monsterklasse werden, wenn sie auch noch für die Serialisierung zuständig ist?

Nein, das ist nicht der Fall.

thatway schrieb:

Was machst du dann wenn du ein Objekt auf verschiedene Arten serialisieren willst?

Ein brauchbares Framework entwerfen, was das kann. Das ist im aktuellen C++ mangels dynamic dispatching eher ein Quahl (daher die Featureliste von mir), aber es geht trotzdem.

thatway schrieb:

Implementiert die Klasse dann XMLSerializable, BinarySerializable, DBSerializable...

Nein, wenn Du das machst, hast Du einen heftigen Designfehler gemacht. Das Frameworks muß wissen, wie es die integralen Datentypen auf das jeweiligen Backend serialisiert. Die Applikation muß dann nur das Backend auswählen, und jede konkrete Klasse muß sagen welche Dinge serialisiert werden müssen. Daher kann auch nur die konkrete Klassen "wissen" was zu serialisieren ist. Aus diesem Grund kommt eine Dekomposition auch nicht in Frage.

Schau Dir doch einfach mal ein entsprechendes Framework in einer Sprache an, die dynamic dispatching hat und entsprechend flexibel ist.

Schön, wie du alles verdrehst. Du warst doch für Mehrfachvererbung was dann ja zu "XMLSerializable, BinarySerializable, DBSerializable" führen würde und jetzt willst du plötzlich dynamic dispatching und tust so als ob ich die Designfehler mach...

[*john 0]

thatway schrieb:

Schön, wie du alles verdrehst.

Geh auf die erste Seite des Threads schau Dir noch einmal meine Liste an und Du wirst darin sowohl Mehrfachvererbung wie auch Dynamic Dispatching finden. Es hat seine Gründe, weshalb ich beides in einer Sprache haben will. Ich habe meinen Standtpunkt im Verlauf des Threads nicht verändert, auch wenn Du mir anders unterstellst.

thatway schrieb:

Du warst doch für Mehrfachvererbung was dann ja zu "XMLSerializable, BinarySerializable, DBSerializable" führen würde

Wenn Du nicht weißt wie man das richtig entwirft, mach dafür nicht Deine Mitmenschen verantwortlich. Es gibt mittlerweile eine reichhaltige Entwurfsmusterliteratur, darin kannst Du solche Grundlagen nachlesen.