As a general rule, the default load factor (.75) offers a good tradeoff between time and space costs. Higher values decrease the space overhead but increase the lookup cost (reflected in most of the operations of the HashMap class, including get and put).
Represent an operation to be performed on the elements of an object
structure. Visitor lets you define a new operation without changing the classes
of the elements on which it operates.
Use the Visitor pattern when
An object structure contains many classes of objects with differing interfaces, and you want to perform operations on these objects that depend on their concrete classes
Many distinct and unrelated operations need to be performed on objects in an object structure, and you want to avoid “polluting” their classes with these operations. Visitor lets you keep related operations together by defining them in one class. When the object structure is shared by many applications, use Visitor to put operations in just those applications that need them
The classes defining the object structure rarely change, but you often want to define new operations over the structure. Changing the object structure classes requires redefining the interface to all visitors, which is potentially costly. If the object structure classes change often, then it’s probably better to define the operations in those classes
Provide objects which follow value semantics rather than reference semantics.
This means value objects’ equality are not based on identity. Two value objects are
equal when they have the same value, not necessarily being the same object.
Use the Value Object when
You need to measure the objects’ equality based on the objects’ value
Update method pattern simulates a collection of independent objects by telling each to process one frame of behavior at a time.
The game world maintains a collection of objects. Each object implements an update method that simulates one frame of the object’s behavior. Each frame, the game updates every object in the collection.
To learn more about how the game loop runs and when the update methods are invoked, please refer to Game Loop Pattern.
If the Game Loop pattern is the best thing since sliced bread, then the Update Method pattern is its butter. A wide swath of games featuring live entities that the player interacts with use this pattern in some form or other. If the game has space marines, dragons, Martians, ghosts, or athletes, there’s a good chance it uses this pattern.
However, if the game is more abstract and the moving pieces are less like living actors and more like pieces on a chessboard, this pattern is often a poor fit. In a game like chess, you don’t need to simulate all of the pieces concurrently, and you probably don’t need to tell the pawns to update themselves every frame.
Update methods work well when:
Your game has a number of objects or systems that need to run simultaneously.
Each object’s behavior is mostly independent of the others.
As explained in the book Game Programming Patterns by Robert Nystrom, type object pattern helps in
Allowing flexible creation of new “classes” by creating a single class, each instance of which represents a different type of object
Say, we are working on a game which has a hero and many monsters which are going to attack the hero. These monsters have certain attributes like attack, points etc. and come in different ‘breeds’ like zombie or ogres. The obvious answer is to have a base Monster class which has some fields and methods, which may be overriden by subclasses like the Zombie or Ogre class. But as we continue to build the game, there may be more and more breeds of monsters added and certain attributes may need to be changed in the existing monsters too. The OOP solution of inheriting from the base class would not be an efficient method in this case.
Using the type-object pattern, instead of creating many classes inheriting from a base class, we have 1 class with a field which represents the ‘type’ of object. This makes the code cleaner and object instantiation also becomes as easy as parsing a json file with the object properties.
This pattern can be used when:
We don’t know what types we will need up front.
We want to be able to modify or add new types without having to recompile or change code.
Only difference between the different ‘types’ of objects is the data, not the behaviour.
Trampoline pattern is used for implementing algorithms recursively in Java without blowing the stack
and to interleave the execution of functions without hard coding them together
It is possible by representing a computation in one of 2 states : done | more
(completed with result, or a reference to the reminder of the computation,
something like the way a java.util.Supplier does).
Trampoline pattern allows to define recursive algorithms by iterative loop.
Use the Trampoline pattern when
For implementing tail recursive function. This pattern allows to switch on a stackless operation.
For interleaving the execution of two or more functions on the same thread.
Known uses(real world examples)
Trampoline refers to using reflection to avoid using inner classes, for example in event listeners.
The time overhead of a reflection call is traded for the space overhead of an inner class.
Trampolines in Java usually involve the creation of a GenericListener to pass events to an outer class.