Что такое хорошее название метода, который получает или создает объект?
Скажите, что у Вас есть кэш и метод, который сделает что-то как следующее:
if (wanted Foo is not in cache)
cache.Add(new Foo())
Return Foo from cache
Что Вы назвали бы тем методом? GetFoo(), GetOrCreateFoo() или что-то еще (и лучше)? Или это должно действительно быть разделено на два метода?
9 ответов
В большинстве случаев достаточно простого GetFoo, поскольку вызывающей стороне не нужно знать, что вы создаете и кэшируете его. В этом и заключается суть инкапсуляции.
Однако в некоторых обстоятельствах создание является дорогостоящей операцией, поэтому полезно знать, что вы можете создавать что-то по запросу, и в некоторых случаях это будет происходить медленно. В этом случае другое соглашение об именовании делает его более понятным для вызывающей стороны. В этом случае GetOrCreate() или Get(Options.CreateIfMissing) является хорошей подсказкой для вызывающей стороны.
(Поведение, конечно, должно быть отмечено в документации, но хорошо использовать имя метода, которое напоминает людям о побочных эффектах во время чтения кода, без необходимости вызывать и читать документацию для каждого вызываемого метода)
Чаще всего я встречаю такие случаи: например, при поиске узла дерева (например, в документе Xml) у вас могут быть "CreateNode" (для создания узла без добавления его в дерево) и "AddNode" (для добавления существующего узла в дерево). В этом случае "Добавить узел, если он еще не существует" должен иметь другое, описательное имя, поэтому я буду использовать что-то вроде "EnsureNodeExists", чтобы отличить его и сделать цель ясной.
Предполагая, что этот метод находится в cacheManager, тогда достаточно fetch (требуется) [или get (требуется) в зависимости от ваших личных предпочтений] - с документом API, указывающим, что элемент создан, если он не не существует.
Требуется ввести соответствующий тип, поэтому в имени метода нет необходимости использовать Foo.
Это зависит от того, какие объекты понятны пользователю.
Если создание не важно для пользователя, это GetFoo; в противном случае назовите его createOrGetFoo.
Если необходимо разграничение концепций, у вас могут быть такие методы, как GetFoo, CreateFoo и createOrGetFoo.
Я предпочитаю называть его GetFoo в соответствии с предоставленной вами информацией.
Я бы тоже назвал ее "getFoo()" и добавил в комментарии, что делает функция, если Foo не существует.
Я бы назвал его GetFoo, на том основании, что вызывающему все равно, будет ли ему предоставлен новый или уже созданный Foo - он просто хочет Get Foo.
Для кэша я бы просто назвал его GetFoo(). Кэш предназначен для работы в качестве фасада за источником данных, чтобы вызывающие стороны могли легко получить доступ к элементам, не беспокоясь о том, как они загружаются или не загружаются.
Я бы назвал это GetFoo, но задокументировал, что если запрашиваемого объекта нет в кэше, то кэш загрузит его (со всеми потенциальными последствиями для производительности, которые это может иметь).
Я предпочитаю GetFoo(), так как действие с точки зрения вызывающего абонента получает, а кэш является скорее деталью реализации.
Я бы выбрал только GetFoo(), как и большинство людей, упомянутых здесь.
Причина в том, что метод отвечает за возврат экземпляра объекта. Это его основная обязанность. Если объект не создан, то создайте объект, поместите его в кэш, а затем верните его. Внешним вызывающим пользователям не нужно беспокоиться о том, что делает метод внутри, чтобы вернуть объект, вызывающие просто будут вызывать GetFoo(), когда это необходимо. Метод GetFoo() инкапсулирует и скрывает сложность, связанную с созданием и кэшированием объекта. поэтому GetFoo()
Если такая конструкция имеет логический смысл в вашем приложении, то я думаю, что GetOrCreateFoo - подходящее название.
Другим подходом, который четко передает цель, было бы
GetFoo(bool createIfNotExists)
Конечно, если мы действительно говорим о кэше, то реализующей стороне может быть все равно, был ли элемент только что создан или нет. Вышесказанное относится к случаям, когда вызывающей стороне действительно нужно знать о возможном создании Foo и его последствиях (например, при извлечении из файловой системы или базы данных, возможно?)