Java може й непогана річ, але мені дуже шкода джавістів коли Я бачу ось таке:

       this.game = new Game(
            new PrintStream(out),
            new CachedWords(new RandomWords(WORDS)),
            new MistakesTrack(max,
                new SolvedTrack(
                    new SuccessRoundTrack(
                        new PuzzleLog(
                            new Round(new Scanner(in))
                        )
                    )
                )
            )
        );
    }

У java є якась тулза, що дозволяє оцінити стиль коду, може якийсь jlint (як clint, pylint)? Це може допомогти

Ну, оце варто б розбити на кілька функцій. Так, краще не стало

А чому прінтами? Впевнений, що й Java вміє працювати з бібліотекою curses, може щось типу такого - https://sourceforge.net/projects/javacurses/

Я явно не Java Senior, але пара питань виникла.
1. Round у грі тільки один, і передається параметром у Game? Нащо він потрібен і чим відрізняється від Game? Чому б його не створювати в конструкторі Game? Що дає додатковий рівень абстракції тут?
2. В Game.java do-while виглядав би природніше.
3. RandomWords.get кидає виняток, якщо слово (випадкове!) пусте. Може, поставити перевірку в конструктор? Бо так можна суттєві помилки пропустити на тестуванні.
4. Часта конструкція puzzle = щось_там(puzzle) (наприклад, у Round, а в Game розтягнута на два рядки). Може, варто зробити це методами puzzle, щоб не створювати і не присвоювати зайвий раз?

2. А можете гайд на github викласти?
3. Ще раз: тести можуть не покрити ситуацію. Наприклад, у вас список з 1e5 слів, одне з яких пусте - скільки треба прогнати тестів, щоб побачити проблему?
4. Давайте подивимося...

ResultInterface result = round.handle(this.output, puzzle);
puzzle = result.puzzle();

Це, гадаю, має перетворитися у щось типу

ResultInterface result = puzzle.try_open( ... );

Для цього треба буде перенести код з Round до Puzzle - що добре узгоджується з зайвістю Round. Раунд - це лише один прохід основного циклу гри, йому не потрібен окремий клас.

2. Не бачу там нічого про do-while.
3. Ну так, саме в конструктор перевірку пхати не варто - там має бути виклик чогось на кшталт validate(), а вже цей validate має перевіряти. Ну, або ж додати змінну validated і викликати перевірку при першому використанні.
4. Зрештою, це ваш код. Якщо вам так зручно - то які у мене можуть бути претензії? 

2. Я тепер зрозумів про що ідеться мова. Стиль коду у кожної команди і у кожного програміста свій.
Попробував переписати і вийшло класно:

ResultInterface result;
do {
  result = round.handle(this.output, puzzle);
  puzzle = result.puzzle();
} while (result.next());

3. Якщо у конструкторі викликати validate у нас нічого не зміниться в плані логіки. При ініціалізації обєкта будемо обходити масив із багатьма елементами. Другий варіант із прапорцем validate можливий.

4. Можливо я щось не те сказав, але я тільки за вашу критику.
Постарався обгрунтувати свою позицію у деяких питаннях і написати чому саме я так зробив. Претензій у мене до вас немає, я навпаки вдячний за увагу і за ревю

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 і перевіряє що він виводить)

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

3) це означає що у інтерфейса завжди буде лише один клас, що його імплементує. Ситуація більш відома як Interface - InterfaceImpl. Який сенс у 'пазлІнтерфейс' якщо єдина очікувана імплементація це 'Пазл'? Для мене це те ж саме якби в jdk було StringInterface & String implements StringInterface.

4) Інтерфейс там непотрібний.

class Message {
    private final String msg;
    Message(String msg) {
        this.msg=msg;
    }
}
class EmptyMessage extends Message {
    EmptyMessage() {
        super("");
    }
}
// ....

6) Так. Окремі лінії також легше дебажити.
7) використовуєте слова/вирази з того домену і контексту і якому Ви працюєте/знаходиться код. Як я й сказав, я не дуже зрозумів що воно робить тому кращого варіянту радше не запропоную. Якийсь "puzzleToStream" був би краще (якщо назва відповідає ідеї метода) ніж хендл, який настільки генеричний що може робити трохи менше ніж будь-що. Ідею зрозуміли.

Я розумію що це проект радше академічний, просто майте на увазі, що коли програміст каже "настане момент коли ми не зможемо безболісно вклинюватись в процес" в більшості випадків це означає "я просто хотів зробити код іліґантньим", а той "момент" ніколи не настане. Це так радше зі свого особистого досвіду )