This week’s blog, as with the last, will be about a topic directly covered in class. And, more importantly, it’ll be necessary knowledge for the first assignment of my class making it a good choice to review. The above linked article is about factory design patterns. In class, we only covered the use of simple factories whereas this article covers factory method pattern, abstract factory pattern, and static factory methods as well. Since I have a length limit, I’ll cover the most pertinent material first while focusing on things I learned outside of the classroom about their use.
Starting with the Simple Factory first. The author informs us that a simple factory isn’t considered a pattern technically but notes that it’s prevalence requires covering. They describe it as a tool that can be “to create/instantiate objects,” but it’s one that is rarely used. More commonly a static factory would be used in java. If the developer’s “factory method needs some instances to work” or “they need to instantiate the factory in order to use it,” then the simple factory works fine but a lazy static factory is still advised.
Since Static Factories are more resourceful it seems, lets discuss them in more detail. The first use he notes is the static factory’s ability to replace a constructor to “create an instance. The first advantage I see from this is the fact that factories have names. Any unique constructor name can only be used once in a class. Any time a class would need multiple constructors with the same name, static factories can be used with more descriptive names to help anyone reading/working with the code. Another convenience of static factories, as opposed to constructors, is that it doesn’t have to create an object when invoked. This helps reduce creating duplicate or unnecessary objects. One last noticeable boon is its ability to have stricter control over what instances exist. Relating to the previous blog, this helps guarantee that a class is a singleton.
Although this concept was already covered in class, its importance requires mentioning. A factory can return any subtype of its return type. This, overall, adds great flexibility to the programmer.
The author does advise that factories (and most patterns) should only be used when necessary as they can make the code more difficult to understand. Small personal projects most likely don’t require them but, they find good use when working in large projects.
This information, complimented with examples, was instrumental to my understanding of factory use and implementation. Using factories seems like a great practice, when done appropriately. It also is obvious that this is a core tool that I’ll need to have as a developer. I know that this will be applicable to my immediate work. But, beyond that, I’ll probably be using it on any project that requires me to create multiple instances of an object. Especially when that allows me to avoid having to write nearly identical constructors repeatedly. (Factories seem awesomely useful and a huge time saver.)