factory pattern clearlypolymorphism is not complete solutionsince we would have to keep updating code whenever we create new objectand in large game this will happen in many places the issue is the creation of the new types and not the use of these types since you want to write better codethink about the following characteristics of good code as you try to come up with better way of handling the expansion we want to add to our shapeshifter game good code is easy to maintaineasy to updateeasy to extendand clear in what it is trying to accomplish good code should make working on something you wrote couple of weeks back as painless as possible the last thing you want is to create these areas in your code you dread working on we want to be able to create objects through common interface rather than spreading the creation code throughout the system this localizes the code that needs to change when you update the types of shapes that can be created since adding new types is the most likely addition you will make to the systemit makes sense that this is one of the areas you have to look at first in terms of code improvement one way of creating centralized system of object creation is by using the factory pattern this pattern has two distinct approachesand we will cover bothstarting with the simpler factory method and then moving on to the abstract factory implementation we will also look at how you could implement each of these in terms of our game skeleton before we get into the weeds with the factory patterni want you to take note of the fact that there is one main difference between the prototype pattern and the factory pattern the prototype pattern does not require sub-classingbut requires an initialize operationwhereas the factory pattern requires sub-classing but not initialization each of these has its own advantages and places where you should opt for one over the otherand over the course of this this distinction should become clearer