Jump to content

  • Log In with Google      Sign In   
  • Create Account

#ActualHodgman

Posted 21 November 2012 - 08:42 PM


Now my last sentence sounds all OO right? ... and it is ... but I got to that design from a data first process, that ENDS in OO, but doesn't start there.

There is a distinction to be made between "Data Oriented" and "Data Driven"; I think your post describes the latter, which is basically a facet of good OOD.

A better description of DOD than the one I gave earlier might be "think about the data first, then the code later".
Under that description, Xai sounds like he's focussing on (or orienting his thoughts around) the data as a primary concern.

e.g. with an OOD renderer, when setting material values, you might think "ok, I'll need a pointer to an IMaterialDataSource interface... what methods will it have?".
With a DOD renderer, you might instead consider that if the signature to your function was void SetMaterialData(const byte* allTheDataYouNeed, int size), then what would that buffer of bytes contain, and how would be be laid out?

Often, if you design around the data first, and then slap an OO layer on top of the data, then it becomes very data-driven as a side effect.

e.g. I've got an OOP interface for reflecting on shader programs, such as looking up a techqnique by name:
struct ShaderPack : NonCopyable, NoCreate
{
	int FindTechniqueByIndex( const char* name ) const;
	int GetTechniqueBlah( int index ) const;
};
But long before I wrote that interface and what methods it could have, I first sat down and designed a bunch of classes with no methods and just data. There's also other classes that can consume this data besides the above interface.
template<class T> struct ArrayOffset  { s32 offset; /*operators to act like a T[]    */ };
                  struct StringOffset { s32 offset; /*operators to act like a char*  */ };

struct Technique
{
	u32 blah ... ;
};
struct ShaderPackBlob
{
	u32                         numTechniques;
	ArrayOffset<Technique>      techniques;
	ArrayOffset<StringOffset>   techniqueNames;
};

#2Hodgman

Posted 21 November 2012 - 08:16 PM


Now my last sentence sounds all OO right? ... and it is ... but I got to that design from a data first process, that ENDS in OO, but doesn't start there.

There is a distinction to be made between "Data Oriented" and "Data Driven"; I think your post describes the latter, which is basically a facet of good OOD.

A better description of DOD than the one I gave earlier might be "think about the data first, then the code later".
Under that description, Xai sounds like he's focussing on (or orienting his thoughts around) the data as a primary concern.

e.g. with an OOD renderer, when setting material values, you might think "ok, I'll need a pointer to an IMaterialDataSource interface... what methods will it have?".
With a DOD renderer, you might instead consider that if the signature to your function was void SetMaterialData(const byte* allTheDataYouNeed, int size), then what would that buffer of bytes contain, and how would be be laid out?

Often, if you design around the data first, and then slap an OO layer on top of the data, then it becomes very data-driven as a side effect.

e.g. I've got an OOP interface for reflecting on shader programs, such as looking up a techqnique by name:
struct ShaderPack : NonCopyable, NoCreate
{
	int FindTechniqueByIndex( const char* name ) const;
	int GetTechniqueBlah( int index ) const;
};
But long before I wrote that interface and what methods it could have, I first sat down and designed a bunch of classes with no methods and just data
template<class T> struct ArrayOffset  { s32 offset; /*operators to act like a T[]    */ };
                  struct StringOffset { s32 offset; /*operators to act like a char*  */ };

struct Technique
{
	u32 blah ... ;
};
struct ShaderPackBlob
{
	u32                         numTechniques;
	ArrayOffset<Technique>      techniques;
	ArrayOffset<StringOffset>   techniqueNames;
};

#1Hodgman

Posted 21 November 2012 - 08:15 PM


Now my last sentence sounds all OO right? ... and it is ... but I got to that design from a data first process, that ENDS in OO, but doesn't start there.

There is a distinction to be made between "Data Oriented" and "Data Driven"; I think your post describes the latter, which is basically a facet of good OOD.

A better description of DOD than the one I gave earlier might be "think about the data first, then the code later".
Under that description, Xai sounds like he's focussing on (or orienting his thoughts around) the data as a primary concern.

e.g. with an OOD renderer, when setting material values, you might think "ok, I'll need a pointer to an IMaterialDataSource interface... what methods will it have?".
With a DOD renderer, you might instead consider that if the signature to your function was void SetMaterialData(const byte* allTheDataYouNeed, int size), then what would that buffer of bytes contain, and how would be be laid out?

Often, if you design around the data first, and then slap an OO layer on top of the data, then it becomes very data-driven as a side effect.

e.g. I've got an OOP interface for reflecting on shader programs, such as looking up a techqnique by name:
struct ShaderPack : NonCopyable, NoCreate
{
	int TechniqueIndex( const char* name ) const;
};
But long before I wrote that interface and what methods it could have, I first sat down and designed a bunch of classes with no methods and just data
template<class T> struct ArrayOffset  { s32 offset; /*operators to act like a T[]    */ };
                  struct StringOffset { s32 offset; /*operators to act like a char*  */ };

struct Technique
{
	u32 blah ... ;
};
struct ShaderPackBlob
{
	u32                         numTechniques;
	ArrayOffset<Technique>      techniques;
	ArrayOffset<StringOffset>   techniqueNames;
};

PARTNERS