❔ Is my Inherittance Scheme dumb?
Base class BuildingObjectBase defines a tile that is used in a level editor. It has data to describe rules of rendering layer, tooltip strings, ID for files, sprite, etc.
TileAssembly : BuildingObjectBase describes a single object that spans a rectangular array of tiles. TileAssembly needs ALL of BuildingObjectBase’s fields and properties. The main difference is TileAssembly has an underlying dictionary/ints/int[,] field to populate arrays of tile sprites.
Almost every property of TileAssembly is an override, where BuildingObjectBase has a virtual property returning default output. (eg TotalCells() {return 1;}).
Everything has been going great, but now if I want to make a class that has a separate sprite for a certain trigger (eg hitting switch changes tile sprite), it either needs to be a TileAssembly (if I want any of them to have multiple tiles), or I need to add a field to BuildingObjectBase (which most instances of the class won’t use).
Q: Is there a smarter way?
4 Replies
So why not create another class that inherits TileAssembly?
Or enhance the TileAssembly to make it changeable based on an event
1) I could. But I’d like to know if I should refactor early before I get deeper.
2) Instances of these classes are basically immutable. They correspond to asset files that should never change.
My main conern: I’m not sure if inheritance is the right tool b/c I could represent every BuildingObjectBase as a TileAssembly. Which makes me wonder how necessary the separate class is.
I may be reading into wrong but it sounds like
TileAssembly should have a BuildingObjectBase rather the be one. Then your new sprite switching tile would inherit from Building ObjectBase and TileAssembly would happily use thatWas this issue resolved? If so, run
/close - otherwise I will mark this as stale and this post will be archived until there is new activity.