namingconventions

Convention of naming a "get/create & get" function


I am working on a function that returns an object from a container (e.g an Array) by value (e.g by name). If the object doesn't already exist, then a default copy of the object (default constructor) is created and returned.

That way, this function ALWAYS returns an object, regardless if the object existed prior to calling the function.

Now my question: is there any convention to name such a function so people using my library won't need to read the subjacent code to figure what it does? Something like GetOrCreateThenGet or GetForSure?


Solution

  • Why do you need anything other than getXXX(). Any method that has and/or means that it is doing to much and is mixing concerns and seriously breaking the Single Responsibility Principle.

    Should the caller actually care if the object is being created on demand if all they need from the contract is to get the object?

    getOrCreate implies you will get the object or it will be created but not returned.

    Again why would I care about the create part?

    If I really am supposed to care it would be getOrCreateAndGet to be semantically correct, but highly unorthodox and prone to discussions with peers about methods doing to many things and mixing concerns and breaking the Single Responsiblity Principle? Just because other people name things whacky and non-sensical isn't a good excuse to do it wrong also.