Path: csiph.com!feeder.erje.net!2.eu.feeder.erje.net!newsreader4.netcologne.de!news.netcologne.de!.POSTED.xdsl-84-44-179-215.netcologne.de!not-for-mail From: Patrick Roemer Newsgroups: de.comp.lang.java Subject: Re: JUnit Test von JButton: Action wird nicht erkannt Date: Fri, 15 Jul 2016 23:44:25 +0200 Organization: news.netcologne.de Distribution: world Message-ID: References: Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Injection-Date: Fri, 15 Jul 2016 21:44:27 +0000 (UTC) Injection-Info: newsreader4.netcologne.de; posting-host="xdsl-84-44-179-215.netcologne.de:84.44.179.215"; logging-data="1492"; mail-complaints-to="abuse@netcologne.de" User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.1.24) Gecko/20100411 Thunderbird/2.0.0.24 Mnenhy/0.7.6.0 In-Reply-To: Xref: csiph.com de.comp.lang.java:12999 Responding to Christian H. Kuhn: > Am 15.07.2016 um 22:04 schrieb Patrick Roemer: >> Alternativ/zusätzlich könnte man das Design so ändern, dass der >> ChessTimer nur eine Methode #checkFlag() hat, die von einem *externen* >> Timer aufgerufen wird. Dann braucht man "weiter oben" natürlich wieder >> eine Entität, die externen Timer und ChessTimer zusammenführt und muss >> die separat testen - aber man hat die Verantwortlichkeiten getrennt und >> die "Problemfläche" für Threading reduziert. > > 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. >> Es ist völlig egal, welche Frequenz die Aufrufe in den einzelnen Threads >> haben. Solange es keine "happens-before"-Beziehung zwischen Aktion A in >> Thread 1 und Aktion B in Thread 2 gibt, hast Du keinerlei Garantie, dass >> Thread 2 die Resultate von Aktion A je sehen wird, egal, wieviel >> Realzeit zwischen den Aktionen liegt. > > Ja. Das ist die Theorie. Schreib-Lese-Konflikte. In dem Fall allerdings > nicht praktisch relevant. Das Blockadepotential der Anwendung ist eine > Größenordnung kleiner als die Wahrnehmung der Spieler. Und wenn externe > Blockaden auftreten, bleibt sowieso irgendwas unzumutbar stehen. Ich dachte mir schon, dass Schachspieler eher so die geduldigen und sanguinischen Typen sind, aber dass sie es entspannt hinnehmen, wenn im Turnierfinale irgendwas (außer ihrer Deckung, natürlich) unzumutbar stehenbleibt, erstaunt mich dann doch. :D Abgesehen davon: Das ist nicht nur Theorie, das passiert. In echt. Und das konkret angesprochene Problem hat (erst mal) nix mit Blockaden und Konflikten zu tun. Es kann schlicht vorkommen, dass der Timer flagFallen auf true setzt, und der Main-Thread da nie etwas von mitbekommt. Und somit die Uhr unzumutbar *nicht* stehenbleibt... Viele Grüße, Patrick