As it stands, the Pilot Panel has too many responsibilities to be implemented as just a single class. In order to break up the responsibilities of the class, and work towards making the class more testable, it has been broken into three separate classes:
SliderController: responsible for updating and setting motion power values and light speed values based on panel sliders.
ProfileController: responsible for updating and loading motion power values from the motion power profiles based on button clicks.
EmergencyStopController: responsible for watching the emergency stop button and is used by the main view controller.
The largest challenge in separating the PilotPanel from the ThrusterPowerSlidersViewController was figuring out how to keep two separate view consistent for eventpublisher events. Further, I wanted this change to work for N number of clients, seeing as now the SliderController, ProfileController and ThrusterPowerSlidersViewController are capable of updating the MotionPowerValue object now.
The solution was to makeMotionPowerValue an interface and subtype the interface for each source that required reading and writing to the event sequence. This is a loose contract which assumes no other applications on the network will use this specialized class. When a reader/writer of MotionPowerValue objects reads a stream, it will be able to tell which objects it did not create by checking the subclass of the instance.
While creating these subtypes I noticed that it is possible to create static nested classes in a Kotlin interface. I took this a step further and defined all of the speed values as nested classes in the SpeedValue interface. I think this change actually added a lot of readability to the code and it also eliminated having a bunch of separate files for such tiny classes. This did however replace the name LightSpeedValue with SpeedValue.Light which is nowhere near as cool... shall hum and haw on this change.
Update I decided against the subtype solution as it added a lot of complexity to the code. A simple solution is to use a timeout based approach where if the source is outputing, messages from the eventpublisher are blocked, and vice-versa. Good to review
As it stands, the Pilot Panel has too many responsibilities to be implemented as just a single class. In order to break up the responsibilities of the class, and work towards making the class more testable, it has been broken into three separate classes:
SliderController: responsible for updating and setting motion power values and light speed values based on panel sliders.ProfileController: responsible for updating and loading motion power values from the motion power profiles based on button clicks.EmergencyStopController: responsible for watching the emergency stop button and is used by the main view controller.The largest challenge in separating the
PilotPanelfrom theThrusterPowerSlidersViewControllerwas figuring out how to keep two separate view consistent for eventpublisher events. Further, I wanted this change to work forNnumber of clients, seeing as now theSliderController,ProfileControllerandThrusterPowerSlidersViewControllerare capable of updating theMotionPowerValueobject now.The solution was to makeMotionPowerValuean interface and subtype the interface for each source that required reading and writing to the event sequence. This is a loose contract which assumes no other applications on the network will use this specialized class. When a reader/writer ofMotionPowerValueobjects reads a stream, it will be able to tell which objects it did not create by checking the subclass of the instance.While creating these subtypes I noticed that it is possible to create static nested classes in a Kotlin interface. I took this a step further and defined all of the speed values as nested classes in theSpeedValueinterface. I think this change actually added a lot of readability to the code and it also eliminated having a bunch of separate files for such tiny classes. This did however replace the nameLightSpeedValuewithSpeedValue.Lightwhich is nowhere near as cool... shall hum and haw on this change.Update I decided against the subtype solution as it added a lot of complexity to the code. A simple solution is to use a timeout based approach where if the source is outputing, messages from the eventpublisher are blocked, and vice-versa. Good to review