Apel is a library that brings particle animations to the table with flexible behaviour and a clean developer interface. It promises also lots of predefined shapes & paths to help the developer on their particle scene
Other
2
stars
1
forks
source link
ParticleObject construction should not be multi-phased #35
Right now, constructing most ParticleObject subclasses requires calling a constructor and then setting additional properties. This allows objects to be in inconsistent states during construction. Before releasing an official 1.0 release, the constructor plus setter approach needs to unify into making use of a builder pattern.
One reason for this is to allow defining rotation, offset, or both when building an object. Right now, the telescoping constructor pattern makes this difficult because both rotation and offset are modeled as Vector3f objects, so they're indistinguishable in constructor function signatures. A builder pattern will fix this by naming each parameter as its provided, such as .rotation(rValue).offset(oValue).build(). This should also help with objects that take lists or vararg arrays of parameters, since builders can accumulate multiple values for the same field.
Objects also have several properties, which makes constructor methods difficult to read. IDEs can help by choosing to show parameter names inline, but that doesn't help on GitHub or in a command line environment.
Builders that use super classes can be difficult to get right, since builder methods often declare a return type based on the class in which they reside. This may complicate the approach a little, but should be manageable.
Right now, constructing most ParticleObject subclasses requires calling a constructor and then setting additional properties. This allows objects to be in inconsistent states during construction. Before releasing an official 1.0 release, the constructor plus setter approach needs to unify into making use of a builder pattern.
One reason for this is to allow defining rotation, offset, or both when building an object. Right now, the telescoping constructor pattern makes this difficult because both rotation and offset are modeled as
Vector3fobjects, so they're indistinguishable in constructor function signatures. A builder pattern will fix this by naming each parameter as its provided, such as.rotation(rValue).offset(oValue).build(). This should also help with objects that take lists or vararg arrays of parameters, since builders can accumulate multiple values for the same field.Objects also have several properties, which makes constructor methods difficult to read. IDEs can help by choosing to show parameter names inline, but that doesn't help on GitHub or in a command line environment.
Builders that use super classes can be difficult to get right, since builder methods often declare a return type based on the class in which they reside. This may complicate the approach a little, but should be manageable.