NAME AND ID
1. A game development company is working on a fantasy role-playing game. In the game, there are
different types of characters (e.g., warriors, archers, mages). Each character has its own set of
abilities, stats, and equipment, but players can also customize their characters (e.g., changing
armor, weapons). (5 marks)
ANS: a builder patter would be suitable in this scenario. The user can ask the director -or builder- to
create a character of a specific type, then they themselves can edit it and add to it or remove from it,
again, by using the director or the builder directly.
2. A coffee shop wants to automate the process of preparing different types of coffee. Customers
can order: (5 marks)
a) Espresso: a strong, black coffee.
b) Latte: coffee with steamed milk.
c) Cappuccino: coffee with steamed milk and foam.
ANS: since each type has its own steps and the steps for each one will not change a factory method
pattern would be suited here since. All of them are types of coffee so they can benefit from having a
shared interface while still having dedicated a factory for each type that can take care of its creation.
3. A car supplier automated its cars manufacturing process, so you are required to design a system
to that produce cars with the same make but different model specifications –knowing a
customer could choose and mix between the offered options-. For example, on a (Toyota
Corolla): (5 marks)
a) Toyota Corolla GX: comes with Manual gear and basic options.
b) Toyota Corolla GLX: comes with an automatic gear and mid options.
c) Toyota Corolla SX: comes with an automatic gear, a sunroof and sport options
ANS: since there is a base make, the prototype pattern would be the best choice. The base car -with the
default make- can be cloned and then customized or added to to become a different model.
4. In the above example if the company wanted to make a future to add new makes and models
(for example: Camry, Land cruiser). What pattern would you use to prevent any possible
problems in future? (5 marks)
ANS: since the new feature requires both the make and model to be customizable then an abstract
factory pattern might be the right solution. the abstract factory would take in a type of make -interface-
and a type of model -interface-, meanwhile all the makes would follow the provided interface for them
and the same for them model, this way a concrete factory can hold a concrete make and model as
required to make adding new makes, models, or cars will not break the current code base due to any
conflicts -no conflict because they all follow that abstract factory, make, model interfaces-.