В общем, хорошо избегать таких слов, как «handle» или «process», как части имен рутины и имен классов, если вы не имеете дело с (например) дескрипторами файлов или (например) процессами unix. Однако абстрактные классы часто не знают, что они собираются делать с чем-то, кроме, скажем, обработки. В моей текущей ситуации у меня есть «EmailProcessor», который входит в почтовый ящик пользователя и обрабатывает сообщения от него. Мне не совсем понятно, как дать этому более точное имя, хотя я заметил, что возникает следующий вопрос стиля:
- лучше относиться к производным классам как к клиентам и называть базовый класс частью той функциональности, которую он реализует? Придает ему больше смысла, но нарушит его. Например, EmailAcquirer будет разумным именем, так как он получает для производного класса, но производный класс не будет получать для кого-либо.
- Или просто смутное имя, так как кто знает, что будут делать производные классы. Однако «Процессор» все еще слишком общий, поскольку он выполняет много соответствующих операций, таких как вход в систему и использование IMAP.
Есть ли выход из этой дилеммы?
Проблема более очевидна для абстрактных методов, в которых вы не можете действительно ответить на вопрос "что это делает?" потому что ответ просто «все, что хочет клиент».
object-oriented
coding-style
naming
djechlin
источник
источник
Ответы:
Проблема не в названии, а в том, что вы вкладываете слишком много в один класс.
В вашем примере класса некоторые части очень конкретны (как будут получены письма). Другие части очень абстрактны (что вы будете делать с почтой).
Лучше делать это с отдельными классами, чем с наследованием.
Я предлагаю:
абстрактный MessageIterator, вложенный в класс POPMailBoxDownloader
другой класс, который СОБСТВЕННЫЙ POPMailBoxDownloader и делает что-то с сообщениями.
источник
Если я не могу найти подходящее имя для класса, я пишу документацию для этого класса. Он описывает цель занятия в одном месте. Обычно я могу получить хорошее имя для класса из этого описания. Это также полезно для абстрактных классов.
Если описание класса «Вход в почтовый ящик пользователя и обработка сообщений от него», я бы предложил «InboxProcessor» в качестве имени класса. Если производный класс имеет «Вход в почтовый ящик пользователя и перемещение спам-сообщения в папку спама» в качестве описания, я бы выбрал «InboxSpamMover» в качестве имени.
Я не вижу проблемы при использовании общих имен, таких как «процессор», если они отражают общее назначение абстрактного класса.
Если у вас есть проблемы с описанием назначения класса в одном или двух сценариях, то у вас могут быть проблемы с дизайном. Возможно, класс делает слишком много и нарушает принцип единой ответственности . Это также относится к абстрактным классам.
источник
Перефразируя Фрэнка Заппу, это то, что он есть и должен называться именно так. Ваш пример просто недостаточно глубоко вник в то, что происходит. Это
EmailToTroubleTicketProcessor,EmailGrammarCorrectorилиEmailSpamDetector?Это не совсем верно; вопрос, на который вы не можете ответить за что-то абстрактное: « как он делает то, что делает?» потому что это зависит от реализации. Если у
EmailSenderкласса естьDeliveryStatus deliver(Email e)метод, есть подразумеваемый контракт, что реализация получит электронное письмо, попытается доставить его и вернуть статус о том, как он прошел. Вам не важно, подключается ли он к SMTP-серверу или распечатывает его для привязки к почтовому голубю, если реализация выполняет то, что было обещано. Тезисы просто количественно определяют это обещание, чтобы реализация могла сказать: «Да, я делаю это».источник
void doWhatYouDoWith(Email e), вы все равно можете вызывать класс anEmailDisposer, который достаточно конкретен, чтобы сказать, что он делает, но достаточно общий, как зависит от реализации. Хотя я думаю, что @KrisVanBael прибил это: если вы прибегли к чему-то неоднозначному, под одной крышей может быть слишком много.Подумайте, почему плохо использовать такие слова. Они описательные? Какие слова есть, чтобы описать классы? EmailBaseClass? Может ли это быть более наглядным, чем, скажем, EmailManager или что-то подобное? Ключ должен иметь представление о рассматриваемом классе, так что найдите правильные глаголы или существительные. Относитесь к своему коду, как к поэзии.
источник
int age«ageInteger», только еще хуже, поскольку я ожидал, что из него будут извлекаться простые текстовые электронные письма, электронные письма MIME и т. Д. Нет необходимости описывать то, что предшествует словуabstractв первую очередь (это Java). У вас есть какое-то конкретное понимание базовой части этого класса? И более глубокое понимание по-прежнему не решает проблему именования чего-то, что будет пересекать отношения "я-это", у меня может быть что-то слишком расплывчатое или слишком общее, я не вижу выхода из этого, если, если бы у меня не было больше понимания, чтобы иметь больше понимания.ageIntegerили что-то подобное действительно уместно. Венгерская нотация - это сокращенная версия из контекста, где это часто случалось. Конечно, бывают случаи, когда вам может понадобиться что-то по аналогииageNumericиageStringв той же области, причем указание типа в имени является самым простым и понятным способом устранения неоднозначности.systemControllerявляется ли это абстрактный базовый класс или лист в огромной иерархии. Конечно, это можно исправить с помощью IDE (как, я полагаю, имеет место в большинстве случаев разработки на Java?), Которая может немедленно информировать пользователя о содержимом и структуре класса, так что на самом деле проницательные имена не могут быть оправданы подобным образом.