De-couple related objects

[mlewis-everley]

So when I was going through the codebase there were a lot of related objects that would be quite cool to allow hot swapping. Some examples are:

1. Roof Hatch
2. Roof tiles
3. Floor tiles
4. Blast door

There are also a lot of properties to set on Bunker that are then duplicated onto the relevant objects.For example:

bunker.floor_tile_width

If you assigned relevant related objects on instantiation then relied on some form of basic dependency injection to swap them out, you could dump a lot of these properties and have a much cleaner API.

From the example above, if you made floor_tile a Tile object, then you could call something like this to directly change the properties on floor tile:

bunker.floor_tile.width

[medicationforall]

right now we have two way of swapping items out. one is by inserting method callbacks the the other is by setting the factory class to be used.

I think swapping the factory class gives more flexibility. but it should probably be made consistent replacing the method callbacks.

Which I think would be pretty simple, the method callbacks could be recreated with just a generic wrapper class.

[medicationforall]

outline

• each swappable component should inherit off of a base class.
  • When the swappable component is initialized it should be given a reference to the parent instance
  • the swappable base class should have:
  • init method - initializes parameters, if the parent is passed in can initialize parameters off of that.
  • make method lifecycle - reponsible for making sub components
  • build method lifycycle - responsible for combining subcomponents into one shape.

What may be needed is for the capability to pass in a custom method to initialize the swappable component. The point is we need a way to define the relationship of a bunker to a roof via setting parameters. But how a detailed roof is setup shouldn't necessarily require the same parameters as a flatroof.

And if we make it modular enough a flatroof can be used for more things than just the child of a bunker. It can be the child of buildingX as long as the relationship between the child and the parent can be set.

What I'm suggesting would be backwards combability breaking, but it should give a foundation for future swappable components.