-
Notifications
You must be signed in to change notification settings - Fork 0
Thoughts on fish behavior architecture
Subclass sandbox pattern: Define behavior in a subclass using a set of operations provided by its base class.
A base class defines an abstract sandbox method and several provided operations. Marking them protected makes it clear that they are for use by derived classes. Each derived sandboxed subclass implements the sandbox method using the provided operations.
Fish base class will define protected methods that every fish subclass would have access to and use. It would also define two abstract sandbox methods called UpdateFish and AffectEnvironment, which each fish subclass would implement based on its individual variables.
- Reduces code duplication by sharing code among similar subclasses
- Minimizes coupling between subclasses and the rest of the game. Coupling is constrained to the base class.
- Results in shallow but wide inheritance trees.
- Most behavior code will be neatly contained within the respective subclass.
- Inheritance in general is highly coupled and can become brittle if it spiderwebs out (brittle base class problem)
- As each subclass depends on using methods from the base class, the base class can become monolithic and unmaintainable as it accretes more and more code.
- The base class will become coupled to every system ANY subclass needs to communicate with.
If this pattern is turning the base class into a giant bowl of code stew, consider pulling some of the provided operations out into separate classes that the base class can dole out responsibility to. The component pattern can help here.
other ideas/methods?