Countdown Timer Design (was: JUnit Test von JButton: Action wird nicht erkannt)

From	"Christian H. Kuhn" <qno-news@qno.de>
Newsgroups	de.comp.lang.java
Subject	Countdown Timer Design (was: JUnit Test von JButton: Action wird nicht erkannt)
Date	2016-07-16 23:44 +0200
Message-ID	<duvo7iF6tgdU1@mid.individual.net> (permalink)
References	(1 earlier) <nm8j8b$r9c$1@newsreader4.netcologne.de> <duqgrdFtso5U1@mid.individual.net> <nmbfkk$sk4$1@newsreader4.netcologne.de> <dut1paFhuo8U1@mid.individual.net> <nmblfr$1ek$1@newsreader4.netcologne.de>

Show all headers | View raw

Am 15.07.2016 um 23:44 schrieb Patrick Roemer:
> Responding to Christian H. Kuhn:
>> Der Gedanke kam mir auch schon. Die Kernfunktionalität von QChessTimer
>> ist einfach das unterbrechbare Runterzählen  und Ausliefern der Zeit. Ob
>> die Null erreicht ist, kann auch QChessClock prüfen. Man kann auch
>> argumentieren, dass das semantisch besser ist.
> 
> Das wäre noch eine andere Variante.
> 
> Ich meinte eher, dass QChessTimer zunächst mal eine State Machine ist,
> die anhand von eingehenden Events zwischen Idle, Stopped, Started und
> Flagged o.s.ä. wechselt. Momentan verwaltet die Klasse zusätzlich noch
> eine der Eventquellen (den Timer). Die könnte man da komplett
> rausziehen. Dann hätte man eine (quasi "rein funktionale") Klasse mit
> der Logik für die Zustandsübergänge. Und die könnte man in einer
> "übergeordneten" Klasse (die dem jetzigen QChessTimer entspricht) mit
> einer Timerabstraktion zusammenschalten.

Ok. Konkret: Zwei Zustände, started und stopped. idle === stopped.
flagged ist für QChessTimer kein eigener Zustand mehr, sondern wird
höheren Ortes angesiedelt. Da wird einfach überprüft, ob die
verbleibende Zeit noch > 0 ist, ansonsten Blättchen. Damit entfällt der
TimerTask.

Zustandsübergang durch start() und stop(). Eigentlich unparametrisiert,
weil ja auf die Systemzeit zurückgegriffen wurde. Dann auch mit
Parameter, damit der zu stoppende QChessTimer „zur gleichen Zeit“
angehalten werden kann wie der zu startende gestartet wird. Wenn einfach
start() und stop() hintereinander ausgeführt werden, kann da schon mal
ne ms oder vier dazwischen liegen. Verlängert die Partie nur um
Sekundenbruchteile, aber es soll ja sauber sein. Also wird die
unparametrisierte Variante gestrichen. Auf eine Zeitquelle muss nur noch
zur Zeitabfrage bei laufender Uhr zurückgegriffen werden.

Den Vorteil einer Abstraktion der Zeitquelle habe ich noch nicht
erkannt. Im praktischen Einsatz wird dies die Systemuhr sein, eine
Alternative kann ich mir gerade nicht vorstellen. Und dann würde ich
überflüssige Funktionalität entwickeln, nur damit ich die testen kann ...

Die Zeitquelle im QChessTimer könnte übrigens komplett entfallen, wenn
das Auslesen des Zustands nicht die Zeit, sondern ein Objekt übergibt,
das verbleibende Zeit und Zustandsname enthält. Bei laufender Uhr wird
remainingTime + startTime zurückgegeben; wenn der Zustand running ist,
muss der Aufrufer sehen, woher er die aktuelle Zeit nimmt, zieht die ab
und hat die verbleibende Zeit; bei stopped bekommt er schon den
korrekten Wert. QChessTimer würde also endgültig nichts mehr mit
laufender Zeit zu tun haben, sondern nur noch von außen mitgeteilte
Marken verwalten.

Ob man tatsächlich intern die Zeit in ns führt, aber nach außen s
ausgibt ... da ist ein Faktor von einer Million dazwischen. Es könnte
reichen, intern in ms zu rechnen. Problem: Beim Test, ob die Uhr läuft,
könnten zwei Abfragen hintereinander so schnell aufeinanderfolgen, dass
die ms sich nicht verändert haben und ein Test falsch fehlschlägt.

Damit sind die Problempunkte aus QChessTimer herausgelöst. Zugriff
erfolgt von QChessClock, aber bis zum Beweis des Gegenteils aus mehreren
Threads: Einem main-Thread, der die Timer erzeugt (reset erfolgt über
neuen Konstruktor), Knopfdruckaktionen können in einem eigenen Thread,
z.B. Swing-EDT, ausgelöst werden, und ein möglicher eigener Thread zur
Aktualisierung der Restzeit und der Fallblättchenüberprüfung.
QChessTimer muss also thread safe geschrieben werden. Zugriffe auf int,
long und boolean sind atomar. Die vier verbleibenden paketöffentlichen
Funktionen müssten synchronized werden.

Aber jetzt erstmal schlafen. Threadsicher und ohne interrupts ;-)

lg
QNo

Back to de.comp.lang.java | Previous | Next — Previous in thread | Next in thread | Find similar

Thread

JUnit Test von JButton: Action wird nicht erkannt "Christian H. Kuhn" <qno-news@qno.de> - 2016-07-14 01:09 +0200
  Re: JUnit Test von JButton: Action wird nicht erkannt "Christian H. Kuhn" <qno-news@qno.de> - 2016-07-14 18:26 +0200
  Re: JUnit Test von JButton: Action wird nicht erkannt Patrick Roemer <sangamon@netcologne.de> - 2016-07-14 19:47 +0200
    Re: JUnit Test von JButton: Action wird nicht erkannt "Christian H. Kuhn" <qno-news@qno.de> - 2016-07-15 00:08 +0200
      Re: JUnit Test von JButton: Action wird nicht erkannt Patrick Roemer <sangamon@netcologne.de> - 2016-07-15 22:04 +0200
        Re: JUnit Test von JButton: Action wird nicht erkannt "Christian H. Kuhn" <qno-news@qno.de> - 2016-07-15 22:53 +0200
        Re: JUnit Test von JButton: Action wird nicht erkannt "Christian H. Kuhn" <qno-news@qno.de> - 2016-07-15 23:09 +0200
          Re: JUnit Test von JButton: Action wird nicht erkannt Patrick Roemer <sangamon@netcologne.de> - 2016-07-15 23:44 +0200
            Countdown Timer Design (was: JUnit Test von JButton: Action wird nicht erkannt) "Christian H. Kuhn" <qno-news@qno.de> - 2016-07-16 23:44 +0200
              Re: Countdown Timer Design "Christian H. Kuhn" <qno-news@qno.de> - 2016-07-17 12:44 +0200
              Re: Countdown Timer Design "Christian H. Kuhn" <qno-news@qno.de> - 2016-07-17 15:49 +0200
                Re: Countdown Timer Design "Christian H. Kuhn" <qno-news@qno.de> - 2016-07-17 17:03 +0200
                Re: Countdown Timer Design "Christian H. Kuhn" <qno-news@qno.de> - 2016-07-19 15:59 +0200
        Re: JUnit Test von JButton: Action wird nicht erkannt "Christian H. Kuhn" <qno-news@qno.de> - 2016-07-19 14:59 +0200
          Re: JUnit Test von JButton: Action wird nicht erkannt "Christian H. Kuhn" <qno-news@qno.de> - 2016-07-19 16:06 +0200
          Re: JUnit Test von JButton: Action wird nicht erkannt Patrick Roemer <sangamon@netcologne.de> - 2016-07-19 18:59 +0200
            Re: JUnit Test von JButton: Action wird nicht erkannt "Christian H. Kuhn" <qno-news@qno.de> - 2016-07-19 22:35 +0200
              Re: JUnit Test von JButton: Action wird nicht erkannt Patrick Roemer <sangamon@netcologne.de> - 2016-07-20 13:00 +0200
                Re: JUnit Test von JButton: Action wird nicht erkannt "Christian H. Kuhn" <qno-news@qno.de> - 2016-07-23 20:36 +0200
                Re: JUnit Test von JButton: Action wird nicht erkannt "Christian H. Kuhn" <qno-news@qno.de> - 2016-07-23 23:15 +0200
          Re: JUnit Test von JButton: Action wird nicht erkannt Wanja Gayk <brixomatic@yahoo.com> - 2016-07-19 23:02 +0200
            Re: JUnit Test von JButton: Action wird nicht erkannt "Christian H. Kuhn" <qno-news@qno.de> - 2016-07-20 12:33 +0200
    GUI-Update über Swing-EDT (was: JUnit Test von JButton: Action wird nicht erkannt) "Christian H. Kuhn" <qno-news@qno.de> - 2016-07-15 12:03 +0200
      Re: GUI-Update über Swing-EDT Patrick Roemer <sangamon@netcologne.de> - 2016-07-15 22:43 +0200
        Re: GUI-Update über Swing-EDT "Christian H. Kuhn" <qno-news@qno.de> - 2016-07-15 23:18 +0200
        Re: GUI-Update über Swing-EDT "Christian H. Kuhn" <qno-news@qno.de> - 2016-07-16 15:24 +0200
          Re: GUI-Update über Swing-EDT Patrick Roemer <sangamon@netcologne.de> - 2016-07-16 16:42 +0200
            Re: GUI-Update über Swing-EDT "Christian H. Kuhn" <qno-news@qno.de> - 2016-07-16 23:05 +0200
              Re: GUI-Update über Swing-EDT "Christian H. Kuhn" <qno-news@qno.de> - 2016-07-17 16:02 +0200

csiph-web