Design-Problem: Composite ohne friend

Dravere

@Nexus,
Nur ist nicht bereits eine solche Verwendung eine falsche Verwendung? Wenn jemand die Anwendungslogik mit einem Button so verbindet, dass er die Übersicht verliert, erscheint es mir nicht gerade eine sinnvolle Lösung
Wie oft wird zudem mehrere Anwendungslogik über mehrere Funktoren mit einem Button-Click verbunden? Erscheint mir alles ein wenig sehr theoretisch hinkonstruiert, wodurch deine Schnittstelle fett wird und leicht zu falscher Verwendung führen kann.

Ich frage mich halt, wieso baust du so ein Feature ein? Dass ein Programmierer theoretisch dies verwenden kann und du ein zusätzliches Feature auf die Liste packen kannst? Oder siehst du wirklich eine praktische sinnvolle Anwendung, also ein Beispiel aus der Praxis oder sowas? Ein Feature einbauen, nur weil man kann, halte ich nicht für sehr klug.

Grüssli

drakon

Ich kann mir durchaus Verwendungsgebiete von einer solchen Funktion vorstellen.

http://tinyurl.com/yfgow2f

Da ist dann das einfügen in ein Textfeld auch gut, wenn man das nicht so lösen muss, dass man Tastatureingaben simuliert.

Dravere

Jetzt müsstest du nur noch einen gültigen Link hinschreiben, damit ich mir das auch anschauen kann

Grüssli

Nexus

Dravere schrieb:

Nur ist nicht bereits eine solche Verwendung eine falsche Verwendung? Wenn jemand die Anwendungslogik mit einem Button so verbindet, dass er die Übersicht verliert, erscheint es mir nicht gerade eine sinnvolle Lösung

Was hat das mit Übersicht verlieren zu tun? Das ist ja der Sinn eines Callback-Systems. Man registriert die Funktionen einmal und fertig. Die Reaktionen auf Events können logisch und lokal getrennt von der Registrierung erfolgen, was Programmbestandteile entkoppelt.

Dravere schrieb:

Wie oft wird zudem mehrere Anwendungslogik über mehrere Funktoren mit einem Button-Click verbunden? Erscheint mir alles ein wenig sehr theoretisch hinkonstruiert, wodurch deine Schnittstelle fett wird und leicht zu falscher Verwendung führen kann.

Warum soll es nicht möglich sein, mehrere Aktionen mit einem Klick zu verbinden? Kann zum Beispiel sehr gut sein, dass man durch den Klick gerade andere GUI-Komponenten aktiviert oder deaktiviert (kennst du sicher, dass gewisse Häkchen in CheckBoxes grau und nicht anklickbar werden, wenn andere aktiv sind). Wenn man nur eine Reaktion zulässt, muss der Benutzer wieder auf seiner Seite Funktionen schreiben, die alles tun. Sind solche Massenfunktionen etwa besser, als wenn die Funktionalität direkt aufgeteilt wird und die einzelnen Komponenten logisch getrennt reagieren können?

Ich verstehe nicht, wieso der Benutzer einen Button drücken darf und der Programmierer nicht.

Dravere schrieb:

Ein Feature einbauen, nur weil man kann, halte ich nicht für sehr klug.

Stell dir vor, das ist mir sogar bewusst!

Aber du darfst grundsätzlich davon ausgehen, dass ich mir beim Design schon etwas überlege. Vielleicht übersehe ich ab und zu etwas oder gestalte etwas anders als z.B. du es tun würdest, aber leichtsinnig Features hinzufügen, nur um möglichst viele davon zu haben, ist eigentlich nicht mein Beweggrund.

drakon schrieb:

http://@notallowed@.com/yfgow2f

Dein Link scheint irgendwie zensiert... Ist das nur bei mir so?

Dravere

Hmmm, habe gerade meine ganze Antwort gelöscht. Ich glaube, dass dies am Ende auf zu viele subjektive Vorstellungen hinausläuft. Vieles würde ich auch gänzlich anders machen. Ich finde es einfach ein wenig unsinnig, wenn ein Programmierer eine GUI Bibliothek gleich verwenden muss, wie die Anwender, welche das GUI bedienen werden. Sowas führt zu keinem guten Aufbau, aber das ist wohl eben eine sehr subjektive Meinung

Grüssli

Nexus

Okay. Dennoch danke für die vielen Anregungen in diesem Thread! Der Programmierer bedient die GUI ja nicht gleich wie der Anwender, das ist jetzt nur ein Spezialfall. Aber mit dem Subjektiven hast du wahrscheinlich Recht, dir würde mein Framework wohl nicht besonders gefallen.

Über das ursprüngliche Problem habe ich nochmals nachgedacht, und ich denke, ich werde es vorerst doch mit friend machen, um den Zugriff auf die zwei Klassen zu beschränken. Aber das kann sich auch wieder ändern. Auf jeden Fall werde ich mir die Indirektion über Forward-Funktionen für protected -Zugriff merken!

drakon

Ehm.. wtf? - Das war ein Link auf "Let me google that for you", wo ja ein Mausklick in dem Sinne gemacht wird, ohne dass es die Maus macht..
Wahrscheinlich hat das Markus mal zensiert..

Dravere

drakon schrieb:

Ehm.. wtf? - Das war ein Link auf "Let me google that for you", wo ja ein Mausklick in dem Sinne gemacht wird, ohne dass es die Maus macht..
Wahrscheinlich hat das Markus mal zensiert..

Dir ist schon klar, dass da nicht wirklich der Button gedrückt wird, sondern du über Javascript und window.location weitergeleitet wirst. Der Query wird dann über die URL Google mitgeteilt. Ich verwende die gleiche Vorgehensweise, um zum Beispiel über die Adresszeile von Opera direkt mit IxQuick/MSDN/Bing/Wikipedia suchen zu können.

Grüssli

drakon

Dravere schrieb:

drakon schrieb:

Ehm.. wtf? - Das war ein Link auf "Let me google that for you", wo ja ein Mausklick in dem Sinne gemacht wird, ohne dass es die Maus macht..
Wahrscheinlich hat das Markus mal zensiert..

Dir ist schon klar, dass da nicht wirklich der Button gedrückt wird, sondern du über Javascript und window.location weitergeleitet wirst. Der Query wird dann über die URL Google mitgeteilt. Ich verwende die gleiche Vorgehensweise, um zum Beispiel über die Adresszeile von Opera direkt mit IxQuick/MSDN/Bing/Wikipedia suchen zu können.

Grüssli

Jap. Ist mir schon klar. Aber ich habe dort eben in die Textzeile noch geschrieben, dass so ein Vorgehen bei einem In Game GUI praktisch wäre.

Das ich in einem PC Spiel keine Animation mit bewegter Maus und Textfeld im vornherein erstelle sondern eben da einfach den Cursor im Code rumschiebe und dann den Klick ebenfalls im Code mache, ist denke ich klar.

Dravere

drakon schrieb:

Das ich in einem PC Spiel keine Animation mit bewegter Maus und Textfeld im vornherein erstelle sondern eben da einfach den Cursor im Code rumschiebe und dann den Klick ebenfalls im Code mache, ist denke ich klar.

Ich hoffe, dass war nicht dein Ernst?

Grüssli

drakon

Dravere schrieb:

Ich hoffe, dass war nicht dein Ernst?

Grüssli

Ehm.. Doch? - Was ist denn nicht gut daran? - Bei z.B einem Game Tutorial oder so kann ein solches Verhalten durchaus nützlich sein und lässt sich dann ganz einfach umsetzen. (à la : "Wenn sie mit der Maus auf dieses Symbol klicken *klick*, dann erreichen sie das Menü so und so")

Dravere

drakon schrieb:

Ehm.. Doch? - Was ist denn nicht gut daran? - Bei z.B einem Game Tutorial oder so kann ein solches Verhalten durchaus nützlich sein und lässt sich dann ganz einfach umsetzen. (à la : "Wenn sie mit der Maus auf dieses Symbol klicken *klick*, dann erreichen sie das Menü so und so")

Das habe ich schon mehrmals gesehen und jedesmal wurde eine zweite Maus animiert oder dann mit Blinken oder ähnlichem auf eine Schaltfläche aufmerksam gemacht. Du darfst doch nicht einfach die Kontrolle über die Maus des Benutzers übernehmen. Da schlägt am Ende gar noch ein Anti-Viren Programm alarm.
Aber auch sonst ist das eine sehr schlechte Technik. Der Benutzer sollte selber über die Geschwindigkeit eines Tutorials entscheiden, also wann er weitergehen will. Wenn du einem Kunden ein Haus zeigst, dann bugsierst du ihn ja wohl auch nicht durch das Haus?
Zudem was machst du mit den Mausbewegungen des Benutzers? Wenn er sich gegen deine erzwungenen Bewegungen der Maus "wehrt"?

Ein solches Vorgehen wäre meiner Meinung nach völlig benutzerunfreudnlich.

Grüssli

Nexus

Dravere, deiner Ansicht nach wäre diese Funktion also äusserst böse?

Ich selbst würde auch nicht direkt die Benutzermaus bewegen. Aber eigentlich ging es ja ums Klicken.

Wenn man einen Benutzerklick simulieren möchte, gehts natürlich auch ohne Click() . Nur läuft das darauf hinaus, dass man die assoziierten Funktionen selbst aufrufen muss und zudem noch dafür zu sorgen hat, dass die Klick-Animation korrekt abgespielt wird. All das könnte die Schaltfläche wunderbar selbst, aber ohne Click() zwingt man den Benutzer zum Nachbauen. Vor allem die Animation wird interessant, da müsste man wohl die Einzelbilder separat speichern und rechtzeitig zeichnen. Richtig lustig wirds, Änderungen konsistent zu halten. Das meinte ich eben mit unnötiger Komplexität.

Wenn ein Feature auf der einen Seite sehr nützlich ist, aber bei unbedachter Benutzung zu schlechtem Design führen kann, würdest du es nur wegen letzterem verbieten? Ich sicher nicht, aber das ist wohl wirklich subjektiv. Um das konsequent durchzuziehen, dürfte man allerdings nicht mehr programmieren.

Dravere

Nexus schrieb:

Dravere, deiner Ansicht nach wäre diese Funktion also äusserst böse?

Nein. Damit kann man schon sinnvolles machen. Man könnte die Option anbieten (oder gleich die Einstellung vom System holen), dass der Cursor immer zur Standardschaltfläche springt. Das kannst du damit implementieren. Aber dann sollte man dem User die Wahl lassen. Ich schalte sowas zum Beispiel immer ab.

Nexus schrieb:

Ich selbst würde auch nicht direkt die Benutzermaus bewegen. Aber eigentlich ging es ja ums Klicken.

Naja, aber du wirst ja auch nicht den Benutzer zu einem Klick zwingen? Den Besucher des Hauses gegen eine Tür drängen, damit er diese aufmacht ... ok, die Metapher ist jetzt nicht mehr so gut oder der Besucher ist von der Billag/GEZ

Nexus schrieb:

..., dass die Klick-Animation korrekt abgespielt wird.

Wieso sollte die abgespielt werden, wenn der Benutzer nicht darauf klickt? Und wenn du wirklich sowas anbieten möchtest, dann würde ich das eher getrennt anbieten: PlayAnimation, PlayClickAnimation oder sowas. Wobei ich, wie gesagt, gar keinen Zweck dafür sehe. Falls das irgendjemand mal wünscht und tatsächlich einen sinnvollen Verwendungszweck zeigen kann, kann man es immer noch anbieten. Wie das grundsätzlich Laurent bei SFML macht, finde ich ein sehr gutes Vorgehen.

Nexus schrieb:

Wenn ein Feature auf der einen Seite sehr nützlich ist, aber bei unbedachter Benutzung zu schlechtem Design führen kann, würdest du es nur wegen letzterem verbieten?

Nein, ich sehe nur den Nutzen von diesem Feature nicht. Für mich gibt es hier dieses "sehr nützlich" nicht.

Übrigens @drakon,
Mir kam nochwas gestern Abend in den Sinn. Wenn du die Bewegungen für den Benutzer übernimmst, hat das noch einen negativen Effekt. Der Benutzer lernt nicht, wie man es macht, denn man lernt etwas nur, wenn man es selber macht

Grüssli

drakon

Jaja. Es war ein Beispiel, wo man es brauchen kann. Es kommt da wahrscheinlich nicht all zu oft vor, aber man kann es benutzen und es ist imo einiges einfacher, als wie nexus sagt alles andere von Hand zu machen.

Aber wie wäre es z.B bei einer Aufzeichnung eines Spieles? Also wenn ich die Aufzeichnung ablaufen lasse, dann kann ich ganz gut einfach die Eingaben des Spielers tracken und dann nachproduzieren. Oder aber auch eine eigene machen für die Ansicht des Gegners. Klar kann man das anderst lösen, aber ich sehe den Sinn nicht alles nachzuprogrammieren, wenn man genau die Funktionen ja bereits hat.

Dravere

@drakon,
Du bestätigst meine Meinung mehr und mehr. Du würdest diese Funktionen genau für solchen Unsinn missbrauchen. Das Beispiel ist schlecht, sowas macht man einfach nicht. Also braucht man auch diese Möglichkeit nicht.
Wenn du sowas sagst wie "Theoretisch könnte man es brauchen, ist vielleicht nicht so gut, aber immerhin hat man die Möglichkeit", dann machst du eben nichts anderes, als möglichst viele Features reinpacken, ohne zu überlegen, wie sinnvoll die eigentlich sind.

drakon schrieb:

Aber wie wäre es z.B bei einer Aufzeichnung eines Spieles? Also wenn ich die Aufzeichnung ablaufen lasse, dann kann ich ganz gut einfach die Eingaben des Spielers tracken und dann nachproduzieren. Oder aber auch eine eigene machen für die Ansicht des Gegners. Klar kann man das anderst lösen, aber ich sehe den Sinn nicht alles nachzuprogrammieren, wenn man genau die Funktionen ja bereits hat.

1. Worauf war das nun bezogen? Du willst doch hoffentlich im Replay nicht die Maus des Benutzers benutzen?
2. Oft löst man das tatsächlich anders und zwar deutlich einfacher: Video Aufzeichnung.
Ich habe jedenfalls noch nie davon gehört, dass da jemand angefangen hat im Replay irgendwelche Klicks zu reproduzieren.

Und es geht ja auch nicht darum, dass du dies nachprogrammieren sollst. Es geht darum, dass du es gar nicht brauchst. Oder es sind irgendwelche hoch speziellen Sonderfälle. Dann biete für diese Sonderfälle lieber eine explizite Schnittstelle an, welche für den Sonderfall gemacht ist. Aber nicht etwas allgemeines, was schnell zu unsauberen Code führt.

Grüssli

drakon

Dravere schrieb:

1. Worauf war das nun bezogen? Du willst doch hoffentlich im Replay nicht die Maus des Benutzers benutzen?
2. Oft löst man das tatsächlich anders und zwar deutlich einfacher: Video Aufzeichnung.
Ich habe jedenfalls noch nie davon gehört, dass da jemand angefangen hat im Replay irgendwelche Klicks zu reproduzieren.

1. Nein. Einfach ein Cursor. Also die echte Maus muss ja nicht an dem Cursor attached sein..

2. Nein. In Age of Empires 2 und vielen anderen Strategiespielen, die ich kenne läuft das so, dass man sogar auswählen kann, ob man eben den Spiele beobachtet und da sind die Bewegungen der Maus nicht unwichtig, oder ob man selbst rumscrollen kann. Da kann man dann auch die ganze Welt anschauen und in den Gebäuden nachsehen, was für Einheiten produziert werden usw. Das als Video zu machen ist nicht möglich.

Dravere

drakon schrieb:

2. Nein. In Age of Empires 2 und vielen anderen Strategiespielen, die ich kenne läuft das so, dass man sogar auswählen kann, ob man eben den Spiele beobachtet und da sind die Bewegungen der Maus nicht unwichtig, oder ob man selbst rumscrollen kann. Da kann man dann auch die ganze Welt anschauen und in den Gebäuden nachsehen, was für Einheiten produziert werden usw. Das als Video zu machen ist nicht möglich.

Age Of Empires, schon lange nicht mehr gespielt. Aber war es da nicht so, dass man da beobachtet hat und nicht gesehen hat, wie der Benutzer auf die Gebäude geklickt hat? Somit wäre die Simulation eines Button-Clicks immer noch nicht nötig
Und abgesehen davon, würde ich sowas ganz anders lösen. Da würde ich eine Event-Aufzeichnung machen und beim Abspielen diese Events wieder auslösen. Da dadurch die Mausbewegung und der Klick als Event gespeichert werden, wird das im Hintergrund automatisch wieder ausgeführt.

Somit würde ich das als ein Spezialfall anschauen und eben einen EventRecorder anbieten oder sowas. Bzw. man könnte dem User auch die Möglichkeit geben, den Events irgendwo zentral zu lauschen, bzw. auch die Quelle angeben. Also gäbe es die Möglichkeiten das System als Quelle abzukopplen und dafür dann die Aufzeichnung als Quelle angeben. Das meinte ich dann mit der expliziten Schnittstelle.

Grüssli

Nexus

Dravere schrieb:

Wieso sollte die abgespielt werden, wenn der Benutzer nicht darauf klickt?

Weil der Klick realistisch aussehen soll, so à la: "Schau mal, was passiert, wenn du hier klickst". Sodass der Benutzer ohne Weiteres weiss, dass ein Klick durchgeführt wurde.

Dravere schrieb:

Und wenn du wirklich sowas anbieten möchtest, dann würde ich das eher getrennt anbieten: PlayAnimation, PlayClickAnimation oder sowas.

Ja, eben. Eine kleinere Schnittstelle hast du dadurch nicht, eher musst du noch Spezialfunktionen, die man sonst nicht braucht, anbieten. Soviel zum Thema "Features genau abwägen".

Dravere schrieb:

Nein, ich sehe nur den Nutzen von diesem Feature nicht. Für mich gibt es hier dieses "sehr nützlich" nicht.

Ich habe es nun aber genügend oft erklärt. Auf das Hauptargument, dass du dir ohne Click() Workarounds basteln musst, bist du gar nie wirklich eingegangen. Wenn das nützlicher ist, okay.

Dravere schrieb:

Du würdest diese Funktionen genau für solchen Unsinn missbrauchen. Das Beispiel ist schlecht, sowas macht man einfach nicht. Also braucht man auch diese Möglichkeit nicht.

Weil ein mögliches Beispiel schlecht ist, braucht man die Funktionalität nicht? Sogar mit Begründung könntest du diesen Schluss nicht ziehen.

Schau dir halt einfach andere Frameworks an.

Die Aufrechterhaltung von Ordnung ist keine Zensur.