Naming factory methods

This all depends on the expected lifetime of the robot. Whether the factory method creates a robot or returns one is irrelevant until you need to know if this robot needs some cleanup after each use.

Consider a robot that is entirely self contained and independent. It can be created at the start of the application and reused in multiple scopes, use cases, and even threads without causing problems. The fact a robot is created the first time you call Robot.getRobot() is immaterial to the rest of the application. If this is the case, add Javadoc comments attesting to this fact. You could call it Robot.get() or Robot.create() so you don't repeat "robot" in the method name. There's always Robot.getOrCreate() and leave out the Javadoc comments.

Now consider a robot that does require some cleanup. Maybe it opens some file handles, database connections, or — heck, since we are talking about robots — a connection to an orbiting satellite or the Hive Mind. These handles on outside resources need special treatment and care. Perhaps you need one robot per application scope (where "scope" could be a for loop, an entire use case, or the duration of a modal window's lifetime). In this case, knowing you are creating a new robot or getting a pre-existing one has consequences, so you might want that to be specific. Name the method Robot.create() and leave get out of the name entirely.

My best advice when naming factory methods is to not leak any more implementation details with the method name than is absolutely necessary for consumers to use the factory method. If there are implementation details relevant to consumers of Robot, make explicit factory methods to communicate this fact and/or include these tidbits in Javadoc comments.

You don't want a zombie robot who stays connected to the Hive Mind, after all...

There are 3 situations that I treat differently:

1. A true factory that always produces something new, and that aspect is important to the overall design and usage of the system. For example, if a method creates a new record for a storing to the database which must not affect any existing records.

2. An abstraction where the consumer does not know and (usually) should not care whether the result is a new object or not. For example: Integer.valueOf. This is more common with immutable objects than mutable ones and I would be very cautious using this approach with mutable objects i.e., avoid returning mutable objects when it's unclear whether they might be shared or not.

3. A factory that is expected/required to return a shared object (in production) and that is important to its usage and the overall design. An example might be something like connection pool for a database or a semaphore which requires sharing to function properly. Note, this approach is largely inferior to dependency injection but (IMO) it can still make sense in a narrow set of use cases.

For 1: I would prefix with create and I would not use this prefix for the other 2 cases.

For 2: I'm not sure it matters that much. get is OK but I think I prefer no prefix or something like valueOf as in the Java Integer example, valueFor, instance. The whole point is that it shouldn't matter to the caller so the naming isn't really important.

For 3: I would generally go with get or a synonym of 'get'. But again, this isn't really something that I think you want to have a lot of.

This is the convention I use. I mainly use c#, but java should be fairly similar.

For your specific example I would probably use Instance:

public class Robots { public static final Robot Instance = new Robot(); private Robots() { } } 

I tend to mostly use this for types where there is no fields, or any fields/properties are constants. But the Instance naming is also sometimes used for singletons. In any case you should ensure that the class is thread safe.

If you have some more complicated caching scheme I would suggest a separate class, this allows more flexibility that is likely needed if you have some more complicated scheme. Normally this would be called a factory, but that implies the creation of objects. If that is not the intent I'm not sure about naming. Maybe "Repository"?

public class RobotsRepository{ private Robots robotTrue; private Robots robotFalse; public Robots Get(bool myBool){ return myBool ? robotTrue : robotFalse; } 

For factory methods that actually create new objects, but may fail, take a long time, or use async code, I use Create, or possibly CreateAsync:

public class Robots { private Robots(Foo foo) {...} public static async Task<Robots> CreateAsync(){ var foo = await GetFooAsync(); return new Robots(foo); } } 

For types that can be constructed in different ways using the same set of parameter types I tend to prefer FromX(...) methods. A typical case is an Angle type:

public class Angle{ private Angle(...){...} public static Angle FromRadians(double radians) {...} public static Angle FromDegrees(double degrees) {...} } 

What you describe is not a factory, it is a provider or supplier. Name accordingly.

Owner determines the lifetime of the object and is exclusively responsible for its disposal.

If an object does not need disposal, prefer more "provider" term, to support future limitations to lifetime (because it would be harder to make clients to dispose the object).