Say you have a cache, and a method that will do something like the following:
if (wanted Foo is not in cache)
cache.Add(new Foo())
Return Foo from cache
What would you call that method? GetFoo(), GetOrCreateFoo() or something else (and better)? Or should this really be divided into two methods?
My preference is GetFoo(), as the action from the point of view of the caller is getting and the cache is more of an implementation detail.
I'd call it GetFoo, on the grounds that the caller doesn't care whether it's going to be given a new or an already-created Foo - it just wants to Get a Foo.
If this design makes logical sense in your application, then I think GetOrCreateFoo is an appropriate name.
Another approach that clearly conveys its purpose would be
GetFoo(bool createIfNotExists)
Of course, if we're really talking cache the implementing side might not care whether or not the item was just created. The above applies in cases where the caller actually does need to know about the possible creation of Foo and its implications (such as when retrieving from filesystem or db, perhaps?)
I would call it "getFoo()" too and add to your comments what the function does if a Foo is not existent.
For a cache, I would simply call it GetFoo(). A cache is designed to act as a facade behind a data source so that callers can easily access items without worrying how they are or are not being loaded.
I'd call it GetFoo, but document that if the requested object is not in the cache, that the cache will load it (and all the potential performance implications that might have).
I'd go for only GetFoo() just like most of the people have mentioned here.
Reason is - The method is responsible for returning the object instance. That is its primary responsibilty. If the object is not created, then create the object put it in cache and then return it. external callers, need not bother what method internally does to return the object, callers will simply call GetFoo() whenever needed. Method GetFoo() encapsulates and hides the complexity behind creating and caching the object. hence GetFoo()
In most cases a simple GetFoo suffices as the caller doesn't need to know that you are creating and caching it. That's what encapsulation is all about.
However, in some circumstances, creating is an expensive operation, so it's useful to know that you may be creating something on demand and in some cases it will be slow. In this case a different naming convention makes it clearer to the caller. In this case a GetOrCreate() or Get(Options.CreateIfMissing) is a good hint to the caller.
(The behaviour should of course be noted in the documentation, but it's good to use a method name that reminds people about side effects while they are reading the code, without them having to bring up and read the documentation for every method that is called)
The sort of case I find this happening in most often is (for example) when finding a tree node (e.g. in an Xml document) you might have "CreateNode" (to create a node without adding it to the tree) and "AddNode" (to add an existing node to the tree). In this case, an "Add a node if it doesn't already exist" needs to have a different, descriptive name, so I will use something like "EnsureNodeExists" to differentiate it and make the purpose clear.
It depends what kind of object that make sense to user.
If the creation is not important to user, it is GetFoo; otherwise, call it createOrGetFoo.
If the differentiation of concepts is needed, you might have methods like GetFoo, CreateFoo and createOrGetFoo.
I prefer to name it as GetFoo according to your given information.
Assuming this method is on a cacheManager then fetch(wanted) [or get(wanted) depending on your personal pref] is enough - with the API doc indicating that the item is created if it doesn't exist.
Wanted should be typed accordingly - so there's no need for Foo in the method name.