HeroEngine Forums
Welcome, Guest. Please login or Register for HeroCloud Account.

Author Topic: [Resolved] inheritance vs glomming  (Read 1901 times)

FI-ScottZ

  • General Accounts
  • *
  • Posts: 1407
    • View Profile
    • Forever Interactive, Inc.
[Resolved] inheritance vs glomming
« on: Dec 07, 10, 08:22:55 AM »

I am looking to add methods to a node, specifically a spec prototype.  I am used to extending classes via inheritance, but this glomming idea is new.  I can see how I can either add things in a child class, or glom a class onto the prototype and either should work, I think.

Can you recommend any particular reasons to choose one vs the other?  The only one I can think of is that glomming is done onto individual nodes rather than a whole class, but since this is a prototype, it doesn't matter.

Thanks.
« Last Edit: Nov 02, 12, 08:29:12 PM by HE-Cooper »
Logged
Scott Zarnke
Lead Programmer, Visions of Zosimos
CTO, Forever Interactive, Inc.

HE-JAY

  • HeroEngine
  • *****
  • Posts: 122
    • View Profile
Re: inheritance vs glomming
« Reply #1 on: Dec 07, 10, 12:00:06 PM »

Two of the most compelling reason for choosing to GLOM a class onto a node rather than explicitly extend its functionality via a child class is the fact that GLOMming can be done dynamically at run-time and that GLOMMing allows a node to effectively 'inherit' from multiple classes without resorting to explicitly defining complex multiply-inherited child classes ahead of time.  This allows a node to gain additional functionality in response to some arbitrary logic (on the fly), and it also allows you to 'tack on' multiple sets of additional functionality to a node that it was not otherwise designed to handle (all without resorting to modifying the DOM or adding additional scripts).  GLOMming is - in essence - an expression of the 'Decorator' pattern of software design (http://en.wikipedia.org/wiki/Decorator_pattern).

The purpose of the Spec System is to both provide a means of storing immutable object definitions as well as instantiating objects from these definitions.  In order to provide robustness and extensibility, these 'spec definitions' may be decorated by additional classes - defined by you - to extend the definition.  This allows you to - for example - create a basic 'Item' spec, then extend it by glomming on additional functionality like 'StackableItemDecorator' or 'ConsumableItemDecorator' (to create a particular definition that describes an Item that is both Consumable and Stackable).  If you have a list of twenty decorator classes you'd like to use in creating complex composite spec definitions, creating 'Consumable Stackable Potions' or 'Throwable Stackable Knives' is as simple as glomming on the appropriate decorator class.  It would be impractical to use simple inheritance to accomplish this goal, as you would be unable to use a single base class for instantiating Item objects and would instead be forced to create explicit multiply-inherited child classes for each combination you'd like to use.

For a more complete description of how to use the spec system to accomplish this, please see both http://wiki.heroengine.com/wiki/Spec_System_-_Advanced_Usage#Spec_Decorators as well as http://wiki.heroengine.com/wiki/How_to_make_an_Inventory_System.
Logged

FI-ScottZ

  • General Accounts
  • *
  • Posts: 1407
    • View Profile
    • Forever Interactive, Inc.
Re: inheritance vs glomming
« Reply #2 on: Dec 07, 10, 12:14:48 PM »

Cool, thanks for that.  That definitely clears some things up.  For what we are doing, it is not as complicated as that, more like an example I read now that was given of a child class of itemSpec called weaponSpec so that may be where we go.  But this is good food for thought in other areas where we want to combine different combinations of types.
Logged
Scott Zarnke
Lead Programmer, Visions of Zosimos
CTO, Forever Interactive, Inc.