Jump to content

  • Log In with Google      Sign In   
  • Create Account

We're offering banner ads on our site from just $5!

1. Details HERE. 2. GDNet+ Subscriptions HERE. 3. Ad upload HERE.


Don't forget to read Tuesday's email newsletter for your chance to win a free copy of Construct 2!


#ActualHodgman

Posted 02 March 2013 - 09:06 PM

My first question is circular dependencies. Are they bad ? People say they are a flaw in the design.

Yes, they're a code-smell. They often indicate that the code isn't very flexible.

Is it wrong to think that every component has to have a two-way connection to it's owner/child ?

Yes, such two-way parent/child connections should be quite rare.

MaterialClass - Has an instance of the renderer component class and uses this to get .e.g the rendering device to create shader resources...
and at the same time the renderer has to work with the material class.

If you apply the SRP to the renderer so that it's broken into several sub-classes, it might be easier to break this down. e.g. move all the shader code into a Shader Pool that is owned by the Renderer.
e.g. Renderer has a Shader Pool. Renderer uses Materials. Material uses Shader Pool.
(has a == member variable, uses == passed as an argument to a function)
All these relationships are one-way (top down) - classes are only aware of the ones below themselves.
  Renderer
      | \
      |  \uses
      |   \
  owns|   Material
      |   /
      |  /uses
      | /
ShaderPool
[edit] oh F^&#$*^ #$&$#( balls. The stupid code editor threw away all the text after the code box! [/edit]

#1Hodgman

Posted 02 March 2013 - 08:54 PM

My first question is circular dependencies. Are they bad ? People say they are a flaw in the design.

Yes, they're a code-smell. They often indicate that the code isn't very flexible.

Is it wrong to think that every component has to have a two-way connection to it's owner/child ?

Yes, such two-way parent/child connections should be quite rare.

MaterialClass - Has an instance of the renderer component class and uses this to get .e.g the rendering device to create shader resources...
and at the same time the renderer has to work with the material class.

If you apply the SRP to the renderer so that it's broken into several sub-classes, it might be easier to break this down. e.g. move all the shader code into a Shader Pool that is owned by the Renderer.

e.g. Renderer has a Shader Pool. Renderer uses Materials. Material uses Shader Pool.

(has a == member variable, uses == passed as an argument to a function)

  Renderer
      | \
      |  \uses
      |   \
  owns|   Material
      |   /
      |  /uses
      | /
ShaderPool

PARTNERS