Static factory method vs adapter











up vote
-3
down vote

favorite












I have a problem which approach is best. Please imagine system written in a hexagonal architecture where each service method accepts class or classes. Let say for example my method create User.
1. Approach:
Of course, it is the only example and real classes can be more complex to accept more arguments etc.
I have a class like this:



class CreateUserCommand {

private final String name;
private final String username;
// let say 10 other fields emails etc it doesnt matter


private CreateUserCommand(String name, String username) {
this.name = name;
this.username = username;
}

public static CreateUserCommand createFromApi(CreateUserRequestApi createUserRequestApi) {
return new CreateUserCommand(createUserRequestApi.getName(), createUserRequestApi.getUsername());
}

public static CreateUserCommand createFromRabbit(CreateUserRabbitMessage createUserRabbitMessage) {
return new CreateUserCommand(createUserRabbitMessage.getName(), createUserRabbitMessage.getUsername());
}

}



  1. Approach:


interface CreateUserCommand {



public String getName();
public String getUsername();
//other 10 methods like getters


}



And for each entry point to my system (api, rabbitmq etc) I will create adapters for this interface so in my service I will operate on the interface instead of real implementation of a class as I do in the first example. What approach do you thinks is better and why?










share|improve this question


















  • 1




    This is not the site to ask general design advice. We require concrete code from a project. As such your current question is off-topic as it consists of hypothetical code. If you can update the question with your actual code then you can still include your concerns. Please see the help center for more information.
    – bruglesco
    15 hours ago















up vote
-3
down vote

favorite












I have a problem which approach is best. Please imagine system written in a hexagonal architecture where each service method accepts class or classes. Let say for example my method create User.
1. Approach:
Of course, it is the only example and real classes can be more complex to accept more arguments etc.
I have a class like this:



class CreateUserCommand {

private final String name;
private final String username;
// let say 10 other fields emails etc it doesnt matter


private CreateUserCommand(String name, String username) {
this.name = name;
this.username = username;
}

public static CreateUserCommand createFromApi(CreateUserRequestApi createUserRequestApi) {
return new CreateUserCommand(createUserRequestApi.getName(), createUserRequestApi.getUsername());
}

public static CreateUserCommand createFromRabbit(CreateUserRabbitMessage createUserRabbitMessage) {
return new CreateUserCommand(createUserRabbitMessage.getName(), createUserRabbitMessage.getUsername());
}

}



  1. Approach:


interface CreateUserCommand {



public String getName();
public String getUsername();
//other 10 methods like getters


}



And for each entry point to my system (api, rabbitmq etc) I will create adapters for this interface so in my service I will operate on the interface instead of real implementation of a class as I do in the first example. What approach do you thinks is better and why?










share|improve this question


















  • 1




    This is not the site to ask general design advice. We require concrete code from a project. As such your current question is off-topic as it consists of hypothetical code. If you can update the question with your actual code then you can still include your concerns. Please see the help center for more information.
    – bruglesco
    15 hours ago













up vote
-3
down vote

favorite









up vote
-3
down vote

favorite











I have a problem which approach is best. Please imagine system written in a hexagonal architecture where each service method accepts class or classes. Let say for example my method create User.
1. Approach:
Of course, it is the only example and real classes can be more complex to accept more arguments etc.
I have a class like this:



class CreateUserCommand {

private final String name;
private final String username;
// let say 10 other fields emails etc it doesnt matter


private CreateUserCommand(String name, String username) {
this.name = name;
this.username = username;
}

public static CreateUserCommand createFromApi(CreateUserRequestApi createUserRequestApi) {
return new CreateUserCommand(createUserRequestApi.getName(), createUserRequestApi.getUsername());
}

public static CreateUserCommand createFromRabbit(CreateUserRabbitMessage createUserRabbitMessage) {
return new CreateUserCommand(createUserRabbitMessage.getName(), createUserRabbitMessage.getUsername());
}

}



  1. Approach:


interface CreateUserCommand {



public String getName();
public String getUsername();
//other 10 methods like getters


}



And for each entry point to my system (api, rabbitmq etc) I will create adapters for this interface so in my service I will operate on the interface instead of real implementation of a class as I do in the first example. What approach do you thinks is better and why?










share|improve this question













I have a problem which approach is best. Please imagine system written in a hexagonal architecture where each service method accepts class or classes. Let say for example my method create User.
1. Approach:
Of course, it is the only example and real classes can be more complex to accept more arguments etc.
I have a class like this:



class CreateUserCommand {

private final String name;
private final String username;
// let say 10 other fields emails etc it doesnt matter


private CreateUserCommand(String name, String username) {
this.name = name;
this.username = username;
}

public static CreateUserCommand createFromApi(CreateUserRequestApi createUserRequestApi) {
return new CreateUserCommand(createUserRequestApi.getName(), createUserRequestApi.getUsername());
}

public static CreateUserCommand createFromRabbit(CreateUserRabbitMessage createUserRabbitMessage) {
return new CreateUserCommand(createUserRabbitMessage.getName(), createUserRabbitMessage.getUsername());
}

}



  1. Approach:


interface CreateUserCommand {



public String getName();
public String getUsername();
//other 10 methods like getters


}



And for each entry point to my system (api, rabbitmq etc) I will create adapters for this interface so in my service I will operate on the interface instead of real implementation of a class as I do in the first example. What approach do you thinks is better and why?







java object-oriented design-patterns






share|improve this question













share|improve this question











share|improve this question




share|improve this question










asked 15 hours ago









Pulkownik

10629




10629








  • 1




    This is not the site to ask general design advice. We require concrete code from a project. As such your current question is off-topic as it consists of hypothetical code. If you can update the question with your actual code then you can still include your concerns. Please see the help center for more information.
    – bruglesco
    15 hours ago














  • 1




    This is not the site to ask general design advice. We require concrete code from a project. As such your current question is off-topic as it consists of hypothetical code. If you can update the question with your actual code then you can still include your concerns. Please see the help center for more information.
    – bruglesco
    15 hours ago








1




1




This is not the site to ask general design advice. We require concrete code from a project. As such your current question is off-topic as it consists of hypothetical code. If you can update the question with your actual code then you can still include your concerns. Please see the help center for more information.
– bruglesco
15 hours ago




This is not the site to ask general design advice. We require concrete code from a project. As such your current question is off-topic as it consists of hypothetical code. If you can update the question with your actual code then you can still include your concerns. Please see the help center for more information.
– bruglesco
15 hours ago















active

oldest

votes











Your Answer





StackExchange.ifUsing("editor", function () {
return StackExchange.using("mathjaxEditing", function () {
StackExchange.MarkdownEditor.creationCallbacks.add(function (editor, postfix) {
StackExchange.mathjaxEditing.prepareWmdForMathJax(editor, postfix, [["\$", "\$"]]);
});
});
}, "mathjax-editing");

StackExchange.ifUsing("editor", function () {
StackExchange.using("externalEditor", function () {
StackExchange.using("snippets", function () {
StackExchange.snippets.init();
});
});
}, "code-snippets");

StackExchange.ready(function() {
var channelOptions = {
tags: "".split(" "),
id: "196"
};
initTagRenderer("".split(" "), "".split(" "), channelOptions);

StackExchange.using("externalEditor", function() {
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled) {
StackExchange.using("snippets", function() {
createEditor();
});
}
else {
createEditor();
}
});

function createEditor() {
StackExchange.prepareEditor({
heartbeatType: 'answer',
convertImagesToLinks: false,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: null,
bindNavPrevention: true,
postfix: "",
imageUploader: {
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
},
onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
});


}
});














draft saved

draft discarded


















StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fcodereview.stackexchange.com%2fquestions%2f209269%2fstatic-factory-method-vs-adapter%23new-answer', 'question_page');
}
);

Post as a guest















Required, but never shown






























active

oldest

votes













active

oldest

votes









active

oldest

votes






active

oldest

votes
















draft saved

draft discarded




















































Thanks for contributing an answer to Code Review Stack Exchange!


  • Please be sure to answer the question. Provide details and share your research!

But avoid



  • Asking for help, clarification, or responding to other answers.

  • Making statements based on opinion; back them up with references or personal experience.


Use MathJax to format equations. MathJax reference.


To learn more, see our tips on writing great answers.





Some of your past answers have not been well-received, and you're in danger of being blocked from answering.


Please pay close attention to the following guidance:


  • Please be sure to answer the question. Provide details and share your research!

But avoid



  • Asking for help, clarification, or responding to other answers.

  • Making statements based on opinion; back them up with references or personal experience.


To learn more, see our tips on writing great answers.




draft saved


draft discarded














StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fcodereview.stackexchange.com%2fquestions%2f209269%2fstatic-factory-method-vs-adapter%23new-answer', 'question_page');
}
);

Post as a guest















Required, but never shown





















































Required, but never shown














Required, but never shown












Required, but never shown







Required, but never shown

































Required, but never shown














Required, but never shown












Required, but never shown







Required, but never shown







Popular posts from this blog

Morgemoulin

Scott Moir

Souastre