The Factory pattern

- [Instructor] Now, the first creational pattern that we're going to talk about is the factory pattern. And this is probably, of all of the patterns, the one that most developers have actually seen and used. I've used this pattern thousands of times throughout my professional career. Now, in Spring, the pattern is used throughout the entire framework. But one of the primary places it's used is the BeanFactory. And this is a little bit of a modification of a traditional factory pattern. But the BeanFactory itself is indeed a factory. In addition to the BeanFactory, there is a FactoryBean that goes with it that gives you this concept of a factory of factories, so to speak, if you look at how they work. Now, the reason I mentioned that these are so cored to Spring is because the IoC container is based on the application context. The application context extends the BeanFactory. And actually keeps a handle to it, because it acts as a wrapper around the BeanFactory. This is where all of your configured object references are stored in the Spring Framework. Again, it's leveraged heavily in the framework, but this is one of the big ones that most developers touch when they first start with Spring. Now, in a nutshell, the way that the pattern works is it allows for construction of similar classes of different types, using a so-called factory method. Now, what does that mean? You have a method call that creates the object for you and serves it back to you. Those objects are constructed from classes that share an interface or a parent class. This shared behavior of these classes allows the factory to reduce the amount of coupling in your code. So, why would we use these? It really, it comes down to, it allows you to not worry about class construction in more than one place. It allows you to leverage the interface for repetitive operations. And, the lack of construction code in your code makes copy and paste errors less likely. Now, the creation strategy that we're going to come up with for writing a factory is always code to an interface, if possible. This is a Gang of Four construct. But more so, it's good object-oriented programming practices. And when you're working with a factory, the real benefit comes from coding to the interface, instead of the concrete implementation. So, you're going to create that common interface that you're going to use in your factory objects. Then, you're going to create a class that gives instances of the interface. And in that class, you're going to implement a method that serves those concrete classes that you will then implement from the interface itself. So, again, we have a class that has a method that creates instances of the interface when under the coverage that it's actually creating instances in the concrete class. Then it serves back out. So, the consuming code, the code that consumes the factory, will create an interface and operate on that interface, even though the factory itself has served a concrete implementation. Now, there's a sister of pattern that goes with the factory pattern. And that is the Abstract Factory Pattern. And this really takes it one step further. And what do I mean by that? It becomes a factory of factories. So, you create the base factory. But all of your factories didn't share a common interface that the parent abstract factory will use to create the sub-factory, and then the instance object from it. It really gets complicated when you start to look at it until you've used it a few times. Because you have these various layers of abstraction that you've got to fight through. And this new layer of abstraction becomes very powerful if you have a bunch of types that also have a bunch of types. So, think about that for a minute. If we look at the high level, so let's look at the case where we have a bunch of pets. Those pets are all animals, different types of animals. And within those animals, there's different breeds and different sizes. And different feeding behaviors. But all in all, you have a factory of a factory that creates instance objects. And that's what this Abstract Factory Pattern is. Now, we're not going to go too deep in that. We're going to stick with the parent factory pattern. And let's jump into that in some code next.