Як назвати фабричні методи?

Я здогадуюсь, що більшість заводських методів починаються з цього create. Але чому їх називають « творити »? Чому б не « зробити », « виготовити », « побудувати », « генерувати » чи щось інше? Це лише питання смаку? З'їзд? Або є особливе значення у «творити»?

createURI(...) 
makeURI(...)
produceURI(...)
buildURI(...)
generateURI(...)

Якого б ви вибрали взагалі і чому?

Кілька випадкових думок:

• "Створити" краще відповідає функції, ніж більшість інших слів. Наступне найкраще слово, яке я можу придумати з голови, - це "Конструювати". У минулому "Alloc" (виділити), можливо, використовувався в подібних ситуаціях, відображаючи більший наголос на блоках даних, ніж на об'єктах на таких мовах, як C.

• "Створити" - це коротке, просте слово, яке має чітке інтуїтивне значення. У більшості випадків люди, ймовірно, просто вибирають це як перше, найочевидніше слово, яке приходить на думку, коли вони хочуть щось створити. Це загальна умова іменування, а "створення об'єктів" - це поширений спосіб опису процесу ... створення об'єктів.

• "Конструювати" є близьким, але його зазвичай використовують для опису конкретного етапу в процесі створення об'єкта (виділити / новий, побудувати, ініціалізувати ...)

• "Збірка" та "Зробити" є загальними термінами для процесів, що стосуються компіляції коду, тому мають різні конотації для програмістів, що передбачає процес, що включає багато кроків і, можливо, багато активності на диску. Однак ідея фабрики «будувати» щось є розумною ідеєю - особливо у випадках, коли побудована складна структура даних або чимало окремих комбінованих відомостей поєднані якимось чином.

• Для мене "генерувати" має на увазі обчислення, яке використовується для отримання значення з вхідних даних, наприклад, генерування хеш-коду або випадкового числа.

• "Виробляти", "Створювати", "Конструювати" довше набирати / читати, ніж "Створити". Історично програмісти віддавали перевагу коротким іменам, щоб зменшити введення / читання.

Джошуа Блох в "Ефективній Java" пропонує наступні умови іменування

valueOf - Повертає екземпляр, який має, слабко кажучи, те саме значення, що й його параметри. Такі статичні фабрики - ефективні методи перетворення типів.

з - короткої альтернативи valueOf, популяризувати EnumSet(пункт 32).

getInstance - Повертає екземпляр, який описується параметрами, але не можна сказати, що він має однакове значення. Що стосується одиночного, getInstance не приймає жодних параметрів і повертає єдиний екземпляр.

newInstance - ЛайкgetInstance , за винятком того, що newInstanceгарантує, що кожен повернений екземпляр відрізняється від усіх інших.

get Type - Like getInstance, але використовується, коли заводський метод знаходиться в іншому класі. Тип вказує тип об'єкта, який повертається заводським методом.

новий Тип - Подобається newInstance, але використовується, коли заводський метод знаходиться в іншому класі. Тип вказує тип об'єкта, який повертається заводським методом.

Хотів додати пару пунктів, яких я не бачу в інших відповідях.

1. Хоча традиційно "Фабрика" означає "створює об'єкти", я люблю думати про це ширше, як "повертає мені предмет, який веде себе так, як я очікую". Я не завжди повинен знати, чи це абсолютно новий об’єкт , насправді мені це може бути все одно. Тож у відповідних випадках ви можете уникнути імені "Створити ...", навіть якщо саме зараз це реалізуєте.

2. Гуава - хороший сховище фабричних імен. Це популяризує приємний стиль DSL. приклади:

   Lists.newArrayListWithCapacity(100);
   ImmutableList.of("Hello", "World");
   

"Створити" та "зробити" є короткими, досить сприятливими та не пов'язаними з іншими зразками при називанні, які я можу придумати. Я також бачив обох досить часто і підозрюю, що вони можуть бути "фактичними стандартами". Я вибрав би його та використовував би його послідовно, принаймні в рамках проекту. (Дивлячись на власний власний проект, я, здається, використовую "зробити". Сподіваюся, я послідовний ...)

Уникайте "складання", оскільки воно краще відповідає шаблону Builder і уникайте "виробництва", оскільки це викликає виробника / споживача.

Щоб дійсно продовжувати метафору назви "Фабрика" для шаблону, я б спокусився "виготовленням", але це занадто довге слово.

Я думаю, що це походить від " створити об'єкт". Однак в англійській мові слово "творити" асоціюється з поняттям "спричинити виникнення як щось унікальне, яке б природним чином не розвивалося або не робилося звичайними процесами", і "розвиватися з власної думки або уява, як витвір мистецтва чи винахід ». Тож здається, що «створити» - це не належне слово. "Зробити", з іншого боку, означає "створити своє існування, формуючи або змінюючи матеріал, комбінуючи деталі тощо". Наприклад, ви не створюєте плаття, ви робите плаття (предмет). Отже, на мій погляд, "робити", означає "виробляти; причина існування або трапляється; набагато краще слово для заводських методів.

Мені подобаються нові. Мені

var foo = newFoo();

читає краще, ніж

var foo = createFoo();

У перекладі на англійську мову у нас є foo - це новий foo або foo - це створення foo. Хоча я не грамметолог, я майже впевнений, що останній граматично неправильний.

Частково умовність, частково семантика.

Фабричні методи (сигналізуються традиційними create) повинні викликати відповідних конструкторів. Якби я бачив buildURI, я б припустив, що це стосується деяких обчислень або складання деталей (і я б не вважав, що тут задіяний завод). Перше, що я подумав, коли побачив, generateURI- це зробити щось випадкове, як нове персональне посилання на завантаження. Вони не однакові, різні слова викликають різні значення; але більшість з них не конвенціоналізовані.

Я б це назвав UriFactory.Create()

Де,

UriFactory це ім'я типу класу, який надає методи, які створюють Uri екземпляри.

і Create()метод перевантажений стільки ж варіацій, які у вас є в специфікаціях.

public static class UriFactory
{
    //Default Creator
    public static UriType Create() 
    {
    }

    //An overload for Create()
    public static UriType Create(someArgs) 
    {
    }
}

Я хотів би зазначити, що я бачив усі дієслова, але виробляються у використанні в якійсь бібліотеці чи іншому, тому я б не закликав творити бути універсальною умовою.

Тепер, створення звучить для мене краще, викликає точний сенс дії.

Так так, це питання (літературного) смаку.

Особисто я , як instantiateі instantiateWith, але це просто з - за мого єдності і об'єктивних переживань C. Ім'я конвенцій всередині двигуна Unity, схоже, обертається навколо слова, instantiateщоб створити екземпляр за допомогою фабричного методу, і ціль C, схоже, любитьwith би вказати, що таке параметри / і. Це дійсно добре працює, якщо метод знаходиться в класі, який буде інстанціюватися, хоча (і мовами, які дозволяють перевантажувати конструктор, це не стільки «річ»).

Просто звичайний старий об'єктив C - initWithце також гарне порядок!

Фабричний метод не диктує назву методу. На вашій фабриці ви можете мати стільки бажаних методів, за умови, що всі вони повернуть об'єкт із однієї родини.

Для отримання більш детальної інформації відвідайте URL-адресу http://xeon2k.wordpress.com