Let's assume I have the following class:

public abstract class Client {
    
    private String clientID;
    private String clientFirstName;
    private String clientLastName;
    
    public Client(String ID, String firstname, String lastname)
    {
        this.clientID = ID;
        this.clientFirstName = firstname;
        this.clientLastName  = lastname;
        
    }
}

and the following Subclasses:

public class Domestic extends Client {
    public Domestic(String ID, String firstname, String lastname) {
        super(ID, firstname, lastname);
        
    }
}

public class International extends Client {

    private List<String> documents;
    
    public International(String ID, String firstname, String lastname, List<String> documents) {
        super(ID, firstname, lastname);
        
        this.documents = documents;
        
    }
}

Given that both subclasses have a different set of parameters, the International subclass requires a List of documents(passport, drivers license), while domestic doesn't. To me anyway, I don't believe the factory pattern is adequate because of the different constructor parameters, and the builder patter isn't necessary as all arguments are necessary, an there isn't that many of them. So is doing this okay?

Client international = new International(id, firstname, lastname, documents); 

or if there is a specific method that I need to access in the International class:

International internationalObj = new International(id, firstname, lastname, documents);

Questions:

1. Is it mandatory to use the factory or builder pattern given this situation?

2. Is there a downside to doing to doing it without the factory or builder?

There are no mandates in programming. Do whatever will make the code more clear. Using a factory or builder is an attempt at restricting what parts of the code need to know about the difference between Domestic and International.

But it looks like your design is doomed to begin with. How are the documents going to be used? Since the base class doesn't expose any virtual functions that may make use of them, you are probably going to be needing to know the type of client in some other part of the code.

I would personally add a variable to Client indicating whether it's international or domestic, and leave the list of documents empty for domestic clients.

Thanks for the reply

I left out the rest of the implementation for simplicity. There is a method that will use the documents List that I've declared.

Why do you want to do this?

Client international = new International(id, firstname, lastname, documents);

And not this?

International international = new International(id, firstname, lastname, documents); 

Yes, there are valid reasons for the first, but what is your reason? You clearly know, in-scope, that you want an International. If you plan to return that out-of-scope, then it looks to me very much like you're already using something like a factory. If you're only using it in the current (and underlying) scope, then polymorphically making it a Client is redundant.

Why do you want to do this?

Client international = new International(id, firstname, lastname, documents);

And not this?

International international = new International(id, firstname, lastname, documents); 

Yes, there are valid reasons for the first, but what is your reason? You clearly know, in-scope, that you want an International. If you plan to return that out-of-scope, then it looks to me very much like you're already using something like a factory. If you're only using it in the current (and underlying) scope, then polymorphically making it a Client is redundant.

No particular reason. I was just showing the ways I could create the International subclass. Ideally I would use the second approach, however, I was reading about the factory pattern and became confused as to when to apply them.

The only thing you're required to have in programming is the main function. Otherwise it's free game.

Domestic shouldn't be there and Client shouldn't be abstract. Literally no difference between the classes in your example. Either you got a client with just an id, or an international client with a list of ids.

Dont make classes just because. For a subclass to exist it has to either have different behavior (methods) or different state (fields) than the superclass. Otherwise it has no purpose.

Hell you could remove International/Domestic altogether, remove the ID field from Client, and just let Client have a documents list, some will only have an Id, some will have passports/driver licences.

Also you should respect standard naming schemes: ID == bad, id == good. clientID == bad, clientId == good.

Have the constructor enforce invariants, can an id be null? Can a last name be null? Can a first name be null? Strict API leads to less bugs.

Thanks for your reply.

The example I posted is a stripped down version of 2 subclasses that actually have a lot more that was is shown here. My real question, and I guess I should have been more clear about it, is it mandatory that I use the builder/factory pattern? The reason why I ask is, the examples I've seen of the factory pattern use no argument constructor to build the objects. However, what if you have subclasses that have slightly different parameters specific to the subclass, what do you do in that case? What happens if you don't have a no argument constructor?

My real problem is that I find the factory pattern confusing and hard to understand despite several attempts at trying. To me, I understand the code shown below a lot better than calling/using a factory to do it. So, my second question is, is it okay just to leave it like this (code below)?

Client international = new International(id, firstname, lastname, documents);
International international = new International(id, firstname, lastname, documents);