Let's say that we would like to implement the loadGame() method. This method would take a file we already created (we'll discuss how later), or, at the least, the following will be required:

1. At least two HQs will fave to be created (otherwise, the game is already won)
2. Each HQ will have to produce the buildings it had
3. Each building will have to produce the units it had
4. All units will have to magically teleport to the positions they were at when the game was saved
5. If there were any commands given to units (like obliterating all enemy bases), they should resume executing them

Now, usually, it's not just one person working on a game unless it's Minecraft (TM). There's that other guy, Dave, who deals with all the command logic. He's not much into constructing buildings. But in his role, he also needs to load saved games quite often.

As the developer of all those bases that belong to you, you could give him a set of instructions you've written on how the game should be properly loaded. He may or may not follow this set of instructions. Maybe he'll forget to move the units, or build buildings. And the game will crash. You could use the Facade design pattern to simplify the job for him.

What's the main problem Dave has right now? 

To load a game, he needs to interact with at least three different interfaces:

• HQ
• Building
• Unit

What he would like is to have only one interface, something like:

interface GameWorld

That has exactly the methods he needs:

fun loadGame(file: File) GameWorld

Hey, but that looks like a Static Factory Method there! 

Yep, sometimes, design patterns are embedded into one another. We use the Static Factory Method to create our class, but its goal is to be a Facade for other more complex classes. Using a Facade doesn't mean we don't expose interfaces our facade hides behind to the client. Dave can still use every small unit to issue orders after the game is loaded successfully. 

Simple, right?