Let's say we have an analytic application (AppX) that allows the import and export of analytic files. We want to build some functionality into it to allow those files to be shared in an enterprise collaboration platform, however we use 2 different platforms, say Jive and Workplace.
While this is somewhat subjective, I'm looking to see if this model matches the convention for OO concepts?
1 - We have in interface CollaborationService defining methods that must be implemented in order to fulfill the full functionality.
2 - We have an abstract class DefaultCollaborationService implements CollaborationService that has some default implementation for some of the operations.
3 - We have a class WorkplaceCollaborationService extends DefaultCollaborationService and a class JiveCollaborationService extends DefaultCollaborationService that each have their own methods, which override those in the Default abstract class.
Or..
Is this better:
2 - abstract class DefaultCollaborationService - note, no link to the interface, so we don't have to implement everything
3 - class WorkplaceCollaborationService implements CollaborationService extends DefaultCollaborationService and class JiveCollaborationService implements CollaborationService extends DefaultCollaborationService
Or..
Is all of that not right, and you can advise a better method?
This is on the edge of "opinionated", so lets focus on facts:
Option 1 (using the interface on your abstract base) class should be preferred: the whole purpose of this class is to provide implementation for some of the methods of your interface. You see, when the interface changes, you probably want that the compiler tells you that you have to look into the implementation in your base class.
And keep in mind: you don't have to implement all methods - you can still leave those abstract that can't be implemented on this level.
Beyond that, your approach seems reasonable.