Coding Pattern for use instance member [closed]

Question

Suppose I have a class called CommandLineOperation. This class accesses API resources. Thus I have defined one instance member of type APIAccessor.

class CommandLineOperation {
    APIAccessor apiAccessor;
    void create() {
        apiAccessor = new APIAccessor(email,password);
        //do work for creation
    }
    void update() {
        apiAccessor = new APIAccessor(email,password);
        //do work for update
    }
}

class APIAccessor {
    String email;
    String password;
    APIAccessor(email,password) {
        this.email = email;
        this.password = password;
    }
}

The operations in CommandLine, are infrequent, is it a better approach to instantiate APIAccessor under every operations or create once using constructor of CommandLineOperation class. e.g.

CommandLineOperation(String email,String password) {
    this.apiAccessor = new APIAccessor(email,password);
}

Please let me know or suggest good coding design pattern. Or suggest any reference book so that I can improve my coding standard based on the analysis. Thanks in advance.

Answer 1

Answer is: it depends - on your context/requirements.

Advantages of creating an ApiAccessor once when creating a CommandLineOperation instance:

• you can create immutable objects then (by making that field final). That has various advantages - as you always know that this field is initialized (ideally, you might even want to validate that the ApiAccessor is actually valid and not containing wrong information)
• your other methods can focus on their direct responsibility - instead of worrying if that field has already been initialized
• as a consequence, unit testing is also easier - in case you need mocking, you only have to provide an ApiAccessor object once - instead of dealing with it each time you invoke one of the "real" methods of CommandLineOperation

Disadvantages:

• you can't "switch" the ApiAccessor for a given CommandLineOperation object
• in case you have millions and millions of these objects hanging around without being your, you waste some memory

But when you think about it: those disadvantages aren't much of an issue in the real world anyway.

Regarding the comments that the required credentials come from parsing files: that boils down to dependency injection!

Meaning: the CommandLineOperation class should not contain code to construct an ApiAccessor instance. That object should either be injected (via a dependency injection framework) - or provided via the constructor for example.