Parameters storing paradigm
I developed my next application: parameters storing paradigm.
There is an enum for each parameter roles:
enum ParameterRole
{
FileName,
FileDir
}
Parameters are contained in a special container as an object:
class ParamContainer : Dictionary(ParameterRole, object) {
public new object this[ParameterRole role]
{
get
{
if (base.ContainsKey(role))
{
return base[role];
}
else
{
return null;
}
}
set
{
if (base.ContainsKey(role))
{
base[role] = value;
}
else
{
base.Add(role, value);
}
}
}
}
Its private member of the AppSettings class:
class AppSettings {
ParamContainer container = new ParamContainer();
public string FileName
{
get
{
return container[ParemeterRole.FileName] as string;
}
set
{
container[ParemeterRole.FileName] = value;
}
}
}
and for each settings there is a corresponding property, but it works not with a local variable, but adds/gets a value from the container.
Benefits:
You can work with parameters separately as named property, so as list (container.Keys, container.Values) - it's useful for SQL queries and XML based business logic.
Deficiencies:
Parameter values are stored as an object and it uses more memory as it could, I guess, if it was stored as its corresponding types.
What do you think about it? It's very interesting and important for me. Is it rubbish or could it be useful?
c#
edited 21 mins ago
Jamal♦
30.2k11116226
asked Dec 27 '08 at 10:30
abatishchev
255111
migrated from stackoverflow.com May 1 '12 at 2:09
This question came from our site for professional and enthusiast programmers.
add a comment |
I developed my next application: parameters storing paradigm.
There is an enum for each parameter roles:
enum ParameterRole
{
FileName,
FileDir
}
Parameters are contained in a special container as an object:
class ParamContainer : Dictionary(ParameterRole, object) {
public new object this[ParameterRole role]
{
get
{
if (base.ContainsKey(role))
{
return base[role];
}
else
{
return null;
}
}
set
{
if (base.ContainsKey(role))
{
base[role] = value;
}
else
{
base.Add(role, value);
}
}
}
}
Its private member of the AppSettings class:
class AppSettings {
ParamContainer container = new ParamContainer();
public string FileName
{
get
{
return container[ParemeterRole.FileName] as string;
}
set
{
container[ParemeterRole.FileName] = value;
}
}
}
and for each settings there is a corresponding property, but it works not with a local variable, but adds/gets a value from the container.
Benefits:
You can work with parameters separately as named property, so as list (container.Keys, container.Values) - it's useful for SQL queries and XML based business logic.
Deficiencies:
Parameter values are stored as an object and it uses more memory as it could, I guess, if it was stored as its corresponding types.
What do you think about it? It's very interesting and important for me. Is it rubbish or could it be useful?
c#
edited 21 mins ago
Jamal♦
30.2k11116226
asked Dec 27 '08 at 10:30
abatishchev
255111
migrated from stackoverflow.com May 1 '12 at 2:09
This question came from our site for professional and enthusiast programmers.
The current question title, which states your concerns about the code, applies to too many questions on this site to be useful. The site standard is for the title to simply state the task accomplished by the code. Please see How to Ask for examples, and revise the title accordingly.
– Zeta
4 hours ago
@Zeta: the question is from 2008, was migrated in 2012, just got upvoted and I decided to give it a little better title. And yeah, I know, this is a stupid question.
– abatishchev
4 hours ago
Please take another look at that page Zeta mentioned- specifically the part that reads: "State what your code does in your title, not your main concerns about it.". Then please edit and give it a different title that describes what the code achieves.
– Sᴀᴍ Onᴇᴌᴀ
3 hours ago
add a comment |
I developed my next application: parameters storing paradigm.
There is an enum for each parameter roles:
enum ParameterRole
{
FileName,
FileDir
}
Parameters are contained in a special container as an object:
class ParamContainer : Dictionary(ParameterRole, object) {
public new object this[ParameterRole role]
{
get
{
if (base.ContainsKey(role))
{
return base[role];
}
else
{
return null;
}
}
set
{
if (base.ContainsKey(role))
{
base[role] = value;
}
else
{
base.Add(role, value);
}
}
}
}
Its private member of the AppSettings class:
class AppSettings {
ParamContainer container = new ParamContainer();
public string FileName
{
get
{
return container[ParemeterRole.FileName] as string;
}
set
{
container[ParemeterRole.FileName] = value;
}
}
}
and for each settings there is a corresponding property, but it works not with a local variable, but adds/gets a value from the container.
Benefits:
You can work with parameters separately as named property, so as list (container.Keys, container.Values) - it's useful for SQL queries and XML based business logic.
Deficiencies:
Parameter values are stored as an object and it uses more memory as it could, I guess, if it was stored as its corresponding types.
What do you think about it? It's very interesting and important for me. Is it rubbish or could it be useful?
c#
edited 21 mins ago
Jamal♦
30.2k11116226
asked Dec 27 '08 at 10:30
abatishchev
255111
I developed my next application: parameters storing paradigm.
There is an enum for each parameter roles:
enum ParameterRole
{
FileName,
FileDir
}
Parameters are contained in a special container as an object:
class ParamContainer : Dictionary(ParameterRole, object) {
public new object this[ParameterRole role]
{
get
{
if (base.ContainsKey(role))
{
return base[role];
}
else
{
return null;
}
}
set
{
if (base.ContainsKey(role))
{
base[role] = value;
}
else
{
base.Add(role, value);
}
}
}
}
Its private member of the AppSettings class:
class AppSettings {
ParamContainer container = new ParamContainer();
public string FileName
{
get
{
return container[ParemeterRole.FileName] as string;
}
set
{
container[ParemeterRole.FileName] = value;
}
}
}
and for each settings there is a corresponding property, but it works not with a local variable, but adds/gets a value from the container.
Benefits:
You can work with parameters separately as named property, so as list (container.Keys, container.Values) - it's useful for SQL queries and XML based business logic.
Deficiencies:
Parameter values are stored as an object and it uses more memory as it could, I guess, if it was stored as its corresponding types.
What do you think about it? It's very interesting and important for me. Is it rubbish or could it be useful?
c#
c#
edited 21 mins ago
Jamal♦
30.2k11116226
asked Dec 27 '08 at 10:30
abatishchev
255111
edited 21 mins ago
Jamal♦
30.2k11116226
asked Dec 27 '08 at 10:30
abatishchev
255111
edited 21 mins ago
Jamal♦
30.2k11116226
edited 21 mins ago
Jamal♦
30.2k11116226
edited 21 mins ago
Jamal♦
30.2k11116226
30.2k11116226
asked Dec 27 '08 at 10:30
abatishchev
255111
asked Dec 27 '08 at 10:30
abatishchev
255111
asked Dec 27 '08 at 10:30
abatishchev
255111
255111
migrated from stackoverflow.com May 1 '12 at 2:09
This question came from our site for professional and enthusiast programmers.
migrated from stackoverflow.com May 1 '12 at 2:09
This question came from our site for professional and enthusiast programmers.
The current question title, which states your concerns about the code, applies to too many questions on this site to be useful. The site standard is for the title to simply state the task accomplished by the code. Please see How to Ask for examples, and revise the title accordingly.
– Zeta
4 hours ago
@Zeta: the question is from 2008, was migrated in 2012, just got upvoted and I decided to give it a little better title. And yeah, I know, this is a stupid question.
– abatishchev
4 hours ago
Please take another look at that page Zeta mentioned- specifically the part that reads: "State what your code does in your title, not your main concerns about it.". Then please edit and give it a different title that describes what the code achieves.
– Sᴀᴍ Onᴇᴌᴀ
3 hours ago
add a comment |
The current question title, which states your concerns about the code, applies to too many questions on this site to be useful. The site standard is for the title to simply state the task accomplished by the code. Please see How to Ask for examples, and revise the title accordingly.
– Zeta
4 hours ago
@Zeta: the question is from 2008, was migrated in 2012, just got upvoted and I decided to give it a little better title. And yeah, I know, this is a stupid question.
– abatishchev
4 hours ago
Please take another look at that page Zeta mentioned- specifically the part that reads: "State what your code does in your title, not your main concerns about it.". Then please edit and give it a different title that describes what the code achieves.
– Sᴀᴍ Onᴇᴌᴀ
3 hours ago
The current question title, which states your concerns about the code, applies to too many questions on this site to be useful. The site standard is for the title to simply state the task accomplished by the code. Please see How to Ask for examples, and revise the title accordingly.
– Zeta
4 hours ago
The current question title, which states your concerns about the code, applies to too many questions on this site to be useful. The site standard is for the title to simply state the task accomplished by the code. Please see How to Ask for examples, and revise the title accordingly.
– Zeta
4 hours ago
@Zeta: the question is from 2008, was migrated in 2012, just got upvoted and I decided to give it a little better title. And yeah, I know, this is a stupid question.
– abatishchev
4 hours ago
@Zeta: the question is from 2008, was migrated in 2012, just got upvoted and I decided to give it a little better title. And yeah, I know, this is a stupid question.
– abatishchev
4 hours ago
Please take another look at that page Zeta mentioned- specifically the part that reads: "State what your code does in your title, not your main concerns about it.". Then please edit and give it a different title that describes what the code achieves.
– Sᴀᴍ Onᴇᴌᴀ
3 hours ago
Please take another look at that page Zeta mentioned- specifically the part that reads: "State what your code does in your title, not your main concerns about it.". Then please edit and give it a different title that describes what the code achieves.
– Sᴀᴍ Onᴇᴌᴀ
3 hours ago
add a comment |
1 Answer
1
active
oldest
votes
Well, the use of an enum (ParameterRole) doesn't make it particularly re-usable in different scenarios; you could express the key simply via generics (<T>). Other than that, it is a fairly standard lookup / property-bag. So a fairly common and established pattern. The get/set logic is over-complicated, too:
get
{
object value;
TryGetValue(role, out value);
return value;
}
set
{
base[role] = value;
}
Finally, I'm a little dubious about inheriting from Dictionary<,> here - I'd probably just encapsulate it instead (i.e. contain a private Dictionary<,> field, but not derive from it).
answered Dec 27 '08 at 15:50
Marc Gravell♦
39116
Do you think making an inheritance to simplify access to dictionary's value is bad idea? My idea was that you can just use an operator without checking presence of given key. A lot of code once, a few code every time you set/get a value
– abatishchev
Dec 27 '08 at 16:01
Well, just using the basic indexer risks it blowing up (key-not-found). Your bespoke indexer avoids this, but that works equally well for encapsulation or inheritance. Really, though, the question might as well be "is there a reason to expose this as inheritance" - I can't think of any off-hand.
– Marc Gravell♦
Dec 27 '08 at 16:10
add a comment |
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',
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%2fcodereview.stackexchange.com%2fquestions%2f11361%2fparameters-storing-paradigm%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
Well, the use of an enum (ParameterRole) doesn't make it particularly re-usable in different scenarios; you could express the key simply via generics (<T>). Other than that, it is a fairly standard lookup / property-bag. So a fairly common and established pattern. The get/set logic is over-complicated, too:
get
{
object value;
TryGetValue(role, out value);
return value;
}
set
{
base[role] = value;
}
Finally, I'm a little dubious about inheriting from Dictionary<,> here - I'd probably just encapsulate it instead (i.e. contain a private Dictionary<,> field, but not derive from it).
answered Dec 27 '08 at 15:50
Marc Gravell♦
39116
Do you think making an inheritance to simplify access to dictionary's value is bad idea? My idea was that you can just use an operator without checking presence of given key. A lot of code once, a few code every time you set/get a value
– abatishchev
Dec 27 '08 at 16:01
Well, just using the basic indexer risks it blowing up (key-not-found). Your bespoke indexer avoids this, but that works equally well for encapsulation or inheritance. Really, though, the question might as well be "is there a reason to expose this as inheritance" - I can't think of any off-hand.
– Marc Gravell♦
Dec 27 '08 at 16:10
add a comment |
Well, the use of an enum (ParameterRole) doesn't make it particularly re-usable in different scenarios; you could express the key simply via generics (<T>). Other than that, it is a fairly standard lookup / property-bag. So a fairly common and established pattern. The get/set logic is over-complicated, too:
get
{
object value;
TryGetValue(role, out value);
return value;
}
set
{
base[role] = value;
}
Finally, I'm a little dubious about inheriting from Dictionary<,> here - I'd probably just encapsulate it instead (i.e. contain a private Dictionary<,> field, but not derive from it).
answered Dec 27 '08 at 15:50
Marc Gravell♦
39116
Do you think making an inheritance to simplify access to dictionary's value is bad idea? My idea was that you can just use an operator without checking presence of given key. A lot of code once, a few code every time you set/get a value
– abatishchev
Dec 27 '08 at 16:01
Well, just using the basic indexer risks it blowing up (key-not-found). Your bespoke indexer avoids this, but that works equally well for encapsulation or inheritance. Really, though, the question might as well be "is there a reason to expose this as inheritance" - I can't think of any off-hand.
– Marc Gravell♦
Dec 27 '08 at 16:10
add a comment |
Well, the use of an enum (ParameterRole) doesn't make it particularly re-usable in different scenarios; you could express the key simply via generics (<T>). Other than that, it is a fairly standard lookup / property-bag. So a fairly common and established pattern. The get/set logic is over-complicated, too:
get
{
object value;
TryGetValue(role, out value);
return value;
}
set
{
base[role] = value;
}
Finally, I'm a little dubious about inheriting from Dictionary<,> here - I'd probably just encapsulate it instead (i.e. contain a private Dictionary<,> field, but not derive from it).
answered Dec 27 '08 at 15:50
Marc Gravell♦
39116
Well, the use of an enum (ParameterRole) doesn't make it particularly re-usable in different scenarios; you could express the key simply via generics (<T>). Other than that, it is a fairly standard lookup / property-bag. So a fairly common and established pattern. The get/set logic is over-complicated, too:
get
{
object value;
TryGetValue(role, out value);
return value;
}
set
{
base[role] = value;
}
Finally, I'm a little dubious about inheriting from Dictionary<,> here - I'd probably just encapsulate it instead (i.e. contain a private Dictionary<,> field, but not derive from it).
answered Dec 27 '08 at 15:50
Marc Gravell♦
39116
answered Dec 27 '08 at 15:50
Marc Gravell♦
39116
answered Dec 27 '08 at 15:50
Marc Gravell♦
39116
answered Dec 27 '08 at 15:50
Marc Gravell♦
39116
39116
Do you think making an inheritance to simplify access to dictionary's value is bad idea? My idea was that you can just use an operator without checking presence of given key. A lot of code once, a few code every time you set/get a value
– abatishchev
Dec 27 '08 at 16:01
Well, just using the basic indexer risks it blowing up (key-not-found). Your bespoke indexer avoids this, but that works equally well for encapsulation or inheritance. Really, though, the question might as well be "is there a reason to expose this as inheritance" - I can't think of any off-hand.
– Marc Gravell♦
Dec 27 '08 at 16:10
add a comment |
Do you think making an inheritance to simplify access to dictionary's value is bad idea? My idea was that you can just use an operator without checking presence of given key. A lot of code once, a few code every time you set/get a value
– abatishchev
Dec 27 '08 at 16:01
Well, just using the basic indexer risks it blowing up (key-not-found). Your bespoke indexer avoids this, but that works equally well for encapsulation or inheritance. Really, though, the question might as well be "is there a reason to expose this as inheritance" - I can't think of any off-hand.
– Marc Gravell♦
Dec 27 '08 at 16:10
Do you think making an inheritance to simplify access to dictionary's value is bad idea? My idea was that you can just use an operator without checking presence of given key. A lot of code once, a few code every time you set/get a value
– abatishchev
Dec 27 '08 at 16:01
Do you think making an inheritance to simplify access to dictionary's value is bad idea? My idea was that you can just use an operator without checking presence of given key. A lot of code once, a few code every time you set/get a value
– abatishchev
Dec 27 '08 at 16:01
Well, just using the basic indexer risks it blowing up (key-not-found). Your bespoke indexer avoids this, but that works equally well for encapsulation or inheritance. Really, though, the question might as well be "is there a reason to expose this as inheritance" - I can't think of any off-hand.
– Marc Gravell♦
Dec 27 '08 at 16:10
Well, just using the basic indexer risks it blowing up (key-not-found). Your bespoke indexer avoids this, but that works equally well for encapsulation or inheritance. Really, though, the question might as well be "is there a reason to expose this as inheritance" - I can't think of any off-hand.
– Marc Gravell♦
Dec 27 '08 at 16:10
add a comment |
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.
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%2fcodereview.stackexchange.com%2fquestions%2f11361%2fparameters-storing-paradigm%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
The current question title, which states your concerns about the code, applies to too many questions on this site to be useful. The site standard is for the title to simply state the task accomplished by the code. Please see How to Ask for examples, and revise the title accordingly.
– Zeta
4 hours ago
@Zeta: the question is from 2008, was migrated in 2012, just got upvoted and I decided to give it a little better title. And yeah, I know, this is a stupid question.
– abatishchev
4 hours ago
Please take another look at that page Zeta mentioned- specifically the part that reads: "State what your code does in your title, not your main concerns about it.". Then please edit and give it a different title that describes what the code achieves.
– Sᴀᴍ Onᴇᴌᴀ
3 hours ago