With the introduction of CoreSection, we've now got three different objects based around a list of Samples: Site, Suite, and CoreSection. None of them actually implement a List interface. It may be time to bring some order to this chaos.
Consider introducing an interface called (say) Samples, which extends List\<Sample> and is implemented by Site, Suite, and CoreSection. List methods (25 by my count) can just call through to the contained List. A bit of a faff to implement three times over – should probably inherit from an abstract class that implements Samples – can't define them as default methods in the interface since we can't have an instance variable in the interface to store the list. In addition to the inherited List\<Sample> methods, Samples can contain useful list-of-Sample-specific methods. Fisher statistics, GC fitting, measurement type (because it should be the same throughout!), min/max depth… probably quite a few things currently sitting in Suite or Site, and many of them can be defined in the abstract class.
On reflection: I don't know that implementing the List interface is the way to go. The required boilerplate feels like a code smell. Is there any major downside to just defining a Samples interface with whatever multi-sample methods we need plus a getSamples() method returning a List\<Samples>? A little bit un-demeterish maybe but feels cleaner overall, and is a smoother transition from the current implementation. After all, Suite, Site, and CoreSection all have (or will have) getSamples() methods already.
With the introduction of CoreSection, we've now got three different objects based around a list of Samples: Site, Suite, and CoreSection. None of them actually implement a List interface. It may be time to bring some order to this chaos.
Consider introducing an interface called (say) Samples, which extends List\<Sample> and is implemented by Site, Suite, and CoreSection. List methods (25 by my count) can just call through to the contained List. A bit of a faff to implement three times over – should probably inherit from an abstract class that implements Samples – can't define them as default methods in the interface since we can't have an instance variable in the interface to store the list. In addition to the inherited List\<Sample> methods, Samples can contain useful list-of-Sample-specific methods. Fisher statistics, GC fitting, measurement type (because it should be the same throughout!), min/max depth… probably quite a few things currently sitting in Suite or Site, and many of them can be defined in the abstract class.
On reflection: I don't know that implementing the List interface is the way to go. The required boilerplate feels like a code smell. Is there any major downside to just defining a Samples interface with whatever multi-sample methods we need plus a getSamples() method returning a List\<Samples>? A little bit un-demeterish maybe but feels cleaner overall, and is a smoother transition from the current implementation. After all, Suite, Site, and CoreSection all have (or will have) getSamples() methods already.