Чистый код: имена классов?

Question

[andreycha]

Из «Чистого кода»:

Имена классов и объектов должны представлять собой существительные и их комбинации: Customer, WikiPage, Account и AddressParser. Старайтесь не использовать в именах классов такие слова как Manager, Processor, Data или Info.

Интересно, чем Мартина и компанию не устраивают Manager и Processor, но устраивает Parser? Слишком «общие» названия, не говорящие ничего о том, что конкретно делает класс?

Answer 1

[sainnr]

Я думаю, что именно Parser их также не устраивает, как и Manager или Processor. В качестве допустимого названия, они приводят в пример AddressParser, т.е. парсер, применимый конкретно к адресу. Аналогично, были бы допустимы варианты, например, AccountManager или TemplateProcessor.

Comments

[Ogra]

Я с вами не согласен.

[andreycha]

Обратите вимание: «старайтесь не использовать в именах классов». Т.е. AccountManager или TemplateProcessor сюда тоже не подходят.

Answer 2

[Ogra]

По слову Parser мне уже понятно, что делает класс — берет что-то большое (скорее всего, текст) и разбирает на небольшие составные части. Мне примерно понятно предназначение класса и его интерфейс.

А вот Manager/Processor/Data/Info… Слишком общие слова. Утрируя — вот класс DataProcessor — что он делает? Обрабатывает данные, подсказывает КО! Но какие данные? Каким образом обрабатывает?
Еще пример: AddressProcessor. Что делает этот класс? Он может приводить все адреса в один формат, может создавать граф для логистической программы, а может обрабатывать DNS записи.

Всегда можно найти более точную замену словам Manage/Process/Data/Info

Comments

[ixSci]

А как например DBManager, AccountData, EmploeeInfo и т.д. Тут тоже слишко общно? Все зависит от контекста, я считаю. И запрещать определенные слова для использовании в именовании классов, не очень умно.

[sainnr]

И я с вами не согласен.

Вот класс Parser — что он делает? Парсит что-то большое! Но что конкретно? Данные — но какие именно данные? Каким образом парсит? Что за части получаются на выходе? Тоже достаточно абстрактно. А в варианте, приведенном авторами книги — AddressParser — все более-менее ясно: преобразует адрес из текста в определенный формат.

DataProcessor, мне кажется, тоже не совсем удачный пример — слова Data и Processor также абстрактны, поэтому при их совместном использовании конкретики становится не сильно больше.

[Ogra]

DBManager — что он делает? «Управляет» БД. Но как? Можно сделать DBConnector (подключается к нужной БД), DBMapper (управялет ORM), DBService (следит за состоянием служб/демонов БД).
AccountData и EmployeeInfo не нужны — вместо них достаточно Account и Employee, в противном случае получается плохая абстракция и плохая инкапсуляция.

DataProcessor — это доказательство ad absurdo. А вам лучше повнимательнее прочитать исходный текст, там все написано.

[ixSci]

Можно сделать DBConnector (подключается к нужной БД), DBMapper (управялет ORM), DBService (следит за состоянием служб/демонов БД)

Угу и после этого агрегировать их в DBManger'е. То, что Вы разделили сущность на несколько частей никак не влияет на появление класса DBManager и никак не отменяет его полезности.

AccountData и EmployeeInfo не нужны — вместо них достаточно Account и Employee

А если мы храним данные аккаунта, его структуру и еще какую-то полезную информацию в разных классах, как тогда поступим? Тут одним Account не обойдешься ;)

[Ogra]

Если вы храните данные, структуру и еще какую-то полезную информацию в разных классах, то у вас проблемы с инкапсуляцией.

Answer 3

[ixSci]

Самое просто, это написать им e-mail и спросить их прямо. Думаю, они лучше смогут объяснить свою точку зрения, чем мы тут сейчас насочиняем.

Answer 4

[Rafael Osipov]

Согласно этой-же книге имя класса должно определять его сферу ответственности. Manager и Processor определяют слишком широкое поле ответственности. Parser — конкретное описание ответственности (разбор чего-то).

Comments

[Анатолий]

Manager, если что, управление чем-то.

[Rafael Osipov]

На мой взгляд управление чем-то — это более общее понятие, нежели разбор (parsing) данных.

Answer 5

[Илья Плотников]

Видимо в его структуре Manager, Processor, Data и Info являются системными классами и не представляют собой объект данных. Видимо он хотел сказать, что нужно четко разделять данные и классы обработки данных.

Answer 6

[korvindest]

Manager, Processor, Data или Info действительно являются слишком общими словами. Manager, можно назвать практически любой класс, который хранит хоть какие данные или доступ к ресурсам. Точно так же и со всеми остальными словами из этого списка. А Info это вообще шедевр, который я неоднократно встречал в коде.
Например вместо того что бы называть класс NetworkConectionManager, можно обозвать его NetworkConections и это, на мой взгляд, будет нагляднее.

Answer 7

[andreycha]

Ответ нашелся сотней страниц позже:

Имя класса должно описывать его ответственности. [...] Если для класса не удается подобрать четкое, короткое имя, вероятно, он слишком велик. Чем туманнее имя класса, тем больше вероятность, что он имеет слишком много ответственностей. В частности, присутствие в именах классов слов-проныр «Processor», «Manager» и «Super» часто свидетельствуют о нежелательном объединении ответственностей.