Path: csiph.com!news.redatomik.org!newsfeed.xs4all.nl!newsfeed8.news.xs4all.nl!feeder1.xsusenet.com!newsreader4.netcologne.de!news.netcologne.de!fu-berlin.de!uni-berlin.de!individual.net!not-for-mail From: "Christian H. Kuhn" Newsgroups: de.comp.lang.java Subject: Re: Countdown Timer Design Date: Sun, 17 Jul 2016 15:49:19 +0200 Lines: 49 Message-ID: References: Mime-Version: 1.0 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit X-Trace: individual.net fpCQO67ogWPvao4Uq+x4Nwaap+anNMTjxbDRcbKrdlUMkQjd0= Cancel-Lock: sha1:DfLPqEdtjfiAzLGlorHxnLhvZeQ= User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 In-Reply-To: Xref: csiph.com de.comp.lang.java:13008 Am 17.07.2016 um 12:35 schrieb Stefan Ram: > ram@zedat.fu-berlin.de (Stefan Ram) writes: > Die Modellklassen wurden nun um eine Klasse »Clock« > erweitert, die zwei Uhrwerke »Unit« enthält. > Damit kann sie eine vereinfachte Art von Schachuhr > imitieren. Warum sieht das bei dir soviel aufgeräumter auf als bei mir? :-) Ok, du hast die Zeitquelle jetzt auch noch aus Clock herausgezogen und in die Verantwortung des Benutzers, also des UI, gegeben. Kann man so machen. Es gibt ein Argument, das dagegen spricht. Ich bin der Auffassung, dass die Feststellung einer Zeitüberschreitung entweder in Unit oder in Clock gehört. Unit kann ein allgemeiner Timer sein, der über Zeitüberschreitung nichts zu wissen braucht, dann gehört der Überschreitungsalarm nach Clock. Deine Unit zählt die Zeit hoch, ich brauche eigentlich einen Countdown, das ist dann eine Zeile mehr, und dann kann man auch argumentieren, dass das Erreichen der 0 von Unit festgestellt werden muss. Geht beides, ich neige im Moment mehr dazu, das in Clock zu tun. Wenn ich aber die Zeitüberschreitung in Clock feststelle, kann ich das eigentlich nur machen, indem ich regelmäßig duration von beiden Unit abfrage. Nicht nur von der laufenden, weil ja die andere Uhr zwischen letzter Abfrage und letztem toggle die Zeit überschritten haben kann. Damit muss Clock eine eigene Vorstellung von now haben. Die Alternative wäre, dass das UI getaktet Clock.isFlagFallen(now()) aufrufen müsste. Hm. Bauch sagt nein ... Das wird eine grundsätzliche Design-Frage. Ich folge bislang dem Observer-Muster: Clock als Observable verwaltet die eigenen Zustände und benachrichtigt seine Observer über Änderungen. Das (G)UI ist dumm. Es trifft keine Feststellungen über Zustände und Übergänge, es stellt einfach dar, was es mitgeteilt bekommt. Indem du Clock derart vereinfacht hast, wird mehr Logik in das (G)UI verfrachtet. Die Frage, wie oft auf welche Zustandsänderungen überprüft wird, ist sehr abhängig von der Implementation von Clock. Im Moment mag das kein Problem sein. Sobald der volle Funktionsumfang einer Turnierschachuhr (mehrere verschiedene Bedenkzeitperioden, Zugzähler, Bronstein-Bedenkzeit, Editierfunktionen für den Schiedsrichter) implementiert wird, befürchte ich eine Verletzung der Kapselung. lg QNo