Ilkka Seppälä
4108f86177
* Changed database implementation. Removed static objects. * Fix Logs * Fix 40 errors from checkstyle plugin run. 139 left)) * Fix CacheStore errors from checkstyle plugin 107 left * Fix last errors in checkstyle. * Fix sonar issues * Fix issues in VALIDATE phase * Fix Bug with mongo connection. Used "Try with resources" * Add test * Added docker-compose for mongo db. MongoDb db work fixed. * Provided missing tests * Comments to start Application with mongo. * Fix some broken links * Remove extra space * Update filename * Fix some links in localization folders * Fix link * Update frontmatters * Work on patterns index page * Work on index page * Fixes according PR comments. Mainly Readme edits. * fix frontmatter * add missing png * Update pattern index.md * Add index.md for Chinese translation * update image paths * update circuit breaker image paths * Update image paths for localizations * add generated puml * Add missing image * Update img file extensions * Update the rest of the EN and ZH patterns to conform with the new website Co-authored-by: Victor Zalevskii <zvictormail@gmail.com>
1.8 KiB
title, category, language, tags
| title | category | language | tags | ||
|---|---|---|---|---|---|
| Type-Object | Behavioral | en |
|
Intent
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
Explanation
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.
Class diagram
Applicability
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.