Is using the Factory or Builder pattern nessesary?

Started by
21 comments, last by LorenzoGatti 8 years ago

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?

1. No it is not mandatory but would help.

Patterns in general are not mandatory and would be better if you alternate them to your own solution rather than using them as is.

Because most of the time, the don't fit 100% as-is.

2. Yes. A big deal of a good software is where your instances are coming from.

In your own example, a factory would be an over-design because you are dealing with a simple model and not a service nor a proxy.

Generally a factory is needed when:

A) You have too many concrete implementatino so you want to give something easier to deal with.

B) You want to control the instantiation of an object. (How it is created).

C) Complex objects which you need special cases to deal with.

So for your solution I'd just create a function at the most part. I don't know your other part of the software, so generally look for what I mentioned above.

Advertisement

If I understand correctly, you are complaining about Client having a list of documents which is not used in the case of domestic clients. If domestic clients having documents is something that doesn't make any sense, then I see your point. I would need to know more about the exact context in which this code is being written to make a judgement, but it seems to me it's more like "we don't currently have a use for the documents in the case of a domestic client", but that sounds like something that may change tomorrow.

It sounds like a boneheaded "optimization": crippling domestic clients by removing their container of documents allows the grand architects to maintain a simple implementation in addition to the general one that's known to be needed for international clients.

What's really different is what to do with different document types and clients having different combinations of documents, which might involve several document classes (not too likely, but possible in principle if documents have nothing in common) but not different client types (what documents they have is a detail of their state, and likely a mutable one: constraining clients with a class that can have no documents is obviously wrong).

Omae Wa Mou Shindeiru

Yeah, that ^^ :D

Patterns should never be a play-book for writing code. Patterns are, well, patterns in code that just so happen to have been repeatedly reinvented, at which point people recognised the pattern and assigned a name to them to make discussion easier. You should look at lists of patterns more like a traveller's dictionary, and less like a cookbook.

A software engineer should strive to be comparable to a chef who writes cookbooks -- not a machine that only knows how to follow them.

Well put! :D

So, if I don't want to, I shouldn't use the factory/builder pattern "just cause"? Correct? As stated above there should be a legitimate reason to implement it.

Many thanks for the reassurance.

In your humble opinion, is doing this:


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

Okay? Given that it accomplishes what I need, and I fully understand what it does.

It's not a matter of "wanting": without the proper context of many similar classes and of client code that is content with some abstract interface but somehow doesn't care about some details of their creations, writing a meaningful factory is impossible because you don't know.what the factory can abstract and hide compared to directly calling constructors.

(It goes without saying that in your example you have either only one class, ("International", which should be just "Client"), or completely unrelated ones without a real common interface, and there's no apparent way to create your objects without passing all data up front)

Omae Wa Mou Shindeiru

This topic is closed to new replies.

Advertisement