3. Ідея зрозуміла. Але от наприклад мені треба буде статистика по буквах які народ найчастіше вгадує. Я зроблю дуже просто. Напишу клас LoggablePuzzle

public class LoggablePuzzle implements PuzzleInterface {

    public LoggablePuzzle(PuzzleInterface original, LogInterface log) {
        this.original = original;
    }

    @Override
    public boolean contains(Character letter) {
        return this.original.contains(letter);
    }

    @Override
    public PuzzleInterface open(Character letter) {
        PuzzleInterface result = this.original.open(letter);
        this.logger.logLetter(letter);
        return result;
    }

}

Я згідний що типу це надуманий приклад. Але це все також з особистого досвіду. Я мабуть ще створю подібну тему в PHP і покажу як було і як стало уже на реальному проекті і з реальними задачами.

iovchynnikov дякую
1. ок
2. Так я уже вище погодився що можна обійтись і без game
3. Я частково згідний але частково ні)) Що значить 100% будуть мати одну реалізацію? Якщо не враховувати GameInterface - назвати приклад інтерфейсу який буде 100% реалізовано тільки один раз?
4. Наскільки я розумію MessageInterface мав бути Message а як тоді назвати клас Message ?
5. Тут згідний 100%
6. Типу оголошуємо змінну і змінній присвоюємо інстанс обєкту? Це діло привички, мені раніше також було важко це зробити. Але зараз дуже зручно. Але вашу точку зору я розумію, спочатку це може взривати мозок.
7.  як назвати метод handle ? Типу вступауй у роль твоя черга) Мені здається як його не назви ніяк добре не буде)) Якщо можете наведіть ще приклади де є погані назви методів.

Нарешті 0) ну тут 100% але ви розумієте що LOC це взагалі не показник. Візьміть метрику NPath
Як я писав вище основна ідея це написати код який легко розширити і змінити. І ви прекрасно розумієте що у оригінальному варіанті ми ще можемо додати якісь там 2-4 умови і доповнювати алгоритм. Але настане момент коли ми не зможемо безболісно вклинюватись в процес.
Ще одна перевага у 800LOC це тести. Попробуйте напишіть тести для старої версії. У вас буде здоровий тест який завжди запускаєм main і перевіряє що він виводить)

Дуже вам вдячний за ревю і за посилання Над деякими штуками дійсно варто задуматись.

2. Гайд простий https://github.com/funivan/hangman/blob … /README.md
mvn clean package
java -classpath target/classes hangman.Main
дальше відгадуєте слова
3. Якщо у анс буде 1e5 слів тоді перебирати всі у конструкторі і проводити їхню валідацію буде напряжно. тут є ще один профіт у тому що ми не кидаємо exception в конструкторі.
Ми можемо написати враппер SafeRound реалізувати RoundInterface і там робити try catch якщо щось зламається ми виводимо помилку але не буде помилки при конструюванні обєктів. Тут дуже багато нюансів і у кожного свій стиль написання. Останнім часом стараюсь юзати цей підхід http://www.yegor256.com/2015/05/07/ctor … -free.html

4. Тут проблеми з назвами мабуть. Round Interface- це набір дій які мають виконуватись. У нас є наприклад клас SuccessRoundTrack
вся його задача це вивести меседж коли ми успішно вгадали. Сама пузля нічого не знає про try_open вона не займається цим.
round.handle не означає що ми зараз відкриємо букву. Один з класів - наприклад ProgressPanel буде показувати нам прогрес бар.   
Тому я в пузлю не закидував try_open

Master_Sergius якщо я вас правильно зрозумів:
Це консольна гра. Але нам треба її розширювати. Тут основна ідея в архітектурі.

Master_Sergius це не всі так пишуть. Це я так написав. По такому самому стилю пишу в PHP
У яві як і у інших мовах є тулзи для оцінки стилю. Але ніхто вам не скаже що не можна вкладувати 10 обєктів один в один або викликати підряд 10 new new не можна

Чим цей стиль вам кращий ?

 String word = WORDS[new Random().nextInt(WORDS.length)];
        boolean[] visible = new boolean[word.length()];
        int mistakes = 0;
        try (final PrintStream out = new PrintStream(this.output)) {
            final Iterator<String> scanner = new Scanner(this.input);
            boolean done = true;
            while (mistakes < this.max) {
                done = true;
                for (int i = 0; i < word.length(); ++i) {
                    if (!visible[i]) {
                        done = false;
                    }
                }
                if (done) {
                    break;
                }
                out.print("Guess a letter: ");
                char chr = scanner.next().charAt(0);
                boolean hit = false;
                for (int i = 0; i < word.length(); ++i) {
                    if (word.charAt(i) == chr && !visible[i]) {
                        visible[i] = true;
                        hit = true;
                    }
                }
                if (hit) {
                    out.print("Hit!\n");
                } else {
                    out.printf(
                        "Missed, mistake #%d out of %d\n",
                        mistakes + 1, this.max
                    );
                    ++mistakes;
                }
                out.append("The word: ");
                for (int i = 0; i < word.length(); ++i) {
                    if (visible[i]) {
                        out.print(word.charAt(i));
                    } else {
                        out.print("?");
                    }
                }
                out.append("\n\n");
            }
            if (done) {
                out.print("You won!\n");
            } else {
                out.print("You lost.\n");
            }
        }

Наче і ооп а наче і ні

у контроллер треба передавати базу даних ззовні а не ініціалізувати її в контроллері.

Буду дуже вдячний якщо ви скажете мені які не професійні терміни я використовую, і в професійному світі як правильно написати

Вирішив все не описувати. Згідний, можна вказати.

А чому міфічних? І чому моїх? Unit tests не є моїми і тим більше не є міфічними
Так багато чого не вистачає. Але якщо розглядати код із сторони "тестування" можна буде простіше розробити кращий код (Моя думка)

Ні) Я старався донести наступну думку - необхідно тестувати код. Я б зробив об'єкт і його перевіряв. Ви б зробили по іншому.
Висловив свою думку: якщо будуть об'єкти контроллера - буде простіше розробляти. Це моя думка.

BronzChef2056 напишіть у приват