Na začátek pár slov o reprezentaci dat a uložení hrací plochy. Ke každému políčku (Field) si algoritmus udržuje tři základní údaje: hodnotu políčka (0-9; 0 znamená nevyplněné políčko) a množinu hodnot, které políčku ještě jde přiřadit (jeden bit pro každou hodnotu). Stav hrací plochy je pak uložen jako dvourozměrné pole políček.

Základní myšlenka řešícího algoritmu spočívá v propagaci možných hodnot a backtrackingu, podobně jako v programování s omezujícími podmínkami. Po přiřazení hodnoty jednomu políčku je tato hodnota zakázána všem ostatním políčkům ve stejné skupině (řádku, sloupci, čtverci). Když v některém políčku zbyde jediná hodnota, pak ji tomuto políčku přiřadí (a provede další propagaci). Pokud jsou v některém poli zakázány všechny možné hodnoty, prohledávání v této větvi končí neúspěchem.
Pokud po skončení propagace hodot jsou některá políčka stále nepřiřazená, algoritmus zkusí do takového pole dosadit jednu z povolených hodnot (to, že políčko zůstalo po propagaci volné znamená, že na základě dostupných informací je do něj možné dosadit více než jednu hodnotu) a provádí backtracking.

Naivní řešení

Naivní řešení používá pro uložení zásobníku java.util.Stack<T>. Při každém sestupu při backtrackování se alokuje nová reprezentace hrací plochy a zařadí na zásobník. O staré stavy ze zásobníku, pro které prohledávání selhalo se stará garbage collector. Jednoduché, ale funkční.

private Stack gameStateStack;

private void pushGameState() {
  Field[][] new_state = cloneGameState(currentGameState);
  gameStateStack.push(currentGameState);
  currentGameState = new_state;
}


Zlepšení s předalokováním

Teď se nad problémem zamyslíme trochu víc. Je snadné si uvědomit, že při řešení Sudoku 9×9 nikdy nebude hloubka zanoření backtrackingu vyšší než 81 – podle počtu polí na hrací ploše. Ve skutečnosti bude ještě nižší, protože některá pole jsou obsazená již v zadání. 81 je poměrně málo. Dost málo na to, aby šlo všech 81 stavů hrací plochy na zásobníku předalokovat a při backtrackingu do nich jen zkopírovat aktuální stav hry.

// alokováno při inicializaci
private Field[][][] gameStateStack = null;
private int stackPosition = 0;

private void pushGameState() {
  stackPosition++;
  cloneGameState();
  currentGameState = gameStateStack[stackPosition];
}

Výsledky

Efektivitu obou verzí kódu jsem testoval na následujícím zadání (těžké sudoku se sedmnácti podporami):

- - -|- - -|- 1 3
- - -|- 3 -|- 8 -
- 7 -|- - -|- - -
-----+-----+-----
- - -|2 - 6|- - -
- 3 -|- - -|9 - -
- - -|- 1 -|- - -
-----+-----+-----
6 - -|5 - -|2 - 4
- - -|4 - -|7 - -
1 - -|- - -|- - -

Naměřené časy shrnuje tabulka níže. Jde o průměrné časy ze 100 pokusů, aby měl JVM dost času se zahřát. Při řešení jednoho zadání solver provedl vždy 174844 rekurzivních sestupů a tedy i “alokací” nového pole.

Časy jsem měřil na počítači s procesorem Intel Core2Duo 1800MHz, spoustou paměti, Gentoo Linuxem a Javou 1.6 (nicméně výsledky na Javě 1.5 jsou obdobné). Rozdíl je sice viditelný (cca 7%), přesto je o dost menší, než jsem čekal. Je vidět, že se v Sunu opravdu snaží o co nejefektivnější JVM a na jejich tvrzení, že nemá smysl optimalizovat na počet alokací opravdu něco bude

Pro snadnou práci s tabulkami rozděluje Swing podle principů MVC práci s tabulkou na komponentu, která ji zobrazuje (JTable) a na její model (TableModel). Ten se stará o správu dat a jejich zpřístupnění komponentě JTable a také má na starosti změnu dat v případě, že uživatel provede editaci pomocí JTable. Toto předávání dat od uživatele se děje pomocí metody setValueAt.

Tento způsob práce s tabulkami v každém případě práci zjednodušuje, zdá se ale, že na některé možné problémy autoři pozapomněli, nebo se rozhodli je neřešit. Tím hlavním, který nás při práci na Guidovi v poslední době trápil byla kontrola dat zadávaných do tabulky. Pokud je správáná libovolná hodnota, kterou je možné v editoru zadat, je vše v pořádku a není nutné nic řešit. Jak ale zařídit, aby do tabulky šlo zadat (téměř) libovolný řetězec, který ale musí být různý od všech ostatních hodnot ve stejném sloupci?

Standardní – a podle mě i správné z hlediska návrhu aplikace – by bylo provádět takovéto kontroly v modelu tabulky. Tím by byla zajištěna funkčnost kontrol automaticky ve všech komponentách, které s modelem pracují bez dalších starostí programátora. Možností jak takové chování zajistit je několik:

• setValueAt bude vracet boolean podle toho, jestli hodnotu přijala, nebo ne. Pokud hodnotu odmítne, JTable snadno pozná, že zadaná hodnota nebyla správná a nechá uživatele ji opravit.
• setValueAt bude v případě nesprávné hodnoty vyhazovat výjimku speciálního typu, kterou JTable odchytí a zareaguje na ni. Toto řešení bych považoval za nejvhodnější, protože nejlépe odpovídá principům programování v jazyce Java.
• TableModel bude obsahovat metodu typu

  boolean isValid(Object value, int row, int column)

  která bude kontrolovat, zda hodnota, kterou uživatel zadává do tabulky je platná. V takovém případě ale stejně bude nutné provádět dodatečné kontroly i v setValueAt a tím je toto řešení nejméně vhodné.

Ve skutečnosti ale není použito ani jedno z nich, “návratová hodnota” setValueAt je typu void a podle definice interface TableModel nesmí vyhazovat výjimky (mimo RuntimeException a odvozených, které není nutné deklarovat v hlavičce metody) – a ani jejich výskyt JTable neošetřuje.

Kontroly v modelu

Pokud chce programátor z modelu tabulky zabránit ukončení editace a nastavení hodnoty, stačí uvnitř setValueAt vyhodit výjimku odvozenou od RuntimeException. Ta projde kódem JTable bez zachycení a defacto ukončí zpracování události, při které byla setValueAt volána. Díky tomu se hodnota do tabulky nenastaví a editor zůstane aktivní. Zatím jsme si nevšimli, že by tímto způsobem docházelo k nějakým defektům v modelu nebo v JTable – ale co není, může být.

Určitou vadou na kráse je stacktrace výjimky vypsaný na konzoli, o který se postará EventDispatchThread a který jednak může zbytečně děsit neinformvané uživatele a navíc působí dost neprofesionálně. Druhou nepříjemnou vlastností je to, že na editoru není žádným způsobem poznat, že došlo k chybě a hodnota nebyla tabulkou přijata. Všimněte si, že pokud používáte standardní editor pro editaci sloupčeku s číselnými hodnotami a zadáte nesmyslnou hodnotu, tak se kolem editoru objeví červený rámeček signalizující, že něco není dobře. A všimněte si také, že tímto způsobem žádný rámeček nevznikne.

Kontroly v editoru

Pátrání po původu červeného rámčeku mě dovedlo až do zdrojáku samotné JTable. Autoři od DefaultCellEditoru odvodili speciální editory postavené na textovém editačním poli, které umožńují editovat libovolnou hodnotu, pokud její třída obsahuje konstruktor vytvářející nové hodnoty z řetězců. Pokud novou hodnotu vytvořit nelze (při vytváření dojde k výjimce), nastaví si editor červený rámeček a pokračuje dál, jako kdyby se nic nestalo.

Ukazuje se, že jediný způsob, jak dosáhnout podobného efektu je vytvoření vlastního TableCellEditoru, který bude provádět kontroly před ukončením editace podobně, jako to dělá generický editor od autorů JTable při konverzi z řetězce. Tento generický editor bohužel je v privátní vnořená třída v JTable.java a tak ho není možné recyklovat a vylepšit o další kontroly. Naštěstí množství změn není tak velké, aby podle nich nešlo napsat vlastní editor fungující stejným způsobem.

Protože se jedná o obecný princip, je samotná kontrola z editoru vydělená do objektu implementujícího následující interfce. Metoda isTableCellValueValid vrací true, pokud je hodnota v zadaném sloupci a řádku přijatelná, jinak vrátí false.

public interface TableCellValidator {
    boolean isTableCellValueValid(
                        Object value, int row, int column);
}

Editor je upravený tak, aby při ukončení editace zkonvertovanou hodnotu předložil validátoru ke kontrole a dále jí předával jen po odslouhlasení.

public class ValidatingTableCellEditor
                            extends DefaultCellEditor {
    private Object value;
    private int editedColumn;
    private int editedRow;
    private TableCellValidator validator;

    // ... redakčně kráceno ...

    public Component getTableCellEditorComponent(
                JTable table, Object value,
                boolean isSelected, int row, int column) {
        this.value = value;
        this.editedColumn = column;
        this.editedRow = row;
        // nastav výchozí (černou) barvu rámečku 
        ((JComponent)getComponent()).setBorder(
                    new LineBorder(Color.BLACK));
        // ...
        return super.getTableCellEditorComponent(
                            table, value, isSelected,
                            row, column);
    }

    public boolean stopCellEditing() {
        String str_val = (String)super.getCellEditorValue();
        Object val = null;

        // ... zkovertuj str_val na val ...
        if(validator != null
                && !validator.isTableCellValueValid(
                            val, editedRow, editedColumn)) {
            validationFailed();
            return false;
        }
        this.value = val;
        return super.stopCellEditing();
    }

    protected void validationFailed() {
        ((JComponent)getComponent()).setBorder(
                    new LineBorder(Color.RED));
    }
}

Takové řešení má velkou výhodu v tom, že uživatel díky červenému orámování jasně vidí, že zadaná hodnota nebyla přijata a také nejsou vypisovány žádné chybové hlášky na konzoli. Výrazná nevýhoda tohoto přístupu naopak je v tom, že je nutné se explicitně postarat o to, aby se editor provádějící kontroly používal správným způsobem ve všech tabulkových komponentách, které s modelem pracují, nehledě na to, že hodnoty do tabulky nemusí být vždy zadávané přes JTable a jeji cell editor.

Správné řešení (ve smyslu nejlepší, které znám) je zkombinovat oba dva přístupy a uživatele blokovat jak při editaci pomocí editoru, tak, pokud si nenechá říct, na něj vyhběhnout s RuntimeException a on už si to rád rozmyslí. Pokud bude obojí provedeno dost důsledně, bude výsledkem jak konzistentní uživatelské rozhraní, tak bezpečné zázemí objektů pro správu dat.

Poud byste měli zájem o zdrojové kódy editoru, který používáme, napiště mi na ondrasejATcentrumDOTcz a domluvíme se