I'm looking to see if there is a design pattern that can solve the following problem. The example is fairly specific but the goal is a public + internal API. I need specific information for my underlying library but I want to present the API generically. If my question is vague or terrible I'll try and spruce it up with your comments.
As an example, let's say I am creating a public API and I want it to be agnostic to the implementation. Continuing the example, I am creating a job handler API using the Quartz (can be any library) library in the current implementation.
I want people to be able to type:
Job job = jobManager.getJob("my.job.name"); String otherInformation = job.getOtherInformation(); job.setSchedule(new IntervalSchedule(repeatInterval, intervalUnit)); job.setSchedule(new CronSchedule(cronExpression));
The Quartz API has builders for schedules (used in Trigger):
CronScheduleBuilder.cronSchedule(cronExpression); CalendarIntervalBuilder.calendarIntervalSchedule() .withInterval(repeatInterval, DateBuilder.IntervalUnit.DAY);
In my current example I would have a base interface or class Schedule. With this structure how would it be possible to get the specific information I need for the schedule builders without revealing an implementation specific object in my interface while keeping it extensible. My goal is to prevent implementation classes from leaking in to the public API. If in the future Quartz falls out of favor, the public API doesn't need to change and deprecate the Quartz specific classes. What design pattern or code reorganization am I missing?