I am trying to encapsulate a Physics Engine (to support fracturing).
I want to know whether my below semantic is bad smell.
[Approach 1] My current design is :-
Programmer can create 2 types of Physics body : Parent, and Child
Parent is a body that can't have any shape or mass, but can contain some Parents or Children.
Child is a body that can't contain any other physic body, it always has shape and mass.
For the implementation :-
Both Parent and Child are inherite d from a class PhysicBody.
PhysicBody has some fields. One of them is mass, as an example.
Mass of a Parent is the total mass of every children.
Mass of a Child is the mass of itself.
Suppose that I want to simulate a jar that can explode into several pieces. I will :-
Create a Parent named x
Create many Child that denote fractures e.g. y1 y2 y3.
x.add(y1); x.add(y2); x.add(y3);
The steps are very similar to BulletPhysics's.
So far, it works well in all demos. Coding is easy and fun.
Today, I want to implement a tank like this :-
(a crappy tank shown in top-view)
Here is how it can be created :-
x is a Child : x = createCube();
y is a Child : y = createSphere();
z is a Child : z = createCylinder();
p is a Parent : p.add(x); p.add(y); p.add(z);
It works, but I think it is counter-intuitive :-
The tank is p which is an relatively (too) abstract physic body.
[Approach 2] Thus, I plan to make it like :-
x = createCube()
y = createSphere(); x.add(y);
z = createCylinder(); z.add(y);
The new sematic demand me to re-design Physics class, e.g. to be :-
Old parent and child will become the same type - all of them can now has shape, mass and contain children!
I think it would work well, but I am still too scared.
Question
Is it make sense to allow non-empty physic body to contain some other physic bodies?
Are Approach 1 and Approach 2 bad designs?
Can Approach 2 be considered an improvement?
Did you spot something (potentially) wrong? How to improve it?
Am I a problem myself?
↧