2.1 Factory

The factory pattern is one of the most commonly used patterns for creating objects. Because it abstracts the whole process of creating objects, so that we can decouple different parts of our application. For example, let's say that we are writing an application that needs some configuration settings, and we could get those settings from a variety of different places. But initially, we decide hey, the database is the best place to store that information. So we will have a class called DatabaseConfig for the lack of a better term. And there's of course a lot of configuration settings, but the only one that we are going to be concerned with is called $timeout. And then we would have a public function called the getTimeout, which would then return whatever we would have set for timeout. So $this -> timeout, and we're good to go. Now, we do need a constructor here, because ideally, we would be doing everything that we need in order to connect to the database. And if we wanted to just go ahead and read the database, and then populate the whole of our settings. Yeah, we can do that, that might not be the best thing to do, but that is an option, so that inside the the constructor, we would then say that this timeout = 20. I don't know if that's seconds, minutes, hours, it's just 20. So now, all throughout our application, we need to use our configuration. So we would say config, and then we would new up DatabaseConfig. And then everything would be great until we needed to change our class. Yeah, using databases might not be that great for configuration, because you have to have configuration information in order to connect to a database. So we decide okay, we want to use JSON files now. So we will have a JsonConfig class. And let's just copy and paste all of the code inside of database to JSON. And so now, we want to use JSON. Well, that's great, except that now, we have to go throughout every place within our application that uses DatabaseConfig and change it to JsonConfig. Yeah, I'm not looking forward to that either. So here's what we could have done. We could have said that hey, we're going to create a class that is going to create our config objects for us. So we would call this config factory. And this would have a static method that would be called simply create(). And then it would return a new DatabaseConfig, and we would be good to go. So that now, whenever we need our config object, all we would have to say is ConfigFactory::create(), and we would have our config object. So now, we only have to change this line of code to JsonConfig, and now everything is hunky dory. But this also gives us the ability to say, okay, this is an application that we want to turn around and sell. And we want to give our customers the ability to determine if they want to use JSON files or XML files, that sounds horrible. Or the database, there's a ton of different options. So we could say that, okay, we don't know what the customer's going to use, but we could use a factory still here anyway. So we could say that, okay, we are going to accept the type of config that the user wants to use. And so if type, and this is of course going to be very naive, assuming that type is all lower case and so on and so forth. But if type is JSON, then we are going to return a new JsonConfig. But if type is database, then we, of course, want to return a new DatabaseConfig. And whatever else that we provided as far as configuration features, we could add them here as well. So that's now we only rely upon this create method to create our object based upon the type of object that we need. Now, this, of course, does add complexity to our code. In fact, most programming patterns add complexity. However, that complexity comes with the ability to make changes to our code without devastating consequences. Like, for example, the factory pattern is designed, so that we can create objects that are loosely coupled with whatever is using those objects. And that loose coupling, it makes our code much more flexible, so that if we want just a simple create method, and we decide to change the type of object that we create, we can do that with a very simple change. Or if it comes to the point that creating these config objects requires a lot of extra code, well, that code is here contained within our factory, as opposed to outside the factory wherever we need the object. So when you find that you need to create multiple objects of the same type or of similar types, then the factory pattern is what you want to use.