CODEWITHSUNDEEP
javaoopdesign-patternsattributes
PushpikaWan
PushpikaWan

Reputation: 2545

Java best practice or are there any design patterns to keep data filed which hasn't a direct relationship with that class

I just want to pass the value with the object but that value is not completely related to that object. Let's say there is an object call Request Data

public class RequestData
{
  private int requestId;
  private String status;
 .......
}

I want to pass is this request need to save only or print only or both save and print likewise there are several actions. When I pass this request data to another class to validate this requestData, I want to identify is it coming from save or print or save and print call. For that, basically, I can add an attribute to that RequestData class. But according to my learning in OOP, We should keep attributes related directly to that objects as attribute of that object.

Then what is the best practice or are there any design patterns to keep data filed which hasn't a direct relationship with that class.

Upvotes: 1

Views: 79

Answers (4)

MAkS
MAkS

Reputation: 751

Ideally, you Request data class should have a state requestAction which should state what action it should perform. In your case it could be save, print, both, etc.

In future, if more actions are introduced you need not to modify your code (Open close principle) You could enumerate values which requestAction could take.

public class RequestData
{
  private int requestId;
  private String status;
  private String requestAction ;
 .......
}

Upvotes: 0

prasad_
prasad_

Reputation: 14287

Define a request type attribute - and this identifies if its a print or save. Define this attribute as an enum. This way if another type like "query" or "update" is needed you can add a new value to the enum class. It is also documentation of the code and the functionality.

Here is what the code can look like:

enum RequestType { SAVE, PRINT }

class RequestData {
    private int requestId;
    private String status;
    private RequestType requestType;
    .......
    // Get/set methods for request type
    public RequestType getRequestType()
        return this.requestType;
    }
}

class UtilityClass {
    static boolean validateRequestData(RequestData req) {
        switch (req.getRequestType()) {
            case SAVE: // do save related validation
            case PRINT: // do print related validation
            default: throw new IllegalArgumentException("Illegal request type");
        }
        ...
    }

    // private boolean ... detailed validate methods called from switch-case.
}

public class RunMyApp {
    public static void main(String [] args) {
        ...
        // Invoke the request data validation
        RequestData rd1 = new RequestData();
        rd1.setRequestType(RequestType.PRINT);
        if (UtilityClass.validateRequestData(rd1) {
            ...
    }
}

Upvotes: 1

Nghia Bui
Nghia Bui

Reputation: 3784

Yes, you're right! Putting an unrelated attribute into you class would make difficult to reuse the class in another environment which does not require that unrelated attribute.

A typical solution is to create another class that makes use of the old class:

class SecondRequestData {
    private RequestData origin;
    private bool isSave;
    private bool isPrint;
}

Upvotes: 2

Blagoj Atanasovski
Blagoj Atanasovski

Reputation: 863

Keep it simple, add all properties related to the request to the RequestData class (the request type seems to me is a property of the request). Regarding validation, if the validity of the request depends on the place it is validated (where the request is handled) then keep it outside, if the validity of a request is based only on the data inside the RequestData object then, put the validate method inside this class

Upvotes: 0

Related Questions