Я смог - сможешь и ты!

private static bool TryOpenDoor(); (посмотреть реализацию можно на странице 119)

и после ряда "улучшений" и вынесения методов получается следующий код:

Давай посмотрим что с ним не так? Пункты будут идти по моему субъективному убыванию критичности.

1) Это другое поведение ! Это прям вообще не нормальная вещь. И дело не в том что мы переименовали метод, это как раз допустимо. Мы изменили сигнатуру метода, ранее он возвращал булевское значение (правда\ложь) , теперь он ничего не возвращает. В случае реального рефакторинга IDE нам бы подсказала и такой проект просто не собрался бы. Почему так получилось ? Потому что по факту начальный код и конечный выполняет немного разные вещи, и оригинальный метод является частью InteractWithDoor() и он естественным образом разваливается на 2 метода, которые и хочется объединить под новым более общим методом.

2) Смешение уровней абстракции. Это может показаться не критичным на таком маленьком примере, но в реальности это огромная проблема и очень важно на начальном этапе дать правильное понимание базовых вещей в архитектуре кода. Так как когда вы перейдёте от 20 строчных примеров к проектам с 20 000 классов вы сможете намного ухудшить качество своего кода, но не улучшить его. У нас есть метод запроса\чтения возраста из консоли, если кто не знает это ReadInt, и первый вывод консоли логически относится к этому методу, тем более в нём уже есть интерактивность с пользователем. На том уровне где мы оперируем методом ReadInt aka GetAge как правильно не должно быть вывода в консоль, если он есть внутри ReadInt.

3) ReadInt() - это вызывает вопросы. Для начала сообщу что почти любая IDE выведет тип возвращаемого значения просто при наведение на метод. В старом коде на си, например, можно встретить обозначение типов в приватных переменных класса, но даже в таком случае оно дополняет название, а не заменяет его. Если бы метод хотя бы назывался GetAgeInt я бы не стал придираться, в конце концов есть принятые в командах стандарты и практики ,а также вкусовщина. Можно возразить "но этот же метод действительно просто получает Int32 из консоли", и с этим можно было бы согласиться, если бы это был какой то публичный метод для consol-и, но даже в таком случае ключевым тут было бы что это значение из консоли. То есть выглядеть должно было, либо так ConsoleEx.GetInt32(), либо GetInt32FromConsole(). Приватный метод, особенно с таким маленьким скоупом, должен иметь очень специфичное функции имя.

4) В книге автор заявляет что он добился успеха выделив "чистое правило" открытия двери в TryOpenDoor() , кстати это было названием оригинального метода. Но давайте посмотрим на этот метод, что в этой строке "age >= 18" есть о двери ??? У меня нейминг вызывает вопросы

И большая часть того что написано это не просто "придирки"? а реально очень критичные вещи. Не хочу сказать что сам могу написать идеальный код с точки зрения доступности для понимания и структуры, иногда, особенно в реальных проектах приходится идти на какой то трейд офф, бывает реально сложно подобрать нейминг и так хочется сделать метод с несколькими ответственностями или у классов появляется какое то неявное состояние и потом с ним реально очень сложно бороться. Но , во-первых, я не пишу книг, т.к. являюсь заурядным программистом, и на мой взгляд их должны писать те, кому действительно есть что сказать поверх формальной документации. Во-вторых, проблемы начинаются в действительно комплексных проектах, где есть причины для появления говнокогда. В третьих, для такого маленького учебного проекта тут слишком много косяков. Если бы я писал книгу то к любой строчки кода относился бы как минимум, как к коду, который я отправляю на код ревью, а в реальности бы это был код, который кто то уже заревьювил и заупрувил.

Многие в комментариях гонятся за какими то "актуальными знаниями", которые толи должны быть в книге, толи не могут быть в ней т.к. она устаревает. Но в реальности я легко могу сказать тимлиду, что не знаю что то требуемое из нового реквайремента или таски и мне нужно время на изучение документации\кода. Но я плохо себе представляю как бы я смог объяснить такое качество кода, при том что в нём самый базовый функционал, который будет работать и на версиях языка десятилетней давности, такой код плох даже для intern позиции.

Как мог бы выглядеть этот код с моей точки зрения. Если мы хотим реализовать InteractWithDoor, то исходный метод, конечно, недостаточен и он разбивается на 2 составляющие, получение возраста и его валидация, но далее нам требуется открытие\отказ в открытие двери, что в коде автора реализовано через сообщение "Дверь не для тебя!" с очередным нарушением уровня абстракции.

Пара комментариев по коду.

1) Конечно, метод EnableRussianSymbolsForConsole не относится к InteractWithDoor, но когда книжный пример при копирование в IDE на некоторых системах будет выдавать тебе вопросы вместо текста это не очень хорошо. И для примера добавить такой вызов допустимо, но лично я бы предпочёл просто использовать английский во всех запросах.

2) Длинный нейминг методов допустим и даже хорош для само документирования кода, в случае если это внутренние методы с малым скоупом видимости (в данном случае все методы кроме InteractWithDoor являются приватными).

3) Может показаться что методы ShowNotAllowedMessage и OpenDoor немного избыточны т.к. у них однострочная реализация, но лично моя практика показывает что такая разбивка оправдана.

4) Код получился длиннее и это нормально, особенно когда речь идёт про рефакторинг таких маленьких фрагментов. Главный показатель качества кода не его количество, а его читаемость и простота модификации. При рефакторинге больших объёмов кода часто бывает и обратный эффект из-за устранение дублирования и избыточной логики, вызванной кривой архитектурой.

Хороший код на верхнем уровне читается почти как осмысленный текст без матана и всяких сложных условий.

Взять возраст из консоли и используя его попробовать открыть дверь

Что же такое попробовать открыть дверь?

Если открытие двери разрешено для данного возраста, то открыть дверь, иначе показать сообщение, что открытие запрещено.

не идеально, согласен, но я на многое и не претендую, а теперь попробуйте прочитать оригинальную программу автора.

P.S. Если взглянуть на обе версии, может показаться что разница небольшая, но это проблема масштаба, все эти вещи становятся очень критичны когда кодовая база растёт вместе с числом разработчиков работающей над ней. И , конечно, у меня нет тех талантов, чтобы суметь это показать в таком маленьком фрагменте кода, в том числе и поэтому у меня никогда не было желания писать какие-либо материалы по программированию.

Цифровизация предоставила множество удобных механизмов: например, подать заявление куда угодно можно даже с горшка, если смартфон в руках и связь устойчивая.

В СПб - портал "Наш Санкт-Петербург" или Госуслуги "Решаем вместе" (по всей РФ) . Если планируется не разовая акция - есть и одноименные приложения, в них удобнее.

Нюанс кроется в деталях, точнее, формулировках просительной части.

Можно написать: "Там-то яма, прошу заделать" и получить ответ: "Данная проблема не требует безотлагательного принятия мер, не попадает в перечень проблем, по которым необходимо проведение срочных работ."

То есть "когда-нибудь сделаем, вы там ждите".

А можно пару минут провести в гугле, и состряпать нечто вроде:

"Там-то и там-то на дороге глубокие ямы. С коляской через ямы пройти возможным не представляется, велосипедистам и автомобилистам приходится объезжать их. Согласно п.4.1 ГОСТ Р 50597-2017 данная дорога имеет категорию "Е" - улицы в жилой застройке второстепенные, проезды основные, велосипедные дорожки.

Согласно п.5.2.4 и таблице 5.3, срок устранения данных повреждений на дорогах данной категории - до 20 суток.

Прошу Вас устранить повреждения дорожного покрытия. Спасибо."

С такой формулировкой ответственной организации значительно сложнее съехать с быстрого решения - указаны сноски на нормативные документы. В случае обращения через портал - модераторы кривую козу про "не требует безотлагательного решения" уже не пропустят. Результат вас наверняка обрадует.

И опять же, если это будет не разовая акция - есть шанс, что обслуживающая организация захочет с вами подружиться, возможно даже обменяться контактами. И может попросить писать им о проблемах лично, не через порталы. Зачастую мелкие проблемы ЖКХ таким образом решать значительно быстрее.