Хаос именования класса [закрывается]
Как правило, единственная ссылка на класс Pimpl в заголовке для класса Владельца (CAT в этом случае) была бы предописанием, поскольку Вы сделали здесь, потому что это может значительно уменьшить зависимости.
, Например, если Ваш класс Pimpl имеет ComplicatedClass как участника (и не только указатель или ссылка на него) затем, необходимо было бы определить ComplicatedClass полностью, прежде чем это будет использование. На практике это означает включая "ComplicatedClass.h" (который будет также косвенно включать что-либо, что ComplicatedClass зависит от). Это может привести к единственному получению по запросу заливки заголовка в партиях и большом количестве материала, который плох для управления Вашими зависимостями (и Вашим временем компиляции).
при использовании pimpl idion Вам только нужен к #include материал, используемый в открытом интерфейсе Вашего типа Владельца (который был бы CAT здесь). Который делает вещи лучше для людей, пользующихся Вашей библиотекой, и означает, что Вы не должны волноваться о людях в зависимости от некоторой внутренней детали Вашей библиотеки - или по ошибке, или потому что они хотят сделать что-то, что Вы не позволяете так они #define частная общественность прежде включая Ваши файлы.
, Если это - простой класс, нет обычно никакой причины использовать Pimpl, но в течение многих времен, когда типы являются довольно большими, это может быть большая справка (особенно в предотвращении долгого времени изготовления)
5 ответов
Популярное мнение о SO, похоже, состоит в том, чтобы избегать использования суффиксов, таких как Manager, Info, Helper или Util.
См .: Smelly Class Names и Имена классов, требующие рефакторинга .
Именование сложно, поэтому не волнуйтесь, что вы боретесь, потому что все мы это делаем. И поверьте мне, это никогда не станет проще!
Лично со всем контроллером / менеджером / помощником / утилитой / любыми суффиксами я обычно использую правило, что если это соглашение (например, для ASP.NET MVC это соглашение, что имя класса контроллера оканчивается на "Controller"), затем используйте суффикс, в противном случае старайтесь изо всех сил избегать этого. Я бы предпочел класс под названием HttpUploader , чем HttpUploadManager .
Самая важная вещь в именовании - это то, что класс должен делать то, что он говорит. Если это класс, который загружает что-то с помощью HTTP, то HttpUploader точно это описывает. Использование причудливого имени вроде HttpUploadManager не говорит мне, что он делает. Сама вещь загружает? Управляет ли он загрузкой нескольких вещей? Я предпочитаю, чтобы все было как можно проще, описывая цель класса / метода / чего угодно.
Я нахожу хороший совет: если вы действительно пытаетесь назвать что-то, как будто вы целую вечность думали и вы по-прежнему не можете выделить то, что он делает, в разумное имя, тогда вам, вероятно, придется реорганизовать все, что вы пытаетесь назвать, на более мелкие и более конкретные компоненты.
Если у вас возникли проблемы с выбором имени, обратитесь к ClassNamer.org .
Вы также можете попробовать просмотреть список более описательных (красочных?) Суффиксов: ManagerManager .
Проблема с обычным советом (назовите класс для чего это так) заключается в том, что многие вещи класса не имеют хороших эквивалентов в реальном мире, и поэтому наш традиционный словарь может не совпадать. Например, HttpUploader может быть связан с другим классом, который помогает с загрузкой, выполняет некоторую координацию или (смею сказать?) Управляет загрузкой. Подобная координация посредников обычна в программном обеспечении, но слова для ее описания настолько расплывчаты, что вызывают презрение.
В книге Чистый код есть полная глава об именах переменных. Хороший материал.