What is a good place, in OO, to store a string that is used many places?
I have a string that is used in a few places.
string portalLoginPath = $"{Request.Scheme}{Uri.SchemeDelimiter}{Request.Host}/Account/Login";
I was thinking of creating a static class with a string const to store it.
public static class StringConsts{
public const string portalPath = $"{Request.Scheme}{Uri.SchemeDelimiter}{Request.Host}/Account/Login";
}
Is there a cleaner way to do this?
I'm building in ASP.NET Core MVC
c# object-oriented clean-code strings
add a comment |
I have a string that is used in a few places.
string portalLoginPath = $"{Request.Scheme}{Uri.SchemeDelimiter}{Request.Host}/Account/Login";
I was thinking of creating a static class with a string const to store it.
public static class StringConsts{
public const string portalPath = $"{Request.Scheme}{Uri.SchemeDelimiter}{Request.Host}/Account/Login";
}
Is there a cleaner way to do this?
I'm building in ASP.NET Core MVC
c# object-oriented clean-code strings
1
One thing to keep in mind when making this decision is how difficult you're making it to internationalize the application. If the German market opens up to you how much rewriting do you want to do just to use the translated versions of your strings? Is YAGNI good enough here or is it worth at least thinking about it?
– candied_orange
Dec 15 at 0:59
1
The first question you should ask is: Do I really need to use it in that many places?
– Frank Puffer
Dec 15 at 7:08
add a comment |
I have a string that is used in a few places.
string portalLoginPath = $"{Request.Scheme}{Uri.SchemeDelimiter}{Request.Host}/Account/Login";
I was thinking of creating a static class with a string const to store it.
public static class StringConsts{
public const string portalPath = $"{Request.Scheme}{Uri.SchemeDelimiter}{Request.Host}/Account/Login";
}
Is there a cleaner way to do this?
I'm building in ASP.NET Core MVC
c# object-oriented clean-code strings
I have a string that is used in a few places.
string portalLoginPath = $"{Request.Scheme}{Uri.SchemeDelimiter}{Request.Host}/Account/Login";
I was thinking of creating a static class with a string const to store it.
public static class StringConsts{
public const string portalPath = $"{Request.Scheme}{Uri.SchemeDelimiter}{Request.Host}/Account/Login";
}
Is there a cleaner way to do this?
I'm building in ASP.NET Core MVC
c# object-oriented clean-code strings
c# object-oriented clean-code strings
edited Dec 14 at 21:39
asked Dec 14 at 21:32
JohnOsborne
1489
1489
1
One thing to keep in mind when making this decision is how difficult you're making it to internationalize the application. If the German market opens up to you how much rewriting do you want to do just to use the translated versions of your strings? Is YAGNI good enough here or is it worth at least thinking about it?
– candied_orange
Dec 15 at 0:59
1
The first question you should ask is: Do I really need to use it in that many places?
– Frank Puffer
Dec 15 at 7:08
add a comment |
1
One thing to keep in mind when making this decision is how difficult you're making it to internationalize the application. If the German market opens up to you how much rewriting do you want to do just to use the translated versions of your strings? Is YAGNI good enough here or is it worth at least thinking about it?
– candied_orange
Dec 15 at 0:59
1
The first question you should ask is: Do I really need to use it in that many places?
– Frank Puffer
Dec 15 at 7:08
1
1
One thing to keep in mind when making this decision is how difficult you're making it to internationalize the application. If the German market opens up to you how much rewriting do you want to do just to use the translated versions of your strings? Is YAGNI good enough here or is it worth at least thinking about it?
– candied_orange
Dec 15 at 0:59
One thing to keep in mind when making this decision is how difficult you're making it to internationalize the application. If the German market opens up to you how much rewriting do you want to do just to use the translated versions of your strings? Is YAGNI good enough here or is it worth at least thinking about it?
– candied_orange
Dec 15 at 0:59
1
1
The first question you should ask is: Do I really need to use it in that many places?
– Frank Puffer
Dec 15 at 7:08
The first question you should ask is: Do I really need to use it in that many places?
– Frank Puffer
Dec 15 at 7:08
add a comment |
4 Answers
4
active
oldest
votes
In C# a string preceded by a $ is an interpolated string.
An interpolated string is a construct that both
- declares a string literal, and,
- asks the compiler to interpolate variables names/expressions within the string.
These two cannot be separated: I know of no way to declare the string outside of the context where the compiler will find the variables, and no way to ask for interpolation of an externally stored string in the context of a scope that has the variables of interest.
Thus, there's no way to put a $"{}" type string anywhere but within the code that uses it.
The only way to put the string elsewhere (other than embedded in the code) is to forgo interpolation. In your case all that would be left is "/Account/Login"
, leaving you to use the expressions in a string.Format statement.
With this response in mind, I'd say a static class with a static method taking your Request and Uri objects as input is probably what you're looking for.
– Turksarama
Dec 15 at 8:27
add a comment |
A static class is a good idea. One thing to be careful of is that class getting cluttered with a bunch of strings, then you might have little context of what the string is actually used for.
One way to solve this is have the context in the name of the class. Instead of StringConsts
, maybe call this PortalConsts
(Or whatever makes the most sense). This way you can organize your strings by class so it doesn't get disorganized.
add a comment |
You shouldn't just be thinking of this as "a string that needs to be shared" - "strings" are a technical definition, not part of your OO or domain model. Who, in your system, would know the portal login url? Probably some sort of LoginManager
, or perhaps PortalConnection
component, which could also expose this path if necessary.
Of course, with this PortalConnection
, you might see that it makes more sense, from the perspective of encapsulation, to not expose that string path, but instead expose a Login()
method on your PortalConnection
which handles logging into the portal in one place, instead of exposing the path, which is an implementation detail - it shouldn't be the responsibility of every component in your system to know how to login.
add a comment |
Since what you want is to interpolate, what you're describing is not a constant but a function. In that case you could use a delegate:
public delegate string PortalPathFormatFunction(string scheme, string delimiter,
string host);
The reason I would use a delegate instead of just Func<string, string, string, string>
is that it identifies the purpose of a function and disambiguates it from other functions with the same signature.
You could then implement it something like this (naming is hard)
public static class PathFormats
{
public static PortalPathFormatFunction GetPortalPath { get; }
= (scheme, delimiter, host) => $"{scheme}{delimiter}{host}/Account/Login";
}
or just
public static string GetPortalPath(string scheme, string delimiter, string host) =>
$"{scheme}{delimiter}{host}/Account/Login";
I prefer the first one because it specifies that the function must correspond to the delegate, like a class implementing an interface. If someone changes the function so that it no longer matches the delegate, I want the compiler error there, telling them not to do that, as opposed to somewhere else.
add a comment |
Your Answer
StackExchange.ready(function() {
var channelOptions = {
tags: "".split(" "),
id: "131"
};
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: 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
});
}
});
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%2fsoftwareengineering.stackexchange.com%2fquestions%2f383059%2fwhat-is-a-good-place-in-oo-to-store-a-string-that-is-used-many-places%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
4 Answers
4
active
oldest
votes
4 Answers
4
active
oldest
votes
active
oldest
votes
active
oldest
votes
In C# a string preceded by a $ is an interpolated string.
An interpolated string is a construct that both
- declares a string literal, and,
- asks the compiler to interpolate variables names/expressions within the string.
These two cannot be separated: I know of no way to declare the string outside of the context where the compiler will find the variables, and no way to ask for interpolation of an externally stored string in the context of a scope that has the variables of interest.
Thus, there's no way to put a $"{}" type string anywhere but within the code that uses it.
The only way to put the string elsewhere (other than embedded in the code) is to forgo interpolation. In your case all that would be left is "/Account/Login"
, leaving you to use the expressions in a string.Format statement.
With this response in mind, I'd say a static class with a static method taking your Request and Uri objects as input is probably what you're looking for.
– Turksarama
Dec 15 at 8:27
add a comment |
In C# a string preceded by a $ is an interpolated string.
An interpolated string is a construct that both
- declares a string literal, and,
- asks the compiler to interpolate variables names/expressions within the string.
These two cannot be separated: I know of no way to declare the string outside of the context where the compiler will find the variables, and no way to ask for interpolation of an externally stored string in the context of a scope that has the variables of interest.
Thus, there's no way to put a $"{}" type string anywhere but within the code that uses it.
The only way to put the string elsewhere (other than embedded in the code) is to forgo interpolation. In your case all that would be left is "/Account/Login"
, leaving you to use the expressions in a string.Format statement.
With this response in mind, I'd say a static class with a static method taking your Request and Uri objects as input is probably what you're looking for.
– Turksarama
Dec 15 at 8:27
add a comment |
In C# a string preceded by a $ is an interpolated string.
An interpolated string is a construct that both
- declares a string literal, and,
- asks the compiler to interpolate variables names/expressions within the string.
These two cannot be separated: I know of no way to declare the string outside of the context where the compiler will find the variables, and no way to ask for interpolation of an externally stored string in the context of a scope that has the variables of interest.
Thus, there's no way to put a $"{}" type string anywhere but within the code that uses it.
The only way to put the string elsewhere (other than embedded in the code) is to forgo interpolation. In your case all that would be left is "/Account/Login"
, leaving you to use the expressions in a string.Format statement.
In C# a string preceded by a $ is an interpolated string.
An interpolated string is a construct that both
- declares a string literal, and,
- asks the compiler to interpolate variables names/expressions within the string.
These two cannot be separated: I know of no way to declare the string outside of the context where the compiler will find the variables, and no way to ask for interpolation of an externally stored string in the context of a scope that has the variables of interest.
Thus, there's no way to put a $"{}" type string anywhere but within the code that uses it.
The only way to put the string elsewhere (other than embedded in the code) is to forgo interpolation. In your case all that would be left is "/Account/Login"
, leaving you to use the expressions in a string.Format statement.
edited Dec 14 at 21:50
answered Dec 14 at 21:44
Erik Eidt
22.2k43156
22.2k43156
With this response in mind, I'd say a static class with a static method taking your Request and Uri objects as input is probably what you're looking for.
– Turksarama
Dec 15 at 8:27
add a comment |
With this response in mind, I'd say a static class with a static method taking your Request and Uri objects as input is probably what you're looking for.
– Turksarama
Dec 15 at 8:27
With this response in mind, I'd say a static class with a static method taking your Request and Uri objects as input is probably what you're looking for.
– Turksarama
Dec 15 at 8:27
With this response in mind, I'd say a static class with a static method taking your Request and Uri objects as input is probably what you're looking for.
– Turksarama
Dec 15 at 8:27
add a comment |
A static class is a good idea. One thing to be careful of is that class getting cluttered with a bunch of strings, then you might have little context of what the string is actually used for.
One way to solve this is have the context in the name of the class. Instead of StringConsts
, maybe call this PortalConsts
(Or whatever makes the most sense). This way you can organize your strings by class so it doesn't get disorganized.
add a comment |
A static class is a good idea. One thing to be careful of is that class getting cluttered with a bunch of strings, then you might have little context of what the string is actually used for.
One way to solve this is have the context in the name of the class. Instead of StringConsts
, maybe call this PortalConsts
(Or whatever makes the most sense). This way you can organize your strings by class so it doesn't get disorganized.
add a comment |
A static class is a good idea. One thing to be careful of is that class getting cluttered with a bunch of strings, then you might have little context of what the string is actually used for.
One way to solve this is have the context in the name of the class. Instead of StringConsts
, maybe call this PortalConsts
(Or whatever makes the most sense). This way you can organize your strings by class so it doesn't get disorganized.
A static class is a good idea. One thing to be careful of is that class getting cluttered with a bunch of strings, then you might have little context of what the string is actually used for.
One way to solve this is have the context in the name of the class. Instead of StringConsts
, maybe call this PortalConsts
(Or whatever makes the most sense). This way you can organize your strings by class so it doesn't get disorganized.
answered Dec 14 at 21:41
JSarwer
787
787
add a comment |
add a comment |
You shouldn't just be thinking of this as "a string that needs to be shared" - "strings" are a technical definition, not part of your OO or domain model. Who, in your system, would know the portal login url? Probably some sort of LoginManager
, or perhaps PortalConnection
component, which could also expose this path if necessary.
Of course, with this PortalConnection
, you might see that it makes more sense, from the perspective of encapsulation, to not expose that string path, but instead expose a Login()
method on your PortalConnection
which handles logging into the portal in one place, instead of exposing the path, which is an implementation detail - it shouldn't be the responsibility of every component in your system to know how to login.
add a comment |
You shouldn't just be thinking of this as "a string that needs to be shared" - "strings" are a technical definition, not part of your OO or domain model. Who, in your system, would know the portal login url? Probably some sort of LoginManager
, or perhaps PortalConnection
component, which could also expose this path if necessary.
Of course, with this PortalConnection
, you might see that it makes more sense, from the perspective of encapsulation, to not expose that string path, but instead expose a Login()
method on your PortalConnection
which handles logging into the portal in one place, instead of exposing the path, which is an implementation detail - it shouldn't be the responsibility of every component in your system to know how to login.
add a comment |
You shouldn't just be thinking of this as "a string that needs to be shared" - "strings" are a technical definition, not part of your OO or domain model. Who, in your system, would know the portal login url? Probably some sort of LoginManager
, or perhaps PortalConnection
component, which could also expose this path if necessary.
Of course, with this PortalConnection
, you might see that it makes more sense, from the perspective of encapsulation, to not expose that string path, but instead expose a Login()
method on your PortalConnection
which handles logging into the portal in one place, instead of exposing the path, which is an implementation detail - it shouldn't be the responsibility of every component in your system to know how to login.
You shouldn't just be thinking of this as "a string that needs to be shared" - "strings" are a technical definition, not part of your OO or domain model. Who, in your system, would know the portal login url? Probably some sort of LoginManager
, or perhaps PortalConnection
component, which could also expose this path if necessary.
Of course, with this PortalConnection
, you might see that it makes more sense, from the perspective of encapsulation, to not expose that string path, but instead expose a Login()
method on your PortalConnection
which handles logging into the portal in one place, instead of exposing the path, which is an implementation detail - it shouldn't be the responsibility of every component in your system to know how to login.
answered Dec 15 at 8:17
Avner Shahar-Kashtan
7,18622132
7,18622132
add a comment |
add a comment |
Since what you want is to interpolate, what you're describing is not a constant but a function. In that case you could use a delegate:
public delegate string PortalPathFormatFunction(string scheme, string delimiter,
string host);
The reason I would use a delegate instead of just Func<string, string, string, string>
is that it identifies the purpose of a function and disambiguates it from other functions with the same signature.
You could then implement it something like this (naming is hard)
public static class PathFormats
{
public static PortalPathFormatFunction GetPortalPath { get; }
= (scheme, delimiter, host) => $"{scheme}{delimiter}{host}/Account/Login";
}
or just
public static string GetPortalPath(string scheme, string delimiter, string host) =>
$"{scheme}{delimiter}{host}/Account/Login";
I prefer the first one because it specifies that the function must correspond to the delegate, like a class implementing an interface. If someone changes the function so that it no longer matches the delegate, I want the compiler error there, telling them not to do that, as opposed to somewhere else.
add a comment |
Since what you want is to interpolate, what you're describing is not a constant but a function. In that case you could use a delegate:
public delegate string PortalPathFormatFunction(string scheme, string delimiter,
string host);
The reason I would use a delegate instead of just Func<string, string, string, string>
is that it identifies the purpose of a function and disambiguates it from other functions with the same signature.
You could then implement it something like this (naming is hard)
public static class PathFormats
{
public static PortalPathFormatFunction GetPortalPath { get; }
= (scheme, delimiter, host) => $"{scheme}{delimiter}{host}/Account/Login";
}
or just
public static string GetPortalPath(string scheme, string delimiter, string host) =>
$"{scheme}{delimiter}{host}/Account/Login";
I prefer the first one because it specifies that the function must correspond to the delegate, like a class implementing an interface. If someone changes the function so that it no longer matches the delegate, I want the compiler error there, telling them not to do that, as opposed to somewhere else.
add a comment |
Since what you want is to interpolate, what you're describing is not a constant but a function. In that case you could use a delegate:
public delegate string PortalPathFormatFunction(string scheme, string delimiter,
string host);
The reason I would use a delegate instead of just Func<string, string, string, string>
is that it identifies the purpose of a function and disambiguates it from other functions with the same signature.
You could then implement it something like this (naming is hard)
public static class PathFormats
{
public static PortalPathFormatFunction GetPortalPath { get; }
= (scheme, delimiter, host) => $"{scheme}{delimiter}{host}/Account/Login";
}
or just
public static string GetPortalPath(string scheme, string delimiter, string host) =>
$"{scheme}{delimiter}{host}/Account/Login";
I prefer the first one because it specifies that the function must correspond to the delegate, like a class implementing an interface. If someone changes the function so that it no longer matches the delegate, I want the compiler error there, telling them not to do that, as opposed to somewhere else.
Since what you want is to interpolate, what you're describing is not a constant but a function. In that case you could use a delegate:
public delegate string PortalPathFormatFunction(string scheme, string delimiter,
string host);
The reason I would use a delegate instead of just Func<string, string, string, string>
is that it identifies the purpose of a function and disambiguates it from other functions with the same signature.
You could then implement it something like this (naming is hard)
public static class PathFormats
{
public static PortalPathFormatFunction GetPortalPath { get; }
= (scheme, delimiter, host) => $"{scheme}{delimiter}{host}/Account/Login";
}
or just
public static string GetPortalPath(string scheme, string delimiter, string host) =>
$"{scheme}{delimiter}{host}/Account/Login";
I prefer the first one because it specifies that the function must correspond to the delegate, like a class implementing an interface. If someone changes the function so that it no longer matches the delegate, I want the compiler error there, telling them not to do that, as opposed to somewhere else.
answered 14 hours ago
Scott Hannen
28016
28016
add a comment |
add a comment |
Thanks for contributing an answer to Software Engineering 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.
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.
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%2fsoftwareengineering.stackexchange.com%2fquestions%2f383059%2fwhat-is-a-good-place-in-oo-to-store-a-string-that-is-used-many-places%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
1
One thing to keep in mind when making this decision is how difficult you're making it to internationalize the application. If the German market opens up to you how much rewriting do you want to do just to use the translated versions of your strings? Is YAGNI good enough here or is it worth at least thinking about it?
– candied_orange
Dec 15 at 0:59
1
The first question you should ask is: Do I really need to use it in that many places?
– Frank Puffer
Dec 15 at 7:08