О книге

Книга “Элегантные объекты. Java Edition” не сильно распространена на рынке в Казахстане, где я живу. Как только узнал, что появилась возможность приобрести в магазине flip.kz - купил тут же.

В предисловии автор рассказывает историю создания языков через его призму восприятия. Он пишет, что 20 лет назад языки программирования были процедурные, не было классов и ООП. И именно эти программисты, которые мыслили процедурно, и создали первые ООП-языки. Егор нисколько не умаляет их заслуг, но говорит о том, что подход к ООП с тех пор практически не изменился и программисты сейчас пишут на Java/.NET/Ruby так же, как писали процедурные программисты на первых ООП-языках.

Егор размышлял об ООП много и пришел к выводу, что нужно начать мыслить иначе, чтобы писать более правильный ООП. А тому, что значит фраза “правильный ООП”, и посвящена книга. Труд полон противоречивых тезисов, но об этом автор прямо и пишет:

Честно говоря, я не думаю, что прав во всем, о чем говорю. Я сам многие годы был процедурным программистом.

Мне нравится, что Егор добавил к каждой главе комментарии других программистов, и чаще всего эти комментарии содержали противоположное мнение. Так читатель может увидеть, что думают другие “читатели”, не заходя на соответствующие блог-посты и не читая все ветки обсуждений. Ну а если у читателя возникнет такое желание, то Егор заботливо оставил ссылки на эти обсуждения. Автор ведет свой блог и даже посвятил своей книге отдельный сайт, где перечислены основные тезисы со ссылками на блог-посты с пояснениями.

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

Нет именам классов, оканчивающимся на -er

Класс в ООП - это представитель какого-то объекта из реального мира. Основной тезис Егора в том, что в реальном мире нет Хэлперов, Врапперов, Ридеров, Хэндлеров и Контроллеров. Исключения - исторические слова наподобие User или Computer, образованные от слов use и compute соответственно.

Класс можно назвать двумя способами: правильно и неправильно. Неправильно – это когда мы смотрим, что делает класс, а нужно смотреть, чем класс является.

Объект - это представитель инкапсулированных в нем данных.

Если мы называем класс именем с -er, то это говорит нам и другим программистам, что класс - набор процедур для манипулирования данными, а не сам объект. Статья Егора расскажет о принципе более подробно.

Один главный конструктор

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

Если язык, на котором вы пишете, не позволяет перегружать методы и конструкторы, то Егор, в первую очередь, советует перейти на другие языки. Если же это невозможно, то он советует принимать в конструкторе словарь “ключ-значение” и парсить его, заполняя нужные поля.

В конструкторах нет места коду

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

Преобразования и операции необходимо делать в публичных методах, которые вызываются по мере необходимости. Если нам понадобится закэшировать результаты, то мы можем вполне создать декоратор. Более того, Егор настоятельно и рекомендует именно так и делать вместо создания приватных полей и проверки на их заполненность.

Принцип также находит отклик и в философском подходе к ООП: ООП – это декларативное программирование, а не императивное, но об этом позднее. У Егора есть статья на эту тему.

Инкапсулируйте как можно меньше