Why CloudFrontUrlSigner is an enum in aws-java-sdk
Source code of sdk saying that com.amazonaws.services.cloudfront.CloudFrontUrlSigner
is an enum
type.
Why they did not implement this as a normal java utility class; e.g. class CloudFrontUrlSigner
with public static
methods?
is there any major reason for using enum
or just they designed it like that.
java amazon-cloudfront aws-java-sdk
add a comment |
Source code of sdk saying that com.amazonaws.services.cloudfront.CloudFrontUrlSigner
is an enum
type.
Why they did not implement this as a normal java utility class; e.g. class CloudFrontUrlSigner
with public static
methods?
is there any major reason for using enum
or just they designed it like that.
java amazon-cloudfront aws-java-sdk
add a comment |
Source code of sdk saying that com.amazonaws.services.cloudfront.CloudFrontUrlSigner
is an enum
type.
Why they did not implement this as a normal java utility class; e.g. class CloudFrontUrlSigner
with public static
methods?
is there any major reason for using enum
or just they designed it like that.
java amazon-cloudfront aws-java-sdk
Source code of sdk saying that com.amazonaws.services.cloudfront.CloudFrontUrlSigner
is an enum
type.
Why they did not implement this as a normal java utility class; e.g. class CloudFrontUrlSigner
with public static
methods?
is there any major reason for using enum
or just they designed it like that.
java amazon-cloudfront aws-java-sdk
java amazon-cloudfront aws-java-sdk
edited Jan 17 at 19:46
mmuzahid
asked Jan 2 at 18:08
mmuzahidmmuzahid
1,5441431
1,5441431
add a comment |
add a comment |
1 Answer
1
active
oldest
votes
Checking on the source of class you're mentioning seems to indicate that CloudFrontUrlSigner
is merely a utlity class, exposing a few public static methods. Said methods are public and static, essentially working as utility methods, which accept a few arguments, do some post processing on them and then return something (in this case a String
).
Thus, as mentioned above the core functionality on this class is essentially a utility helper class. With that in mind, one has to take into account the best practices when creating any utility class. The main revolves around the notion of avoiding inadvertent instantiation of the class in question.
With this in mind assume what actions the developer would need to have taken to ensure this had they had chosen to implement this with a normal class. They would have had to declare the class as final
(to avoid inheriting), they would have put in place a private constructor and then create all the public methods.
Choosing though to use an enum
pretty much offers all the above out of the box. You can't inherit from an enum
nor can you instantiate with new
.
To sum up, they have chosen this in order to seemingly abide with the best practises of creating a utlity class. Ideally, for me I would go with the same enum
concept but would rather have a singleton service with the said methods.
Interesting explanation from you. Usingenum
for utility this way I never thought earlier. Upvoted for explanation.
– mmuzahid
Jan 3 at 1:58
add a comment |
Your Answer
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: "1"
};
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',
autoActivateHeartbeat: false,
convertImagesToLinks: true,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: 10,
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
});
}
});
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f54011134%2fwhy-cloudfronturlsigner-is-an-enum-in-aws-java-sdk%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
1 Answer
1
active
oldest
votes
1 Answer
1
active
oldest
votes
active
oldest
votes
active
oldest
votes
Checking on the source of class you're mentioning seems to indicate that CloudFrontUrlSigner
is merely a utlity class, exposing a few public static methods. Said methods are public and static, essentially working as utility methods, which accept a few arguments, do some post processing on them and then return something (in this case a String
).
Thus, as mentioned above the core functionality on this class is essentially a utility helper class. With that in mind, one has to take into account the best practices when creating any utility class. The main revolves around the notion of avoiding inadvertent instantiation of the class in question.
With this in mind assume what actions the developer would need to have taken to ensure this had they had chosen to implement this with a normal class. They would have had to declare the class as final
(to avoid inheriting), they would have put in place a private constructor and then create all the public methods.
Choosing though to use an enum
pretty much offers all the above out of the box. You can't inherit from an enum
nor can you instantiate with new
.
To sum up, they have chosen this in order to seemingly abide with the best practises of creating a utlity class. Ideally, for me I would go with the same enum
concept but would rather have a singleton service with the said methods.
Interesting explanation from you. Usingenum
for utility this way I never thought earlier. Upvoted for explanation.
– mmuzahid
Jan 3 at 1:58
add a comment |
Checking on the source of class you're mentioning seems to indicate that CloudFrontUrlSigner
is merely a utlity class, exposing a few public static methods. Said methods are public and static, essentially working as utility methods, which accept a few arguments, do some post processing on them and then return something (in this case a String
).
Thus, as mentioned above the core functionality on this class is essentially a utility helper class. With that in mind, one has to take into account the best practices when creating any utility class. The main revolves around the notion of avoiding inadvertent instantiation of the class in question.
With this in mind assume what actions the developer would need to have taken to ensure this had they had chosen to implement this with a normal class. They would have had to declare the class as final
(to avoid inheriting), they would have put in place a private constructor and then create all the public methods.
Choosing though to use an enum
pretty much offers all the above out of the box. You can't inherit from an enum
nor can you instantiate with new
.
To sum up, they have chosen this in order to seemingly abide with the best practises of creating a utlity class. Ideally, for me I would go with the same enum
concept but would rather have a singleton service with the said methods.
Interesting explanation from you. Usingenum
for utility this way I never thought earlier. Upvoted for explanation.
– mmuzahid
Jan 3 at 1:58
add a comment |
Checking on the source of class you're mentioning seems to indicate that CloudFrontUrlSigner
is merely a utlity class, exposing a few public static methods. Said methods are public and static, essentially working as utility methods, which accept a few arguments, do some post processing on them and then return something (in this case a String
).
Thus, as mentioned above the core functionality on this class is essentially a utility helper class. With that in mind, one has to take into account the best practices when creating any utility class. The main revolves around the notion of avoiding inadvertent instantiation of the class in question.
With this in mind assume what actions the developer would need to have taken to ensure this had they had chosen to implement this with a normal class. They would have had to declare the class as final
(to avoid inheriting), they would have put in place a private constructor and then create all the public methods.
Choosing though to use an enum
pretty much offers all the above out of the box. You can't inherit from an enum
nor can you instantiate with new
.
To sum up, they have chosen this in order to seemingly abide with the best practises of creating a utlity class. Ideally, for me I would go with the same enum
concept but would rather have a singleton service with the said methods.
Checking on the source of class you're mentioning seems to indicate that CloudFrontUrlSigner
is merely a utlity class, exposing a few public static methods. Said methods are public and static, essentially working as utility methods, which accept a few arguments, do some post processing on them and then return something (in this case a String
).
Thus, as mentioned above the core functionality on this class is essentially a utility helper class. With that in mind, one has to take into account the best practices when creating any utility class. The main revolves around the notion of avoiding inadvertent instantiation of the class in question.
With this in mind assume what actions the developer would need to have taken to ensure this had they had chosen to implement this with a normal class. They would have had to declare the class as final
(to avoid inheriting), they would have put in place a private constructor and then create all the public methods.
Choosing though to use an enum
pretty much offers all the above out of the box. You can't inherit from an enum
nor can you instantiate with new
.
To sum up, they have chosen this in order to seemingly abide with the best practises of creating a utlity class. Ideally, for me I would go with the same enum
concept but would rather have a singleton service with the said methods.
answered Jan 2 at 19:27
Aris_KortexAris_Kortex
1,6711923
1,6711923
Interesting explanation from you. Usingenum
for utility this way I never thought earlier. Upvoted for explanation.
– mmuzahid
Jan 3 at 1:58
add a comment |
Interesting explanation from you. Usingenum
for utility this way I never thought earlier. Upvoted for explanation.
– mmuzahid
Jan 3 at 1:58
Interesting explanation from you. Using
enum
for utility this way I never thought earlier. Upvoted for explanation.– mmuzahid
Jan 3 at 1:58
Interesting explanation from you. Using
enum
for utility this way I never thought earlier. Upvoted for explanation.– mmuzahid
Jan 3 at 1:58
add a comment |
Thanks for contributing an answer to Stack Overflow!
- 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.
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f54011134%2fwhy-cloudfronturlsigner-is-an-enum-in-aws-java-sdk%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
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