caloriestracker | biometric data . | Database library

As you rightly pointed out, inheritance does not make a case here because there is not a IS-A relationship between trackers. Composition can be used if one tracker needs other trackers to calculate its value. As per the Single Responsibility principle of SOLID design principles, one class or method should do one particular thing. Applying this principle in this case, it makes sense to create different classes or interfaces for each kind of tracker. It may be good to have interfaces for each kind of tracker and the corresponding implementation classes. So for example, interfaces such as IDistanceTracker, IElevationTracker, IStepTracker and so on can be created along with their implementations such as DistanceTrackerImpl, ElevationTrackerImpl and so on.

By coding against interfaces, we are keeping the code flexible to supply a different implementation of the same tracker in the future. For example in the client code we can use interfaces and in the service code, we can potentially use multiple implementations of the same interface and do things like use one kind of implementation for specific set of clients and use another for the rest. The client code doesn't have to change in this case. And sometimes, let's say we want to upgrade certain clients to use a newer version of the implementation - hypothetically speaking - a wearable device 1.0 hardware is capable of tracking only steps and let's say we display the consumed calories based on the steps then the Calorie Tracker can calculate the calories based on the steps. And let's say in the newer wearable hardware 2.0, the hardware is capable of tracking elevation as well, in that the Calorie Tracker for the newer hardware will need to be modified to use the elevation data to calculate calories. But the old devices should still use previous calorie tracker which uses only steps and not the elevation. This results in the need to have multiple implementations of the same tracker and hence it is better to code against the interface by having a single interface ICalorieTracker and multiple implementations of the same.

Thus, IMHO, having individual interfaces and implementations for each tracker without any inheritance relationship might be a good idea. If there is a tracker that satisfies the IS-A relationship then one tracker interface can extend the other. For example, IAdvancedCalorieTracker extends ICalorieTracker. Here the subtype satisfies the IS-A relationship, so it would be okay to use inheritance.