Separate Meta data from implementation data in code

Description

SourceForge ID: 877582
New Summary: Separate Meta data from implementation data in code
Request: Please assign to Tom Parker
Type: New Feature
Priority: Minor
=====
Details:

There are a lot of places in the code where an object
is used to hold both information about the object
and information about how the object affects the
character.

A prime example is the PCClass object that is used to
hold information about a CLASS. however it is also
used to hold information about the character (how
many levels the character has in that class, the
number of spells and skills it gained him etc.)

The way this is done is by clone()ing a the PCClass so
that there is a single instance unassigned to any
character, and then for each character the PCClass is
cloned so that the character can set the 'level'
property.

As PCClass has 64 fields and PObject from which it
derives has 63 fields this means taht for every time
any character inthe system gains a different class an
object with 127 fields is created unncesseraly.

If the fields and functionality that directly related to a
Character was stripped out of the PCClass and put
into a join class then the following benefits would be
gained:

1- PlayerCharacter would get smaller & simpler
2- PCClass would get smaller and simpler.
3- There would be a more obvious relationship
between character levels and classes.
4- there would be less need to use
Global.getCurrentPC() which is error prone and is a
major cause of spagetti code.
5- There would be less cloning, which means less
memory and less cpu activity.
6- There will be no need to lookup the global list of
classes keyed by the class name of the current class
as they will be the same object.

This process needs to be looked at for each object
that is cloned to see why it is being cloned and if the
cloning is necessary or if functionality should be
factored out into a new joining class.

There will be cases where cloning is needed (such as
when COPYing an object) but most of the cloning is
unneeded
Submitted:

Frugal ( frugal ) - 2004-01-15 09:26:23 EST
=====
Date: 2006-08-14 09:36:33 EDT
Sender: kariannaSourceForge.net DonorProject Admin & DonorAccepting Donations
Hide

Logged In: YES
user_id=252169

Architecture

Date: 2006-01-11 22:37:35 EST
Sender: soulcatcher
Hide

Logged In: YES
user_id=107647

the changes we are making are making this viable eventually,
but not before 5.11

Date: 2005-09-15 11:39:12 EDT
Sender: soulcatcher
Hide

Logged In: YES
user_id=107647

parts of this need to be considered.

I'll see if I can break it down into functional areas to
consider.

Date: 2005-09-15 11:14:17 EDT
Sender: kariannaSourceForge.net DonorProject Admin & DonorAccepting Donations
Hide

Logged In: YES
user_id=252169

Devon, is this still an idea we should follow, or have we
gone down a different path? - K

Date: 2004-02-03 04:13:02 EST
Sender: frugal
Hide

Logged In: YES
user_id=4807

This is indeed a scary FREQ. It will take a good coder
several days of work to get it into a state where it will
even compile cleanly, let alone work properly.

The way I would go about it is to:

  • take the PObject class and all of it's children and refactor
    them to a new package pcgen.core.implementation.
    Rename PObject to PImplementationObject.

  • Create a mathcing class heirarchy starting from an new
    class PDataObject. So there will be a new RaceDataObject
    which is the data repersentation of the current Race
    Object.

  • Refactor all of the Data functionality out of the
    PImplementationObject heirarchy and into the PDataObject
    heirarchy.

  • Refactor all of the PImplementationObject heirarchy so
    that they contain a reference to the mathcing global
    PDataObject instance. (i.e. when you create a
    RaceImplementationObject to hold the character specific
    race data you need a link to the global DataObject for that
    Race).

  • Refactor all of the code where a global object is currently
    cloned. At this point all of the information that needs to
    be Character specific should be in a new
    ImplmentationObject, so the DataObject does not need to
    be cloned.

Worked Example:

When a character gains a level of a new class the current
implementation clones the global nistance of that PCClass
and assigns the clone to the character. It does this
because there are certain variables in PCClass that are
character specific, but it also contains copies of the global
PCClass data (such as the list of class skills). Under the
new system you would break this into two classes:

PcClassDataObject:
List classSkillList
ArrayList featAutos

PcClassImplementationObject
PcClassDataObject dataObject
int level
HashMap hitPointMap

The PlayerCharacter object then contains a List of
PcClassImplementationObjects rather than a List of
PCClass objects.

I have tried to just separate the data aspects of PCClass
into a small CharacterClass object that just contains the
character specific code. Unfortunately this impacted on so
many areas of the code that it was very difficult to do
without causing wholesale changes.

I think that if this is to be done, it needs to be done in
one fell swoop...

Date: 2004-02-02 23:28:21 EST
Sender: kariannaSourceForge.net DonorProject Admin & DonorAccepting Donations
Hide

Logged In: YES
user_id=252169

Fruagl,

Is there a way we can sensibly start on this, I get the feeling
this freq is too scary for most to tackle...

Environment

None

Status

Assignee

Tom Parker

Reporter

User Submissions

Labels

None

Source Books

None

Data/LST Monkey

None

Theme

None

Theme

None

Dependent Data

None

Subtype

None

Contact Person

None

Email

None

Publisher Website

None

Permission Level

None

Epic/Theme

None

Pending User Input

None

Sprint

Priority

Minor
Configure