Для меня:
Помощник - это фасад, или он кодирует / декодирует определенный формат данных и не имеет состояния между вызовами.
Утилита предназначена для кодирования / декодирования формата или выполнения ввода-вывода, и, если она создает соединения, часто не поддерживает соединения или не открывает файлы между вызовами.
Менеджер похож на помощника, но имеет состояние между вызовами.
Фабрика - это класс, который получает или создает, а затем возвращает объект (либо пользовательский, либо API).
Простой и По умолчанию часто означает просто базовый класс.
A Мой «класс», как правило, предназначен для предварительных проверок идей и примеров кода, хотя иногда он используется в производственном коде, например, для MyApplication и MyView (по сути, для именования синглетонов).
Эти имена классов де-факто. Это значения, которые я создаю и вижу чаще всего, но часто встречаются противоречивые схемы именования и несоответствия. Они не являются формальными именами шаблонов проектирования, и на практике выбор любого из этих имен кажется почти произвольным. Некоторые люди маркируют все свои классы, которые являются потокобезопасными, с одним из этих имен, и те, которые не с другим из них.
Часто я вижу, что имя "Manager" присваивается классу, который выполняет функцию, похожую на ORM, с объектами или ключами, или объекту, который разрешает соединения.
EDIT
Я вижу приложение, построенное на платформе, как обычно имеющее следующие основные объекты:
- Официальная заглушка входа / выхода / обработки процесса
- (одноэлементный) объект приложения (ссылается на иерархическую модель данных и, возможно, объекты задачи)
- Менеджер баз данных
- Сетевой менеджер
- Пользовательский интерфейс (который ссылается или не ссылается на модель представления в зависимости от ваших религиозных убеждений)
- Помощник / Утилиты / Фабричные классы
- Код клея Разное
- Вспомогательные файлы
Я считаю, что сосредоточение на максимизации тестируемости и минимизации площади поверхности этих интерфейсов более важно, чем именование пакетов и имен файлов; Я думаю, что вы должны следить за своим собственным носом для подробных разбивок и названий для вашего проекта. Разделение кода на разные файлы для целей SCM особенно важно для общих файлов, на которые указывает более чем один маркер.
EDIT
Я использую синглтон, наименьший вес, составной, итератор, сувенир, наблюдатель, состояние, стратегию как рутину. Я использую фасад, прокси, цепочку ответственности между модулями и в коде пользовательского интерфейса. Я иногда использую фабрику, прототип и конструктор в сложных системах данных, а также шаблон и посетителя, когда система концептуально особенно сложна. Я иногда использую адаптер, мост, фабрику, абстрактную фабрику, декоратор, когда поведение сложное. Я редко использую Interpreter и использую медиатор, чтобы помочь мне написать более общий код в некоторых случаях. Лично я не люблю называть свои классы в честь GoF, но многие люди очень рады, это может быть хорошей идеей, и я не против практики. Это может быть очень полезно, и если оно делает людей счастливыми и помогает понять всем, что происходит в конкретном случае, тогда это здорово.
Мне просто кажется, что называть объект моего приложения Singleton, Composite или ChainOfResponsibilityLink (?) Не очень хорошо, а вызывать мои адаптеры кода сети и базы данных - не очень хорошо, поэтому я называю их менеджерами. И я называю многие вещи, которые, возможно, следует называть «Фасады» в «GoF», «Помощники» или «Утилиты», потому что я думаю, что это более понятно, что имеется в виду.