-1

I'm looking to have a method return a class Job, that has different methods based on the job type.
For example, the job type could be BackupJob or RunCommandJob. They don't share methods, but it's needed to get them from a single method, getJob().

Right now I have a normal class job that has the methods return null, without a constructor, since I construct the other classes (BackupJob or RunCommandJob for example) in the getJob() method.

What is the best way to get the different job classes while returning a single class?
example code below.
Job class:

public ArrayList<String> getCommands() { return null; }

public String getBackupGUID() { return null; }

public void setCommands(String... commands) { return; }

public void setBackupGUID(String backupGUID) { return; }
//Etc...

getJob method

public Job getJob() { 
if (JobType == RunCommandsJob) return new RunCommandsJob(...);
else if (JobType == BackupJob) return new BackupJob(...);
//and so on for all the other types

Example of the RunCommandsJob class, but it's the same concept with all the different types, but with unique method names.

public ArrayList<String> getCommands() { /* method */ }
public void setCommands(String... commands) {/* method */ }

Edit: A little bit more context.
I have a scheduler class, that can contain multiple Tasks. Each Task has it's own Job, that could be different things (for example, a RunCommandsJob). Job itself isn't used, but In the other classes I extend Job so that I can return a "Job" that is in reality a "RunCommandsJob", which has logic to edit it in the database/API.
It's complicated, but that's what I have to work with.

filliravaz
  • 3
  • 2
  • 1
    "*They don't share methods, but it's needed to get them from a single method, getJob().*" - I would highly advice to not use inheritance to realize this. Taking this approach sounds like a cascase of `if (... instanceof ...) { ... } else if (... instanceof ...) { ... }` down the road (i.e. tight coupling). I bet there is a way to give those classes at least one common method that could then be encapsulated in either an interface or parent class. – Turing85 Sep 04 '22 at 13:55
  • @Turing85 As much as I'd like to use just a single pair of set and get methods, it's not possible due to the fact that they can return strings, enums, or integers. Unless there is a way to return different types without overloading. – filliravaz Sep 04 '22 at 14:39
  • Where does `JobType` come from? Is it a member of the class, pass at construction time? – Andy Turner Sep 04 '22 at 15:25
  • Please can you add code which shows how the class `job` relates to `Job`, and how that relates to `RunCommandsJob` etc? – Andy Turner Sep 04 '22 at 15:28
  • 1
    So a `Job` gives you a `Job`? That doesn't seem like a particularly logical design. Sounds like you have a `JobFactory` that gives you instances of `Job`. – Andy Turner Sep 04 '22 at 15:40

1 Answers1

2

You can define Job as an interface or abstract class. So you don't have to write default implementations and concrete classes must implement the methods.

Mert Ülkgün
  • 124
  • 1
  • 7
  • I thought about that, but what would I do about all the other methods? Return null? throw an exception? – filliravaz Sep 04 '22 at 15:17
  • 1
    implement a default behavior or throw NotImplementedException. – ben Sep 04 '22 at 15:46
  • @filliravaz Or define more interfaces for your concrete classes to implement, if those other methods are not really part of what being a “Job” means. Tip: Before worrying about your Java code, get *very* clear on the semantics of the problem domain. Don’t start coding until you have clearly defined business terms with relationships fully explained. – Basil Bourque Sep 04 '22 at 16:54