Design patterns

Any programmer should be well aware of the concept of design patterns. even if you have not been directly exposed to the terminology, you will notice that many of these patterns have been drilled into you since intro. It is sometimes good to understand what these patterns are because they are essentially what reduces a lot of abstraction and confusingness in computer code. It is important to know why each pattern is good and where each fall short, so when any given problem arises you may know more than one way to solve it and compare which might be best for your given scenario.here is a short list of popular design patterns to help understand how they work and what different types of patterns there are.Singletonthe singleton design pattern is a very effective for organizing code especially for readability and helps to minimize global variables. In a singleton you begin with your class which defines one private, static member variable and is used each time you need to call an instance of that class.for example a game manager could be considered a singleton where each of its public member functions are something you may use that object for.like saygameManager-> startLevelgameManager->setObjectNodesgameManager->checkForCollisionssince all of these calls are referring to a single object, it is called a singleton.Facadethis pattern is useful when we are given what may seem like several unrelated systems that need to be somehow tied together for the sake of the software. Any game engine requres the wrapping of rendering, physics sound etc, so when you initialize/access this information it is all stored within the bounds of the facade.you may think of it as the super singleton, that manages all the other little singletons into one classtake a look at my wonderfully oversimplified game engine facadepublic class macLocEngine{void soundLibraryvoid graphicsLibraryvoid physicsLibrary}where macLocEngine is the Facade class and the sub classes are all wrapped together for easy access and usability of programmers who don't need to know the complexities that may be involved with each subsystem to use them.FactoryFactories allow many different types of object to be linked together so that we don't necessarily have to have all the attributes of the object right away when it is implemented.This one is a little harder for me to explain so I will just jump into an examplepublic Class Particles(){float speed;Vector3 position;Vector3 colour;int maxParticles, minParticles;void initiate;void emitter;}not the most complete particle class but the point is that all types of particles share some common properties like they all take up 3D space, and they all have a velocity, but what if we want different sort of behaviors out of them? it is possible just to inherit the base info that is common between all particles and then use that information for its own designpublic void lightningParticles():Particles{void applyDistribution()void applyLaplaceTransform()}public void waterParticles():Particles{void applyNavierStokesApproximation()}as the rendering of water and lightning have different properties it would be redundant to say, apply a Navier Stokes equation to a lightning particle. Which is why it is considered more efficient to break it down to several different types of particles. you can go one step beyond this even and say that particle inherits from the gameObject class which is just a position for example.StatesI think that states are something pretty hard to avoid, and even if you don't realize it you have probably been using them in some form or another.states can be scripted using if statements or hardcoded with switches()say you are just starting a game you may have mulitple states to choose from, consider the following switch statementSwitch(selection){case ("newgame")initiate.theGame()case ("continue")resume.theGame(memory)case("instuction")displayManual()case ("Main Menu")mainMenuState()}in this example we have 4 different potential states that need to be accessed in different ways. using states the programmer can appropriately construct a list of potential actions that could be taken at any given time. It is also useful to use the state pattern when designing AI, and have the states change dynamically depending on such variables asdistance from player, Health, nearness to obstacles etc.AdapterThe Adapter pattern allows us to take something foreign that is useful to our system, but may not be directly compatible, and change or "adapts" its core values to work with the way our system reads it.for example you may be building an engine that reads and manipulates rectangle Geometry usingmanipulateRect(Vector3 xyz, length, width){doSomething()}But what if you getting your polygons from a system that defines it using the followingcreatePoly{Vector3 point1Vector3 point2vector3 point3vector3 point 4}Adapters will take in that initial information of 4 points, and use math like finding distance between points to return the values necessary for our system.AdaptPoly{Vector3 a, b, c, d){Length = getDist (a, b);Width getDist  (a, c);center = getCenterPoint(a, b,c,d)}as I mentioned before there are several different design patterns that can be used, and finding the right one can sometimes be a difficult task.check out this resource I found that provides many different examples, problems rules and discussions of Design patterns.