Methoden mit bool-Parametern und "Lesbarkeit" im Kontext
-
otze schrieb:
heutige PCs sind keine Turingmaschienen, also ist auch die zustandslogik fehl am Platz. ...
Objekte haben ohnehin nichts mit dem Entscheidungsproblem oder speziell mit
Sprachen, Berechenbarkeit oder Komplexitaet zu tun.gruss
v R
-
post nr 101 - wer hätte das gedacht, 2 xin-troll-threads in einem monat
-
CStoll schrieb:
Xin schrieb:
CStoll schrieb:
Ein Fenster ist kein Zustand, sondern ein (mehr oder weniger) real existierendes Objekt. Ein Dialog ist eine spezielle Art von Fenster.
Und was bitte schön ist ein Objekt? Eine Zustandsbeschreibung für etwas, was mit einer Klasse klassifiziert wird.
Auto: rot, 195km/h Spitze, Benziner.
Window: Aktiviert, Position( x, y ).So langsam blicke ich durch deine Sichtweise durch - aber die scheint weniger objektorientiert zu sein, sondern datenorientiert.
Datenorientiert? Klassenorientiert.
Egal. Daten - Klasseninstanzen - alles Objekte.Was ich amüsant finde ist, wie sich viele an dem Wort "objekt" festklammern, als ob es eine wichtige Bedeutung hätte. Warum programmiert man denn, weil es soviel Spaß macht, oder weil man Daten miteinander verwursten will?
CStoll schrieb:
OK, was ist ein "Objekt"? Ein Objekt ist ein Gegenstand, mit dem ich interagieren kann. In das Auto kann ich einsteigen, auf's Gaspedal treten oder auf den Tacho schauen (und wenn ich nicht aufpasse, es auch in der nächsten Mauer parken), das Fenster kann ich anklicken oder ihm verschiedene Tastenkombinationen schicken. Zustände sind da eher zweitrangig und gehören zu den Interna des Objekts - nach außen wirken sie sich nur dadurch aus, daß das Objekt anders auf meine Aktionen reagiert.
(und wie ein Zustand intern dargestellt wird, ist für mich als Klassennutzer auch irrelevant - das Auto könnte seine Maximalgeschwindigkeit direkt als double speichern, über physikalische Berechnungen aus der Leistungskurve seines Motors ermitteln oder auch aus einer Datenbank des Herstellers abfragen - aber was es macht, ist Entscheidung des Autos und nicht der Maximalgeschwindigkeit)
Du widersprichst Dir grade.
Wichtig ist, dass es nach außen als Ganzes funktioniert. Ob die class VMax oder das class Car selbst die Maximalgeschwindigkeit verwaltet, ist ein Interna der Klasse Car. Es muss also kein Member sein.CStoll schrieb:
Schön, wenn du eine Sprache hast, die zwischen Zuständen und Teilobjekten unterscheiden kann. C++ kann das leider nicht, also brauchst du gar nicht versuchen, es dazu zu bringen.
Super Einstellung. "Ich" kann das nicht, also brauchst "Du" es nicht zu versuchen.
Ich versuche es trotzdem. Sich derart dagegen zu wehren bringt aber nix, ich zwinge schließlich niemanden hier, es zu nutzen.CStoll schrieb:
Xin schrieb:
CStoll schrieb:
Wenn du einen int mit einer Maßeinheit versehen willst, um Strecken und Gewichte unterscheiden zu können, geht das in die richtige Richtung. Aber Hilfsklassen anlegen zu müssen, nur um einer Area zwei Maßzahlen übergeben zu können halte ich ein wenig übertrieben.
Ähh... moment... Du beklagst Dich, über die bei mir fehlende Unterscheidung WindowFlag und WindowFlags und jetzt wird's übertrieben, wenn ich Maßeinheiten klassifiziere?!
Ein Unterschied zwischen Zahl und Zahl mit Maßeinheit ist klar, aber den kannst du nicht vernünftig mit Vererbung nachbauen (wenn alle Maßgrößen von int abgeleitet werden, kannst du auch alle Maßgrößen als nackte int's behandeln
Kilo AddiereGewichte( Kilo a, Kilo b ) { return a+b; }
Dann übergib da mal ein int.CStoll schrieb:
und damit auch beliebig miteinander verrechnen. Und erzähl mir blos nicht, daß du eine Addition von Gewicht+Länge auf dieser Basis verhindern kannst.
Warum sollte ich das verhindern?
4kg und 7m. Wenn ich die Zahl des Gewichts mit der Zahl der Länge addiere, erhalte ich 11. Ist doch eine legitime Fragestellung. Was immer man mit der Zahl anfangen will. Was ich nicht erhalte sind 11 Kilometer oder derartiges.Ich kann eine Zuweisung auf Kilo oder auf Meter verhindern.
Ich kann aber zum Beispiel 7m * 8m berechnen. Daraus ergeben sich Meter2, die ich nicht auf eine Metervariable zuweisen kann.
Operatorüberladung ist das Zauberwort, freundlich kombiniert mit "explizit".CStoll schrieb:
Was ich an dem oberen Ansatz bemängle, ist zum Beispiel die Unterscheidung von PixelWidth und PixelHeight - beide Typen sind technisch gleichwertig und wurden nur eingeführt, damit Area zwei Pixelmaße in sich vereinigen kann.
Okay, das bemängelst Du mit einer technsich falschen Begründung. Sie sind eben nicht technisch gleichwertig, weil - wie der Name schon sagt - das eine ist eine Breite und das andere eine Höhe. Und wenn Du ein Schiff konstruierst und dabei Breite und Höhe gleichwertig, also austauschbar machst, dann könnte es sein, dass das Schiff recht merkwürdig aussieht.
Werte müssen klassifiziert werden - entweder durch die Disziplin des Entwicklers - oder durch Klassen, deren Zweck es ist, Werte zu klassifizieren.CStoll schrieb:
Xin schrieb:
CStoll schrieb:
Und außerdem tendiert der Ansatz auf Dauer zu extrem langen Variablennamen (gerade wenn ich mehrere technisch ähnliche Klassen an verschiedenen Stellen des Programms verwenden will).
Mein Ansatz tendiert zu überhaupt keinen Variablennamen und vor allem tendiert er dazu "ähnliche" Klassen zu vermeiden.
OK, dann eben zu Klassennamen.
Hmm... Point, Area, BitMap, Soucetext, XMLEntity. Das sind keine lange Klassennamen.
Ansonsten bietet C++ auch Namespaces, von denen ich rege Gebrauch mache.CStoll schrieb:
Und schon hast du eine Asymmetrie in deinem Design - die Quelle ist ein Member, die Senke nicht. Und wenn du Filter mit mehreren Ausgängen hast, wird das Design unüberschaubar (entweder du splittest den Filter in zwei Teile auf, die die identischen Berechnungen duplizieren,
Überlege Dir mal kurz, was ein Filter ist. Einen Filter setzt man zum Beispiel in einen Laserstrahl, vorne kommt was rein, hinten kommt was raus. Du veränderst den Typ aber nicht. Es geht Licht rein und es kommt Licht raus.
Was Du kritisierst, ist kein Filter, sondern ein Adapter. Ergo falsche Kritik zu falschem Problem.
Das Design halte ich für optimal für einen Filter.Weiterhin duplizierst du keine Berechnungen, dafür gibt es notfalls templates, wenn Du das schon so lösen möchtest.
CStoll schrieb:
du fügst eine Zwischenklasse "zwei Areas" als Ausgang und zwei Splitter zum Zerlegen dieser Klasse ein oder zwei Hilfsklassen "TargetArea1" und "TargetArea2", von denen der Filter abgeleitet wird.
Gut, bauen wir einen Adapter auf, der zwei TargetAreas hat, die natürlich nicht TargetArea heißen würden. Nehmen wir unser Fenster und adaptieren es auf vier Punkte, die dann ObenLinks, UntenRechts usw.. heißen würden und direkt übertragbar für andere Objekte wären.
Und? Hättest Du ein Problem damit?
CStoll schrieb:
Ein Fenster hat eine linke obere Ecke, eine rechte untere Ecke und noch viele Punkte dazwischen - um jeden von denen ansprechen zu können, brauchst du entsprechend viele Zwischenklassen, die der Klasse "Punkt" jeweils einen neuen Namen geben. Außerdem interessiert es mich als Außenstehenden nicht, ob das Fenster nun zwei Ecken, Ecke+Größe oder Mittelpunkt+Größe intern verwaltet - ich interessiere mich nur danach, bei Bedarf jede Ecke oder den Mittelpunkt ansprechen zu können.
Und? Hindere ich Dich oder die Verwendung von Klassifizierungen daran?
CStoll schrieb:
Xin schrieb:
-Scott Meyers - Effiziente C++ Programmierung -
Dein Rechteck <-> Quadrath kommt ja offenbar auch daraus.
Selbiges gilt auch für die Fortsetzung.Ich erzeuge keine Pinguine, denn meine Fenster können fliegen und ich erstelle auch keine Methoden, die sich in der Hirachie wieder ändern. Du möchtest eine idiotische Frage verhindern, bei mir mache ich das nicht.
Und nun?"Xin ignoriert Scott Meyers" oder "Xin macht unübliche Dinge"?
Ich ignoriere ihn nicht. Und meine Klasse widerspricht ihm nichtmals, ich habe kein Problem damit, einen operator bool() zu haben.
Dass ich über den operator bool() in C++ nicht glücklich bin, sagte ich auch schon. Ich bin mit "int Flags;" aber auch nicht glücklich. Besser kann ich es in C++ nicht ausdrücken und weil das bei vielen Punkten der Fall ist, begann ich eine eigene Sprache zu definieren, die unter anderem Flags besser unterstützt.
Bis dahin muss ich mit operator bool() leben.Es ist vom Design egal, ob der operator bool() nun technisch gesichert ist oder nur durch eine Konvention.
Fakt ist, daß es keinen Sinn macht, ein Fenster als bool zu interpretieren - und damit verhält es sich nicht wie ein Flag.Es verhält sich wie WindowFlags. Nicht, wie ein Flag. Immernoch...
CStoll schrieb:
(übrigens taucht das Rechteck<->Quadrat Beispiel nicht nur bei Meyers auf)
Stimmt, aber solange es nicht im Zusammenhang mit der Problematik steht, juckt mich das auch nicht.
CStoll schrieb:
Dann mußt du auch damit leben, daß andere Programmierer deine Sichtweise nicht auf Anhieb verstehen.
Dieser Thread hat mich bisher nicht umgebracht.
Ich zwinge Dich nicht, Deine Daten zu klassifizieren. Ich habe kein Problem mit Membervariablen, ich sehe nur zusätzlich auch Alternativen. Ich habe hier nichts, was mir das Leben schwer macht.
Wenn Du eine alternative Sichtweise nicht auf Anhieb verstehst, wüßte ich jetzt nicht, wieso ich damit nicht leben könnte.CStoll schrieb:
Xin schrieb:
Nicht soviel, nur etwas. Nicht mehr als bei normalen Flags.
"Normale" Flags sind sehr sehr weit verbreitet
Bild und Express verkaufen sich auch sehr gut.
Und mit beiden kann man sehr gut Fenster putzen, wenn man sie auf Druckpapier castet und sich nicht auf das Interface "Schmierblatt" beschränkt.CStoll schrieb:
Xin schrieb:
Die Allergien schmeiße ich mal raus, die verlieren zusehens Bezug zum Thema.
Den Bezug hast du doch selber angefangen.
Ich sagte, dass ein Nussallergiker nicht auf einer Nusspackung darauf hingewiesen werden, dass sie für Nussallergiker nicht geeignet sind. Denken als Grundvoraussetzung. Deine Allergien oder die Deiner Oma interessieren mich in dem Thread nicht.
CStoll schrieb:
Xin schrieb:
Ich sehe das als selbsterklärend, selbst wenn da nicht WindowFlags::Fullscreen steht.
Du siehst es als selbsterklärend, weil du das Konzept durchschaut hast. Für mich ist dieser Ausdruck z.B. nicht selbsterklärend.
Dann solltest Du Dir überlegen, weitere Erfahrungen zu sammeln, statt Dich weiteren Erfahrungen nur zu widersetzen.
CStoll schrieb:
OK, dann anders - andere Sprachen mögen eine Unterscheidung zwischen Zuständen des Objekts und Teilobjekten bieten - C++ stellt beides durch Member dar (daß das nicht die perfekte Lösung ist, sehe ich ein).
Dann sieh bitte auch ein, dass C++ beides auch durch Vererbung anbietet und dass das auch nicht immer die perfekte Lösung ist. Trotzdem geht es.
CStoll schrieb:
Du bist anscheinend der Meinung, dort einen syntaktischen Unterschied zu benötigen - und wirfst darum Zustände mit Verwandschaftsbeziehungen in einen Topf.
...? Lies Dir den Satz nochmal durch...
CStoll schrieb:
Tellerrand schrieb:
Ich frage mich also: was spricht überhaupt für die Variante der Vererbung und gegen die Variante der Komposition?
Da muß ich meinen Vorrednern Recht geben - du hast weder ein Argument geliefert, warum die Komposition ungeeignet wäre,
Das könnte zum Beispiel daran liegen, dass ich die ganze Zeit betone, dass sie nicht ungeeignet ist...
CStoll schrieb:
noch eins für die Überlegenheit deines Vererbungsansatzes.
Das wiederum könnte daran liegen, dass ich nicht von "Überlegenheit" spreche, sondern von Alternative.
CStoll schrieb:
Auf den letzten Seiten hast du nur versucht, Argumente gegen deinen Ansatz zu entkräften (und damit dein Grundprinzip wieder verwässert).
Keine Ahnung, was Du als Verwässerung ansiehst. Eigentlich habe ich auf den letzten Seiten nur versucht, Dir zu zeigen, dass es Alternativen gibt, die auch Vorteile bieten - eben die Typsicherheit. Darum baue Flags in Klassen ein. Und hier kann man Typen vererbend zusammenbringen, ohne Mehrdeutigkeiten zu erhalten (wobei C++ bei Mehrfachvererbung verlangt, dass man in der abgeleiten Klasse using verwendet - es geht also doch wunderbar).
Vielleicht fällt Dir an der Tatsache, dass ich das mit der Mehrfachvererbung erst jetzt herausgefunden habe, auch auf, dass es sich hier nicht um "mein Grundprinzip" handelt und erst recht nicht um ein "Grundprinzip". Ich benutze Vererbung gelegentlich, um wiederverwertete Eigenschaften zu übertragen, aber das ist deswegen kein Grundprinzip (vgl. selbst da: Auto != Autositze).
Ich habe die Fürsprache für die Idee übernommen, die ich - je länger wir hier diskutieren - für immer besser halte. Du rennst gegen die Idee an, in einer Form, die ich mit "Hauptsache dagegen" am besten beschrieben sehe.
Und schau Dir Dein Posting mal an: Das meiste ist Geblubber, am Thema vorbei, subjektive Ablehnung, viel Konkretes kommt da auch nicht. Die Paprikaallergie Deiner Oma als Highlight. Darauf kann ich nicht argumentieren, sondern nur fragen, wo Du da ein Problem siehst. Und so liest Du hier mehrfach "Und?", weil mir der Zusammenhang mit dem Thema fehlt oder das Argument eben ist, dass Du es nicht auf Anhieb verstehst und andere es nicht benutzen. Das ist doch kein Argument, mal Alternativen auszuprobieren?!
Der einzige, der konkret was gebracht hat war Shade of Mine, was ich leider zu spät erst begriffen habe. Den Punkt halte ich für wichtig, aber nicht für so wichtig, dass ich auf die Typsicherheit verzichten würde. Zumal man den Punkt weiterhin durch genauere Klassifizierung in WindowFlags und WindowFlag ausräumen könnte.Bloß nicht gucken, ob da vielleicht ein Vorteil drin verborgen sein könnte. Ich beschäftige mich neutral damit: Komposition gut, Vererbung - auch nicht schlecht.
Das "Komposition gut" fällt Dir überhaupt nicht auf, oder? Das ist nichts, wo Du dagegen sein könntest.
Noch striktere Klassifizierung erforderlich? Sehr gut, weil Disziplin zwangsverordnet.Ich führe hier keinen Wettstreit gut gegen böse. Es geht hier um eine Alternative. Gut gegen genauso gut. Vielleicht gut gegen nicht ganz so gut in C++. Vielleicht auch gut gegen etwas besser, wenn man sich damit auseinandersetzt. Ich habe damit nur begrenzte Erfahrung, ich leite nicht grundsätzlich ab. Ich leite nur ein Objekt von seinen Flags ab und überlege, ob ich neue Klassen aus Vorhandenen sinnvoll zusammenvererben kann. Was mir nicht sinnvoll erscheint, kommt als Member rein.
otze schrieb:
heutige PCs sind keine Turingmaschienen, also ist auch die zustandslogik fehl am Platz.
OMG, genau sowas fehlte hier noch... geballte Kompetenz als Behauptung verpackt und auch noch öffentlich ausgesprochen.
Benutzername: schrieb:
post nr 101 - wer hätte das gedacht, 2 xin-troll-threads in einem monat
Und alle Unregistrierten sind auch schon da. Damit ist das Niveau des Threads gesichert.
CStoll, wenn Du von "Ich bin dagegen" auf "Ich bin nicht zwangsläufig dagegen" runterschalten kannst und diskutieren möchtest - meine E-Mailadresse findet sich auf meiner Homepage. Hier fällt grade der Forums-Kindergarten ein und sollte dem so sein, hab' ich da keine Lust drauf.
-
Xin schrieb:
CStoll schrieb:
Xin schrieb:
CStoll schrieb:
Ein Fenster ist kein Zustand, sondern ein (mehr oder weniger) real existierendes Objekt. Ein Dialog ist eine spezielle Art von Fenster.
Und was bitte schön ist ein Objekt? Eine Zustandsbeschreibung für etwas, was mit einer Klasse klassifiziert wird.
Auto: rot, 195km/h Spitze, Benziner.
Window: Aktiviert, Position( x, y ).So langsam blicke ich durch deine Sichtweise durch - aber die scheint weniger objektorientiert zu sein, sondern datenorientiert.
Datenorientiert? Klassenorientiert.
Egal. Daten - Klasseninstanzen - alles Objekte.Was ich amüsant finde ist, wie sich viele an dem Wort "objekt" festklammern, als ob es eine wichtige Bedeutung hätte. Warum programmiert man denn, weil es soviel Spaß macht, oder weil man Daten miteinander verwursten will?
CStoll schrieb:
OK, was ist ein "Objekt"? Ein Objekt ist ein Gegenstand, mit dem ich interagieren kann. In das Auto kann ich einsteigen, auf's Gaspedal treten oder auf den Tacho schauen (und wenn ich nicht aufpasse, es auch in der nächsten Mauer parken), das Fenster kann ich anklicken oder ihm verschiedene Tastenkombinationen schicken. Zustände sind da eher zweitrangig und gehören zu den Interna des Objekts - nach außen wirken sie sich nur dadurch aus, daß das Objekt anders auf meine Aktionen reagiert.
(und wie ein Zustand intern dargestellt wird, ist für mich als Klassennutzer auch irrelevant - das Auto könnte seine Maximalgeschwindigkeit direkt als double speichern, über physikalische Berechnungen aus der Leistungskurve seines Motors ermitteln oder auch aus einer Datenbank des Herstellers abfragen - aber was es macht, ist Entscheidung des Autos und nicht der Maximalgeschwindigkeit)
Du widersprichst Dir grade.
Wichtig ist, dass es nach außen als Ganzes funktioniert. Ob die class VMax oder das class Car selbst die Maximalgeschwindigkeit verwaltet, ist ein Interna der Klasse Car. Es muss also kein Member sein.Eben nicht - wenn die Klasse Vmax eine Verarbeitung vorgibt, ist die Klasse car darauf angewiesen, genau diese zu nutzen.
Xin schrieb:
CStoll schrieb:
Schön, wenn du eine Sprache hast, die zwischen Zuständen und Teilobjekten unterscheiden kann. C++ kann das leider nicht, also brauchst du gar nicht versuchen, es dazu zu bringen.
Super Einstellung. "Ich" kann das nicht, also brauchst "Du" es nicht zu versuchen.
Ich versuche es trotzdem. Sich derart dagegen zu wehren bringt aber nix, ich zwinge schließlich niemanden hier, es zu nutzen.Doch, du versuchst krampfhaft, mir zu erklären, daß dein Ansatz besser ist.
Xin schrieb:
CStoll schrieb:
Xin schrieb:
CStoll schrieb:
Wenn du einen int mit einer Maßeinheit versehen willst, um Strecken und Gewichte unterscheiden zu können, geht das in die richtige Richtung. Aber Hilfsklassen anlegen zu müssen, nur um einer Area zwei Maßzahlen übergeben zu können halte ich ein wenig übertrieben.
Ähh... moment... Du beklagst Dich, über die bei mir fehlende Unterscheidung WindowFlag und WindowFlags und jetzt wird's übertrieben, wenn ich Maßeinheiten klassifiziere?!
Ein Unterschied zwischen Zahl und Zahl mit Maßeinheit ist klar, aber den kannst du nicht vernünftig mit Vererbung nachbauen (wenn alle Maßgrößen von int abgeleitet werden, kannst du auch alle Maßgrößen als nackte int's behandeln
Kilo AddiereGewichte( Kilo a, Kilo b ) { return a+b; }
Dann übergib da mal ein int.Das ist ja auch kein Beispiel, wo es nötig ist zu vererben (btw, wenn das ohne einen eigenen op+ compiliert UND int-Übergabe verhindert, denke ich vielleicht näher über den tieferen Sinn nach).
Xin schrieb:
CStoll schrieb:
und damit auch beliebig miteinander verrechnen. Und erzähl mir blos nicht, daß du eine Addition von Gewicht+Länge auf dieser Basis verhindern kannst.
Warum sollte ich das verhindern?
4kg und 7m. Wenn ich die Zahl des Gewichts mit der Zahl der Länge addiere, erhalte ich 11. Ist doch eine legitime Fragestellung. Was immer man mit der Zahl anfangen will. Was ich nicht erhalte sind 11 Kilometer oder derartiges.Wenn ich ein Gewicht und eine Masse verrechnen, ist das genauso unsinnig wie der Cast eines Fensters nach bool).
Xin schrieb:
Ich kann aber zum Beispiel 7m * 8m berechnen. Daraus ergeben sich Meter2, die ich nicht auf eine Metervariable zuweisen kann.
Operatorüberladung ist das Zauberwort, freundlich kombiniert mit "explizit".Und was nützt dir die Vererbungsbeziehung, wenn du dann doch alles von Hand erledigen kannst? (btw, du kannst nichtmal zwei Gewichte addieren und ein Gewicht erhalten, ohne dir einen eigenen operator definieren zu müssen)
Xin schrieb:
CStoll schrieb:
Was ich an dem oberen Ansatz bemängle, ist zum Beispiel die Unterscheidung von PixelWidth und PixelHeight - beide Typen sind technisch gleichwertig und wurden nur eingeführt, damit Area zwei Pixelmaße in sich vereinigen kann.
Okay, das bemängelst Du mit einer technsich falschen Begründung. Sie sind eben nicht technisch gleichwertig, weil - wie der Name schon sagt - das eine ist eine Breite und das andere eine Höhe. Und wenn Du ein Schiff konstruierst und dabei Breite und Höhe gleichwertig, also austauschbar machst, dann könnte es sein, dass das Schiff recht merkwürdig aussieht.
Werte müssen klassifiziert werden - entweder durch die Disziplin des Entwicklers - oder durch Klassen, deren Zweck es ist, Werte zu klassifizieren.CStoll schrieb:
Xin schrieb:
CStoll schrieb:
Und außerdem tendiert der Ansatz auf Dauer zu extrem langen Variablennamen (gerade wenn ich mehrere technisch ähnliche Klassen an verschiedenen Stellen des Programms verwenden will).
Mein Ansatz tendiert zu überhaupt keinen Variablennamen und vor allem tendiert er dazu "ähnliche" Klassen zu vermeiden.
OK, dann eben zu Klassennamen.
Hmm... Point, Area, BitMap, Soucetext, XMLEntity. Das sind keine lange Klassennamen.
Ja, die Grundtypen sind noch recht kurz, aber darauf aufbauende Hilfstypen nicht mehr - und ein PixelWidth hat außerhalb der Area keinen eigenständigen Nutzen, wäre also technisch redundant.
Xin schrieb:
CStoll schrieb:
Und schon hast du eine Asymmetrie in deinem Design - die Quelle ist ein Member, die Senke nicht. Und wenn du Filter mit mehreren Ausgängen hast, wird das Design unüberschaubar (entweder du splittest den Filter in zwei Teile auf, die die identischen Berechnungen duplizieren,
Überlege Dir mal kurz, was ein Filter ist. Einen Filter setzt man zum Beispiel in einen Laserstrahl, vorne kommt was rein, hinten kommt was raus. Du veränderst den Typ aber nicht. Es geht Licht rein und es kommt Licht raus.
Was Du kritisierst, ist kein Filter, sondern ein Adapter. Ergo falsche Kritik zu falschem Problem.
Das Design halte ich für optimal für einen Filter.Weiterhin duplizierst du keine Berechnungen, dafür gibt es notfalls templates, wenn Du das schon so lösen möchtest.
Nehmen wir das Beispiel mit dem Laser - dort kann ich einen Splitter draufsetzen, der zwei Strahlen (fast identische) hinten rausspuckt. Für deinen Ansatz bräuchte ich jetzt zwei Teilsplitter, die fast die selben Berechnungen durchführen - und das "fast" verhindert den Einsatz von Templates.
Xin schrieb:
CStoll schrieb:
du fügst eine Zwischenklasse "zwei Areas" als Ausgang und zwei Splitter zum Zerlegen dieser Klasse ein oder zwei Hilfsklassen "TargetArea1" und "TargetArea2", von denen der Filter abgeleitet wird.
Gut, bauen wir einen Adapter auf, der zwei TargetAreas hat, die natürlich nicht TargetArea heißen würden. Nehmen wir unser Fenster und adaptieren es auf vier Punkte, die dann ObenLinks, UntenRechts usw.. heißen würden und direkt übertragbar für andere Objekte wären.
Ist dir schonmal aufgefallen, daß die Fensterpunkte nicht unabhängig voneinander sind? Wenn ich die obere linke Ecke verschiebe, rutschen ihre Nachbarn hinterher (sonst würde das Fenster schnell ziemlich verbogen aussehen).
Xin schrieb:
CStoll schrieb:
Ein Fenster hat eine linke obere Ecke, eine rechte untere Ecke und noch viele Punkte dazwischen - um jeden von denen ansprechen zu können, brauchst du entsprechend viele Zwischenklassen, die der Klasse "Punkt" jeweils einen neuen Namen geben. Außerdem interessiert es mich als Außenstehenden nicht, ob das Fenster nun zwei Ecken, Ecke+Größe oder Mittelpunkt+Größe intern verwaltet - ich interessiere mich nur danach, bei Bedarf jede Ecke oder den Mittelpunkt ansprechen zu können.
Und? Hindere ich Dich oder die Verwendung von Klassifizierungen daran?
Versuch mal die Beziehungen der Fensterpunkte untereinander darzustellen.
Xin schrieb:
Es verhält sich wie WindowFlags. Nicht, wie ein Flag. Immernoch...
OK, wie ein "Flags" - aber es verhält sich auch nicht wie ein Flags, denn Flags auf bool umzuwandeln macht durchaus Sinn.
Xin schrieb:
CStoll schrieb:
Xin schrieb:
Die Allergien schmeiße ich mal raus, die verlieren zusehens Bezug zum Thema.
Den Bezug hast du doch selber angefangen.
Ich sagte, dass ein Nussallergiker nicht auf einer Nusspackung darauf hingewiesen werden, dass sie für Nussallergiker nicht geeignet sind. Denken als Grundvoraussetzung. Deine Allergien oder die Deiner Oma interessieren mich in dem Thread nicht.
Diese "Achtung, Nüsse"-Warnung steht ja nicht nur auf Nuss-Packungen
Xin schrieb:
CStoll schrieb:
OK, dann anders - andere Sprachen mögen eine Unterscheidung zwischen Zuständen des Objekts und Teilobjekten bieten - C++ stellt beides durch Member dar (daß das nicht die perfekte Lösung ist, sehe ich ein).
Dann sieh bitte auch ein, dass C++ beides auch durch Vererbung anbietet und dass das auch nicht immer die perfekte Lösung ist. Trotzdem geht es.
Ich habe noch keine praktische Anwendung (abgesehen von deinen Code-Beispielen) gesehen, wo (öffentliche) Vererbung die bessere Darstellung für interne Zustände wäre.
Xin schrieb:
CStoll schrieb:
Du bist anscheinend der Meinung, dort einen syntaktischen Unterschied zu benötigen - und wirfst darum Zustände mit Verwandschaftsbeziehungen in einen Topf.
...? Lies Dir den Satz nochmal durch...
OK, dann langsam - du versuchst, Teile und Zustände syntaktisch unterschiedlich zu behandeln. Ein neues Sprachmittel dafür zu erfinden wäre sicher eine Lösung, ein bestehendes Sprachmittel (das schon seine vorgegebene Bedeutung hat: Vererbung == "ist-ein") dafür zu verwenden ist die falsche Lösung.
Xin schrieb:
CStoll schrieb:
Tellerrand schrieb:
Ich frage mich also: was spricht überhaupt für die Variante der Vererbung und gegen die Variante der Komposition?
Da muß ich meinen Vorrednern Recht geben - du hast weder ein Argument geliefert, warum die Komposition ungeeignet wäre,
Das könnte zum Beispiel daran liegen, dass ich die ganze Zeit betone, dass sie nicht ungeeignet ist...
CStoll schrieb:
noch eins für die Überlegenheit deines Vererbungsansatzes.
Das wiederum könnte daran liegen, dass ich nicht von "Überlegenheit" spreche, sondern von Alternative.
Du kennst die bisherigen Vorgehensweisen - die sind etabliert und stellen (fast) ideal das dar, was benötigt wird. Und du stellst einen eigenen Ansatz vor, der (aus Sicht fast aller Anwesenden) schlechter auf das Problem passt. Ergo solltest du uns davon überzeugen, daß dein Ansatz mindestens genauso gut ist wie unserer.
Xin schrieb:
CStoll schrieb:
Auf den letzten Seiten hast du nur versucht, Argumente gegen deinen Ansatz zu entkräften (und damit dein Grundprinzip wieder verwässert).
Keine Ahnung, was Du als Verwässerung ansiehst.
Nehmen wir als Beispiel die "if(win)"-Frage: Nachdem du darauf aufmerksam gemacht wurdest, daß sowas möglich ist, hast du erst gegengerudert und op bool privat deklariert - und im nächsten Moment gesagt, daß du keinen privaten op bool hast, sondern nur einen Hinweis, daß man nicht if(win) fragen sollte (was letztlich den selben Effekt hat, aber nicht vom Compiler überprüft werden kann).
Xin schrieb:
Eigentlich habe ich auf den letzten Seiten nur versucht, Dir zu zeigen, dass es Alternativen gibt, die auch Vorteile bieten - eben die Typsicherheit.
Um Typsicherheit zu gewährleisten, brauche ich keine Vererbungsbeziehungen. Die bekomme ich mit einer eigenen (freistehenden) Flag-Klasse genausogut.
Xin schrieb:
Bloß nicht gucken, ob da vielleicht ein Vorteil drin verborgen sein könnte. Ich beschäftige mich neutral damit: Komposition gut, Vererbung - auch nicht schlecht.
Das "Komposition gut" fällt Dir überhaupt nicht auf, oder? Das ist nichts, wo Du dagegen sein könntest.
Noch striktere Klassifizierung erforderlich? Sehr gut, weil Disziplin zwangsverordnet.Wenn das deine Meinung ist, hast du sie bisher sehr gut versteckt - für mich sah das eher nach "Komposition brauchbar - Vererbung wesentlich besser".
Xin schrieb:
Ich führe hier keinen Wettstreit gut gegen böse. Es geht hier um eine Alternative. Gut gegen genauso gut. Vielleicht gut gegen nicht ganz so gut in C++. Vielleicht auch gut gegen etwas besser, wenn man sich damit auseinandersetzt. Ich habe damit nur begrenzte Erfahrung, ich leite nicht grundsätzlich ab. Ich leite nur ein Objekt von seinen Flags ab und überlege, ob ich neue Klassen aus Vorhandenen sinnvoll zusammenvererben kann. Was mir nicht sinnvoll erscheint, kommt als Member rein.
Die Ableitung von Flags mag vielleicht technisch möglich sein, aber sie widerspricht immer noch den OOP-Prinzipien (aber wenn du nicht objektorientiert arbeitest, ist das natürlich kein Problem). Die Definition von Hilfsklassen, nur um mehrere gleichartige Eigenschaften in ein Objekt zu packen, halte ich für unsinnig und fehleranfällig. Und du hast immer noch nicht klargestellt, was der entscheidende Vorteil davon ist - von kryptischeren Quelltexten mal abgesehen.
-
Der unterhaltungswert ist gleich null, weil ihr immer viel zu viel schreibt. das will keiner lesen
-
Ich lese nur CStolls Posts, da er Xins zeug sinnvoll filtert.
-
CStoll schrieb:
Xin schrieb:
CStoll schrieb:
Schön, wenn du eine Sprache hast, die zwischen Zuständen und Teilobjekten unterscheiden kann. C++ kann das leider nicht, also brauchst du gar nicht versuchen, es dazu zu bringen.
Super Einstellung. "Ich" kann das nicht, also brauchst "Du" es nicht zu versuchen.
Ich versuche es trotzdem. Sich derart dagegen zu wehren bringt aber nix, ich zwinge schließlich niemanden hier, es zu nutzen.Doch, du versuchst krampfhaft, mir zu erklären, daß dein Ansatz besser ist.
Vielleicht macht Dir diese Antwort verständlich, wie krampfhaft ich versuche Dich von etwas zu überzeugen. Denk selbst drüber nach, oder lass es - es zwingt Dich niemand.
-
@Xin
ich empfehle dir folgendes Buch:
Design Patterns | ISBN: 0201633612
Insbesondere das Kapitel über Vererbung vs. Delegation.
Wenn du es gelesen hast und immer noch von "class Window: public WindowsFlags" überzeugt bist, dann solltest du es nochmal lesen und evtl. dann nochmal.
Ist echt ganz schön stur von dir zu behaupten, es sei aus OO Sicht völlig OK, obwohl dir hier schon 100x gezeigt wurde, dass das Murks ist.Gruß
mathik
-
mathik schrieb:
@Xin
ich empfehle dir folgendes Buch:
Design Patterns | ISBN: 0201633612
Insbesondere das Kapitel über Vererbung vs. Delegation.Auch das Buch steht als Standardwerk natürlich auch hier und ist längst gelesen.
mathik schrieb:
Wenn du es gelesen hast und immer noch von "class Window: public WindowsFlags" überzeugt bist, dann solltest du es nochmal lesen und evtl. dann nochmal.
...und vor allem immer brav im Gleichschritt marschieren und auf keinen Fall Wege suchen, die nicht irgendwer in einem Buch für gut beschrieben hat.
Die Gang Of Four hat die Design Patterns beschrieben, die Patterns sind gut, aber das ist keine Religion und die Patterns sind keine steingemeißelten Gebote. Auch wenn manche es so auffassen.
Erfahrung ist mehr als ein Buch gelesen zu haben. Erfahrung heißt Dinge auszuprobieren und das heißt auch Dinge auf Möglichkeiten abzuklopfen, die der Masse nicht zusagen.
Neues Wissen findet sich nicht in sauberen Büchern, sondern im Dreck dazwischen.Und da Du den Thread gelesen hast, weißt Du ja, dass das Ding, dass ich abklopfe eine Mischung aus privater und öffentlicher Vererbung ist und "class Window : public WindowFlags" eine vereinfachte Abwandlung davon ist.
Du hast sicherlich auch gelesen, dass der Fragesteller Möglichkeiten suchte und eine Möglichkeit habe ich angeboten, ob es CStoll oder Dir im Detail gefällt oder nicht. Die angebotene Möglichkeit muss nicht perfekt sein, um eine Möglichkeit zu sein. "int(Flags) & WFLG_FULLSCREEN" ist das übliche Vorgehen und das ist ebenfalls sehr weit entfernt von perfekt.
Wie Du auch bereits gelesen hast, stelle ich meinen Sourcecode lediglich als Möglichkeit, nicht als perfekte Möglichkeit dar.Vollkommen unabhängig davon, halte ich die Möglichkeit Eigenschaften scharf zu klassifizieren und durch Vererbung weiterzureichen, für eine SEHR interessanten Ansatz, Disziplin in der Programmierung zu erzwingen - vollkommen unabhängig davon, was in DesignPatterns oder Scott Meyers Büchern steht.
Zumindest bei Scott Meyer weiß ich, dass er seine Bücher nicht als Gott gegebene Regeln ansieht, sondern als Empfehlungen. Und als Empfehlungen sind seine Bücher verdammt gut.mathik schrieb:
Ist echt ganz schön stur von dir zu behaupten, es sei aus OO Sicht völlig OK, obwohl dir hier schon 100x gezeigt wurde, dass das Murks ist.
Mir wurde schon viel gezeigt und diese Tatsache wird nicht selten auch wieder vergessen, wenn sich die allgemeine Perspektive bewegt hat. Mir 100x das selbe zu zeigen, ein ganzes Forum gegen mich zu haben, nichtmals die Paprikaallergie von CStolls Oma beeindruckt mich diesbezüglich im Entferntesten. Ein einziges sauber und konstruktiv begründetes Argument hingegen kann Welten bewegen.
Shade hat ein Argument gebracht und CStoll hat mir die Augen geöffnet für mein Mißverständnis, so dass ich beiden zugestimmt habe, dass die Komposition in C++ wohl die bessere Wahl ist (Seite 7 afair). Derartige Details interessieren aber offenbar auch dann nicht, wenn ich es wiederhole, weil man sonst nicht weiter so schön gegen mich sein kann.
Den Punkt, den Shade angeführt hat, ist an meinem Source unschön, aber kein K.O.-Kriterium, da man es mit etwas Mehraufwand entsprechend umgehen kann und selbst ein operator bool() in einem Fenster kein Problem darstellt, dass im Alltag eine ernstzunehmende Gefahr darstellt.
Die Möglichkeit bleibt bestehen, ein Fenster als Erweiterung zu seinen Flags zu sehen, auch wenn das ungewöhnlich ist und in dem Source, den ich als Möglichkeit angeboten habe, der operator bool() nicht gefällt. Die Möglichkeit nicht optimal, aber definitiv auch nicht schlecht.
Ansonsten: Lies den Thread und lies, was ich schreibe, nicht was CStoll und/oder Du daraus interpretierst.
-
Xin schrieb:
...und vor allem immer brav im Gleichschritt marschieren und auf keinen Fall Wege suchen, die nicht irgendwer in einem Buch für gut beschrieben hat.
Einfach mal ohne werten zu wollen:
Krankhaft gegen den Mainstream sein ist genauso falsch wie krankhaft mit dem Mainstream sein zu wollen.
Der Mensch hat viele Idee - 99% davon ist Schrott. Es sind die 1% die den Unterschied machen. Diese 1% sind die guten Ideen.
Es ist sehr sehr einfach eine Idee zu haben die anders ist als alle gängigen. Das ist absolut kein Problem. Ich sehe mir ein Auto an und denke mir einfach eckige Räder dazu - tada - ich hab ein Auto das komplett anders ist als alle anderen.
Das Problem ist nun zu erkennen ob diese Idee eine von den 99% oder eine von den 1% ist.
Nun zu diesem konkreten Beispiel:
Deine Idee ist anders als der Mainstream. Aber ist sie besser oder gleichwertig? Ein Haufen Leute hat einen Haufen Gründe genannt warum sie schlechter ist und du kannst keinen nennen warum sie besser ist. Du kannst lediglich die Argumente warum es schlechter ist widerlegen - selbst wenn du aber alle widerlegst bleibt ein Problem bestehen:Es ist nicht besser als die herkömmliche Lösung - wohl aber anders. Und wenn etwas nur anders aber nicht besser ist, ist es defakto schlechter da es weniger Know-How hier gibt.
Deshalb sollte man immer ganz vorsichtig sein wenn man eine Idee als "gegen den Mainstream" bezeichnet. Denn meistens ist das Ziel einer solchen Idee einfach nur anders zu sein.
-
Xin schrieb:
Shade hat ein Argument gebracht und CStoll hat mir die Augen geöffnet für mein Mißverständnis, so dass ich beiden zugestimmt habe, dass die Komposition in C++ wohl die bessere Wahl ist (Seite 7 afair). Derartige Details interessieren aber offenbar auch dann nicht, wenn ich es wiederhole, weil man sonst nicht weiter so schön gegen mich sein kann.
[...]
Die Möglichkeit bleibt bestehen, ein Fenster als Erweiterung zu seinen Flags zu sehen, auch wenn das ungewöhnlich ist und in dem Source, den ich als Möglichkeit angeboten habe, der operator bool() nicht gefällt. Die Möglichkeit nicht optimal, aber definitiv auch nicht schlecht.Die Sache ist doch die, dass deine Probleme, die du offenbar auch siehst, genau deshalb entstanden sind, weil dein Code diesen aufgestellten Thesen widerspricht.
Das ist doch genau der Grund, warum Meyers, Sutter und wie sie alle heißen sowas in ihren Büchern schreiben. Weil sonst Probleme auftreten wie sie hier vielfach aufgedeckt wurden.
Das bool()-Problem z.B. tritt doch auf, weil deine public-Vererbung eben keine "IST-EIN"-Beziehung darstellt.
-
Xin schrieb:
Shade hat ein Argument gebracht und CStoll hat mir die Augen geöffnet für mein Mißverständnis, so dass ich beiden zugestimmt habe, dass die Komposition in C++ wohl die bessere Wahl ist (Seite 7 afair). Derartige Details interessieren aber offenbar auch dann nicht, wenn ich es wiederhole, weil man sonst nicht weiter so schön gegen mich sein kann.
Auch wenn Du Dir das anscheinend gern selbst einredest, niemand ist aus Prinzip gegen Dich. Das hast Du Dir ganz allein zuzuschreiben. Behauptung.
Begründung:
1. Genau diese Behauptung "alle sind gegen mich" (Arroganz, "ich bin so toll und wichtig, daß ich es wert bin, daß jemand gegen mich ist und dafür seitenweise schreibt")
2. Äußerungen wie "class DeppenWindow"
3. Äußerungen wie "die kids, ihre eltern, blabla"Ich zitiere einen Mathematikversager: "Schon die Voraussetzungen sind falsch"
Falsche Voraussetzungen sind u.a.:
- "WindowFlags sind Windows"
- "Ein Auto kann eine Farbe sein" <- spätestens hier krieg ich Pipi in die AugenÜbrigens habe ich Deine Zustimmung nicht auf Seite 7 finden können. Daher wäre es sehr nett, wenn Du Dich mal nicht auf dein Gedächtnis verlassen würdest.
Nehmen wir an, sie steht irgendwo anders. Das heißt, Du sagst, daß Deine Alternative "schlechter" ist. Dann mußt Du Dich dafür rechtfertigen, daß Du sie trotzdem verwendest. Da Du natürlich die "bessere" Alternative verstehst, kann es schonmal nicht an mangelnden (Programmier-)Fähigkeiten liegen. Jetzt wirds aber schon hakelig...
-
Shade Of Mine schrieb:
Xin schrieb:
...und vor allem immer brav im Gleichschritt marschieren und auf keinen Fall Wege suchen, die nicht irgendwer in einem Buch für gut beschrieben hat.
Einfach mal ohne werten zu wollen:
So kann man diskutieren.
Shade Of Mine schrieb:
Krankhaft gegen den Mainstream sein ist genauso falsch wie krankhaft mit dem Mainstream sein zu wollen.
Ich bin nicht krankhaft gegen den Mainstream, denn ich programmiere in den meisten Dingen ja auch nicht anders, als andere Entwickler auch. Das vielleicht mal explizit ausgesprochen - ich bin kein Crack, der möglichst schwer verständlichen Code produzieren will - absolut das Gegenteil ist der Fall.
Wo ich allerdings einen Unterschied ziehe ist, dass ich mich mit meinem Werkzeug - der Programmiersprache - sehr detailiert auseinandersetze und mich auch mit den Dingen beschäftige.
Das schließt auch Techniken ein, die andere als schlecht beschreiben und ich mache mir auch Gedanken, zu Dingen, die mit C++ nicht oder nicht einfach beschreibbar sind.
Vieles ist zurecht als schlecht verrufen und Bücher wie Design Patterns oder die Scott Meyer Bücher sind wertvolle Hilfen, um gut zu programmieren. Sie wurden dafür geschrieben eine Hilfe für gute Programmierung zu sein, aber nicht um als die einzige Wahrheit für gute Programmierung zu gelten.Was in einem Buch steht, muss weder richtig sein, noch muss ein gutes Buch ein Dogma darstellen. Der Irrglaube, dass Bücher, besonders bei hervorragenden Büchern, kritiklos hinzunehmen sind, ist weit verbreitet. Auch "hervorragend" bedeutet noch nicht "uneingeschränkt gültig".
Alleine die Tatsache jedes Fachbuch sofort und grundsätzlich in Frage zu stellen unterscheidet mich von vielen anderen. Ich sehe Quellen wie Bücher oder dieses Forum als Inspiration, nicht als einzige Wahrheit.
Shade Of Mine schrieb:
Nun zu diesem konkreten Beispiel:
Deine Idee ist anders als der Mainstream. Du kannst lediglich die Argumente warum es schlechter ist widerlegen - selbst wenn du aber alle widerlegst bleibt ein Problem bestehen: wenn etwas nur anders aber nicht besser ist, ist es defakto schlechter da es weniger Know-How hier gibt.Hier laufen zwei Dinge zusammen. Das eine ist die Klasse Flags und das andere die Vererbung. Die Klasse halte ich nachwie vor für richtig. Was die Vererbung in C++ angeht, so halte ich die Komposition aufgrund Deines Arguments bei meinem Beispiel-Code inzwischen für besser.
Trennt man die die Flags als Variable von den einzelnen Flags als Werten und somit die öffentlichen und privaten Teile, so sehe ich hier die Möglichkeit, dass das ganze besser ist.
Es ist nicht schwer besser als 'Flags & DEFINE_FULLSCREEN' zu sein.Shade Of Mine schrieb:
Deshalb sollte man immer ganz vorsichtig sein wenn man eine Idee als "gegen den Mainstream" bezeichnet. Denn meistens ist das Ziel einer solchen Idee einfach nur anders zu sein.
Meinen Ruf habe ich in diesem Forum ja bereits weg, ein kleines Rudel "Unregistrierter" sorgt bei nahezu jedem Posting dafür, dass das auch ja nicht vergessen wird.
Fakt ist, dass dieses Vorgehen nicht den Mainstream darstellt und damit "anders" ist. Mir geht es nicht, darum anders zu sein. Ich gebe mein Wissen weiter und oder eben hier eine Alternative zur Diskussion. Und ich stelle fest, dass daran nur eine Minderheit interessiert ist. Das ist enttäuschend, aber auch nicht unbedingt wichtig.
Hier geht es mir darum, universell benutzte Datentypen wie int zu vermeiden, darum die Klasse Flags. Das kann man akzeptieren oder lassen oder sich immer wieder auf die Vererbung der Flags stürzen, obwohl in dem Thema längst Einigkeit herrscht.Das Thema Vererbung als Memberkonzept ist unabhängig davon, eine interessante Möglichkeit anders zu programmieren, der ich durchaus gute Chancen für ein besseres Programmieren zuspreche. Aufwändiger, aber besser. Und besser rechtfertigt für mich bei vielbenutzten Klassen nahezu jeden Aufwand.
-
Xin schrieb:
Mir geht es nicht, darum anders zu sein. Ich gebe mein Wissen weiter und oder eben hier eine Alternative zur Diskussion. Und ich stelle fest, dass daran nur eine Minderheit interessiert ist. Das ist enttäuschend, aber auch nicht unbedingt wichtig.
Hier geht es mir darum, universell benutzte Datentypen wie int zu vermeiden, darum die Klasse Flags. Das kann man akzeptieren oder lassen oder sich immer wieder auf die Vererbung der Flags stürzen, obwohl in dem Thema längst Einigkeit herrscht.Auch wenn es unwichtig ist: Mich hast du zum nachdenken gebracht, auch wenn ich sicherlich nicht mir nix dir nix auf deine Methode umsteigen werde. Und interessant ist dein Konzept alle mal, jedenfalls wenn ich es richtig verstanden hab
-
Badestrand schrieb:
Xin schrieb:
Mir geht es nicht, darum anders zu sein. Ich gebe mein Wissen weiter und oder eben hier eine Alternative zur Diskussion. Und ich stelle fest, dass daran nur eine Minderheit interessiert ist. Das ist enttäuschend, aber auch nicht unbedingt wichtig.
Auch wenn es unwichtig ist: Mich hast du zum nachdenken gebracht, auch wenn ich sicherlich nicht mir nix dir nix auf deine Methode umsteigen werde. Und interessant ist dein Konzept alle mal, jedenfalls wenn ich es richtig verstanden hab
Wenn man Menschen nicht dazu veranlassen kann nachzudenken, so ist das nicht wichtig. Es ist nur ein Angebot.
Wenn das Angebot inspirieren konnte, so ist mir das Feedback schon wichtig, denn sonst bräuchte ich es nicht zu probieren.Dafür musst Du nicht Deine Programmierung nicht ändern. Sich bewußt zu machen, was man tut und was dadurch dass man es tut auf der anderen Seite unterlässt, das ist eingentlich der wichtigste Punkt.
Man kann sich nur dann dazu entscheiden, auch eigene Alternativen zu bauen, wenn frei genug im Denken ist, um überhaupt auf den Gedanken zu kommen, dass Alternativen möglich sind.
-
Xin schrieb:
Meinen Ruf habe ich in diesem Forum ja bereits weg, ein kleines Rudel "Unregistrierter" sorgt bei nahezu jedem Posting dafür, dass das auch ja nicht vergessen wird.
versteh ich nicht, in diesem thread hat doch kein unreg was zum thema beigetragen.
vielleicht solltest du mal von deinem ego trip runterkommen und einsehen dass dein schlechter ruf vielleicht davon verursacht wird, dass du hier so viel müll redest, das versuchst mit fadenscheinigen argumenten aufrechtzuerhalten und wenn das nicht klappt anfängst andere zu beleidigen?nur zur info: in diesem forum lesen auch viele professionelle entwickler mit, würde mich nicht wundern wenn du dir mit den letzten beiden threads jede menge jobchancen verbaut hast, auch wenn du es vermutlich niemals bestätigt bekommen wirst
-
unregistrierter schrieb:
Xin schrieb:
Meinen Ruf habe ich in diesem Forum ja bereits weg, ein kleines Rudel "Unregistrierter" sorgt bei nahezu jedem Posting dafür, dass das auch ja nicht vergessen wird.
versteh ich nicht, in diesem thread hat doch kein unreg was zum thema beigetragen.
Gratuliere, Du hast die Kritik verstanden und gleichzeitig bestätigt.
-
Xin schrieb:
Meinen Ruf habe ich in diesem Forum ja bereits weg, ein kleines Rudel "Unregistrierter" sorgt bei nahezu jedem Posting dafür, dass das auch ja nicht vergessen wird.
Leute werden nicht aufgrund ihres namens verarscht, sondern aufgrund ihres verhaltens.
-
Xin schrieb:
unregistrierter schrieb:
Xin schrieb:
Meinen Ruf habe ich in diesem Forum ja bereits weg, ein kleines Rudel "Unregistrierter" sorgt bei nahezu jedem Posting dafür, dass das auch ja nicht vergessen wird.
versteh ich nicht, in diesem thread hat doch kein unreg was zum thema beigetragen.
Gratuliere, Du hast die Kritik verstanden und gleichzeitig bestätigt.
du verstehst auch jeden post so, damit du ihn dir so zurechtrücken kannst wie du willst oder?
-
Xin schrieb:
CStoll schrieb:
Xin schrieb:
CStoll schrieb:
Schön, wenn du eine Sprache hast, die zwischen Zuständen und Teilobjekten unterscheiden kann. C++ kann das leider nicht, also brauchst du gar nicht versuchen, es dazu zu bringen.
Super Einstellung. "Ich" kann das nicht, also brauchst "Du" es nicht zu versuchen.
Ich versuche es trotzdem. Sich derart dagegen zu wehren bringt aber nix, ich zwinge schließlich niemanden hier, es zu nutzen.Doch, du versuchst krampfhaft, mir zu erklären, daß dein Ansatz besser ist.
Vielleicht macht Dir diese Antwort verständlich, wie krampfhaft ich versuche Dich von etwas zu überzeugen. Denk selbst drüber nach, oder lass es - es zwingt Dich niemand.
Schön, daß du jetzt anfängst, meine Beiträge inhaltlich zu ignorieren.
OK, fassen wir nochmal die bisherigen Beispiele zusammen, die laufen alle auf einen ähnlichen Denkfehler hinaus: Du kannst mit Ableitung die Fähigkeiten einer Klasse erweitern, aber nicht einschränken.
-
WindowFlags vs. Window:
Die Klasse WindowFlags hat einen operator bool() (und auch wenn du das "s" noch so sehr betonst, ein einzelnes Flag ist auch von diesem Typ), die Klasse Window als bool zu betrachten ist sinnlos (und wenn nicht, dann mit einer völlig anderen Semantik als für WindowFlags). Da ist es egal, ob du eine technische (op bool ist privat und der Compiler beschwert sich, wenn man es nutzen will) oder konzeptionelle (irgendwo in der Doku steht "benutze nie 'if(win)...'") Einschränkung hast - du hast eine Einschränkung.
(und im Ernstfall sind mir technische Einschränkungen lieber) -
Ableitungen von int:
Du hast alle Maßangaben (Längen, Gewichte etc) von int abgeleitet, um Schreibarbeit zu sparen. Aber damit hast du gleichzeitig massenweise Mehraufwand, um sie vernünftig nutzen zu können: -
Alle Operatoren liefern int-Werte, also brauchst du entweder Typumwandlungen von int in deine Typen (aber dann geht die Typsicherheit verloren, wenn du beliebig Gewichte und Längen miteinander verwursten kannst) oder eigene überladene Operatoren (aber dann brauchst du die Verwandtschaft mit int nicht mehr)
-
btw, op+ und op- zu überladen mag ja noch recht einfach sein, aber bei op* und op/ wird's dann haarig (die schlucken zwei beliebige Maßangaben und geben eine völlig andere Angabe wieder heraus) - davon, was bei op& und Co. rauskommen sollte, will ich gar nicht anfangen.
(erzähl mir jetzt bitte nichts von Templates - ich kenne eine Template-Lösung dafür, aber die braucht keine Vererbung von int) -
Wertekombination durch Vererbung:
In den wenigstens Fällen sind die Attribute eines Objekts unabhängig voneinander (die Maximalgeschwindigkeit eines Autos hängt von der Motorleistung ab, die linke obere Ecke eines Fensters von der rechten oberen Ecke etc). Die einzelnen Basisklassen sind aber konzeptionell unabhängig voneinander - also mußt du in der abgeleiteten Klasse dafür sorgen, daß sie sich konsistent zueinander ändern.
PS: Die Allergie hatte ich übrigens erwähnt, weil du mit den Allergiewarnungen angefangen hast - es gibt halt auch Menschen, die unter mehr leiden als einem (eher harmlosen) Heuschnupfen (btw, ich kenne auch jemanden mit einer Nussallergie). Und die sind dankbar, wenn sie rechtzeitig über (potentiell) gefährliche Nahrungsmittel informiert werden.
PPS: Mich hast du übrigens auch zum Nachdenken gebracht - mit dem Ergebnis, daß ich deine Lösung nach längerem Nachdenken als unsinnig eingestuft habe.
-
