For this reason, I have decided to rewrite one of my uses of inheritance by composition. The piece of code in question is the BaseScreen class in XnaUtils.
Before I go any further, I need to give you a bit of context. The user interface of video games is usually composed of screens. The library provides a class called ScreenManager which is responsible for managing stacks of screens, notifying each screen when to load/unload resources such as textures...
I have created an interface named "Screen" which serves as the interface between the framework and the screens in a game. The framework also provides a few screens which can be used in simple games, namely TextScreen, MenuScreen and PressStartScreen.
These screens all share common functionality which I needed to put somewhere to avoid code duplication. In my first version, BaseScreen was an abstract class from which screen implementations inherited, overriding a few key methods to customize rendering.
Differences in ScreenBase
The changes are not very extensive. Abstract methods were replaced by fields. Instead of defining overrides, inheritors set properties using lambdas.
+ let post_drawer : ('T -> unit) ref = ref (fun _ -> ())
...
- abstract member EndDraw : 'T -> unit
- default this.EndDraw(_) = ()
-
+ member this.PostDrawer
+ with get() = !post_drawer
+ and set(d) = post_drawer := d
Differences in inheritors
A few "this" had to be replaced by "impl", the name of the variable I have used to hold the instance of ScreenBase.
type PressStartScreen(sys : Environment, fade_in, fade_out, blink) = - inherit ScreenManager.ScreenBase<unit>() + let impl = new ScreenManager.ScreenBase<_>() + let impl_screen = impl :> ScreenManager.Screen
// Task to check if a button is pressed. Sets player when that happens. let player : PlayerIndex option ref = ref None while (!player).IsNone do - do! sys.WaitUntil(fun () -> this.IsActive) + do! sys.WaitUntil(fun () -> impl.IsActive) for p in all_players do let state = GamePad.GetState(p) if state.IsConnected
Boiler-plate code had to be written to implement interfaces Screen and IDisposable, forwarding calls to "impl". As ScreenBase implements these interfaces explicitly, I had to introduce an extra variable "impl_screen" to refer to impl's implementation of Screen. Otherwise, I would have had to use casts in all forwarding code, as shown in the implementation of IDisposable.
+ interface ScreenManager.Screen with + member this.ClearScreenManager() = impl_screen.ClearScreenManager() + member this.Draw() = impl_screen.Draw() + member this.LoadContent() = + impl_screen.LoadContent()
+ + interface System.IDisposable with + member this.Dispose() = (impl :> System.IDisposable).Dispose() +
Advantages of composition and delegation over inheritance
1. Inheritors can reuse code from multiple classes (F# does not have multiple inheritance).
2. The code for ScreenBase is a bit shorter.
3. Inheritors have more control.
Advantages of inheritance over composition and delegation:
1. The "IDisposability" of ScreenBase is implicitly propagated to its inheritors.
2. No risk of errors in delegation.
3. The code for inheritors is shorter.
Conclusion
Although I believe most of the weaknesses of the approach using composition and delegation could be lifted by additions to the F# language, in its current shape, I would not dare to force users of my library to use composition.
The ideal solution is to write my library code to allow users to use the approach they prefer, which I expect would be inheritance in most cases. Providing this approach as the only one is not acceptable, as it would prevent users to reuse features from multiple classes.
