Can a 'ref' parameter be saved for later use?

[Helmut Giese]

Hello out there,
I am passing a string[] to a form's constructor, it gets displayed in
a ListBox, the user can change it and in the end I want it back.

I have a solution I don't particularly like and thought about using a
'ref' parameter. Inside a function I can use it to 'pass back' data -
but in this scenario the 'passing back' will have to happen later. So
I thought I could declare a (normal) variable to be a 'ref' - but the
compiler doesn't like it.

// class variables
ref string[] strLstFromCaller; // compiler error

Form(ref string[] strLst) {
// save the reference to strLst "somehow"
strLstFromCaller = strLst;
}

btnClose_Click(...) {
// get the (possibly changed) ListBox's content
...
// and return it to the caller via strLstFromCaller
}

In C or C++ (where I come from) one would just use a pointer and go on
but here I wonder: How could I achieve what I want in C#?

Any insight wll be greatly appreciated.
Best regards
Helmut Giese

 

[Scott M.]

Hello out there,
I am passing a string[] to a form's constructor, it gets displayed in
a ListBox, the user can change it and in the end I want it back.

I have a solution I don't particularly like and thought about using a
'ref' parameter. Inside a function I can use it to 'pass back' data -
but in this scenario the 'passing back' will have to happen later. So
I thought I could declare a (normal) variable to be a 'ref' - but the
compiler doesn't like it.

// class variables
ref string[] strLstFromCaller; // compiler error

Form(ref string[] strLst) {
// save the reference to strLst "somehow"
strLstFromCaller = strLst;
}

btnClose_Click(...) {
// get the (possibly changed) ListBox's content
...
// and return it to the caller via strLstFromCaller
}

In C or C++ (where I come from) one would just use a pointer and go on
but here I wonder: How could I achieve what I want in C#?

Any insight wll be greatly appreciated.
Best regards
Helmut Giese

You can't declare a variable as ref. You can delcare a paramer as ref and
then use the ref keyword when supplying that parameter via the method call.

You have 3 options as I see it:

1. Forget about ref althogether and just have the data stored in a class
field.
2. Go ahead and use ref, just use it properly
3. Use the C# out parameter syntax, which allows for a method to effectively
return more than one value.

From your description though, I think choice #1 is the best for you.

-Scott

 

[Peter Duniho]

Hello out there,
I am passing a string[] to a form's constructor, it gets displayed in
a ListBox, the user can change it and in the end I want it back.

I have a solution I don't particularly like and thought about using a
'ref' parameter. Inside a function I can use it to 'pass back' data -
but in this scenario the 'passing back' will have to happen later. So
I thought I could declare a (normal) variable to be a 'ref' - but the
compiler doesn't like it.

// class variables
ref string[] strLstFromCaller; // compiler error

Form(ref string[] strLst) {
// save the reference to strLst "somehow"
strLstFromCaller = strLst;
}

btnClose_Click(...) {
// get the (possibly changed) ListBox's content
...
// and return it to the caller via strLstFromCaller
}

In C or C++ (where I come from) one would just use a pointer and go on
but here I wonder: How could I achieve what I want in C#?

I agree with Scott's suggestion, and will go a bit further and suggest
that your proposal seems to be a fundamental misuse of passing by
reference, even if you could get it to work (which in C# you can't).

Even in C/C++ it's a dangerous thing to capture a pointer to some data
and save it for reuse later. You have to be very clear to client code
about what kind of pointer they can pass to you, lest they pass you a
pointer to something on the stack, or to an object that is going to be
freed before your own code's use of the pointer.

C# just doesn't let you get into that situation by default. Instead, it
strongly encourages you to use a more maintainable pattern, such as
using some kind of container class like Scott suggested. And I agree,
you should follow that encouragement.

Note that in .NET, there are a number of alternatives for dealing with
deferred or asynchronous processing. So if you would care to be more
specific about what you're _really_ trying to do (i.e. under what
circumstances do you "want it back", with respect to the array passed to
your form, and why is it insufficient to allow the form to modify the
array itself so that your code can later observe changes to it...not
that I'm a big fan of _that_ approach either, but at least it works
directly in C#), as opposed to your chosen attempt at a mechanism for
accomplishing that, you may get better advice than just "don't do that".

Pete

 

[Harlan Messinger]

Hello out there,
I am passing a string[] to a form's constructor, it gets displayed in
a ListBox, the user can change it and in the end I want it back.

I have a solution I don't particularly like and thought about using a
'ref' parameter. Inside a function I can use it to 'pass back' data -
but in this scenario the 'passing back' will have to happen later. So
I thought I could declare a (normal) variable to be a 'ref' - but the
compiler doesn't like it.

// class variables
ref string[] strLstFromCaller; // compiler error

Right, you can't just invent new syntax and expect it magically to do
something.

Form(ref string[] strLst) {
// save the reference to strLst "somehow"
strLstFromCaller = strLst;
}

btnClose_Click(...) {
// get the (possibly changed) ListBox's content
...
// and return it to the caller via strLstFromCaller
}

Create a public property "get" for the *form* that returns the current
text value of the list box. Then the object that wants that value needs
to have a method that retrieves that value, and the same object needs to
add that method to the form's Closing event.

 

[Helmut Giese]

Hi Scott, Harlan and Peter,
thank you for your comments.

I'll try to re-phrase the scenario:
I have several sets of key-value pairs where the user should be able
to change the values. So I created a form with 2 listboxes (one for
the keys, one for the values) where the user can change the values to
his heart's delight. Once he is done (clicking on 'Ok' and thereby
closing the form) I need a way to communicate the (possibly changed)
values back.
@ Peter: That's what I meant with 'I want it back'

What I did to get it working:
- pass the 'main form' as an additional parameter to the 'secondary
form's' constructor,
- pass an additional parameter as a flag identifying the current set,
and
- when the 'secondary form' closes via 'ok' it _directly_ updates the
variable in the 'main form', where the set came from (using the flag
to determine which one).
Works, no problem.

However, I am a big fan of loose coupling and in seeing that my
secondary form needed to know the main form _and_ the names of certain
variables there, I was just wondering if something could be done about
it.
In my C++ past the secondary form would have received the data thru a
pointer, would update it on closing and wouldn't need to know nor care
who called it - loose coupling.

I use situations like these to improve my understanding of C# (you may
have guessed that it is quite new to me). So I tried the
// class variables
ref string[] strLstFromCaller; // compiler error
from the (naive) assumption that if you can have 'ref' parameters
maybe you can also have 'ref' variables. Ok, you cannot - now I know.

@Harlan:

Right, you can't just invent new syntax and expect it magically to do
something.

Yes, I know.

@Scott: I will stick to #1 - this is what I have right now, it's
working, and apparently coupling cannot be avoided. So be it.

Thanks again for your thoughts and comments and best regards
Helmut Giese

Hello out there,
I am passing a string[] to a form's constructor, it gets displayed in
a ListBox, the user can change it and in the end I want it back.

I have a solution I don't particularly like and thought about using a
'ref' parameter. Inside a function I can use it to 'pass back' data -
but in this scenario the 'passing back' will have to happen later. So
I thought I could declare a (normal) variable to be a 'ref' - but the
compiler doesn't like it.

// class variables
ref string[] strLstFromCaller; // compiler error

Form(ref string[] strLst) {
// save the reference to strLst "somehow"
strLstFromCaller = strLst;
}

btnClose_Click(...) {
// get the (possibly changed) ListBox's content
...
// and return it to the caller via strLstFromCaller
}

In C or C++ (where I come from) one would just use a pointer and go on
but here I wonder: How could I achieve what I want in C#?

Any insight wll be greatly appreciated.
Best regards
Helmut Giese

 

[Peter Duniho]

Hi Scott, Harlan and Peter,
thank you for your comments.

I'll try to re-phrase the scenario:
I have several sets of key-value pairs where the user should be able
to change the values. So I created a form with 2 listboxes (one for
the keys, one for the values) where the user can change the values to
his heart's delight. Once he is done (clicking on 'Ok' and thereby
closing the form) I need a way to communicate the (possibly changed)
values back.
@ Peter: That's what I meant with 'I want it back'

What I did to get it working:
- pass the 'main form' as an additional parameter to the 'secondary
form's' constructor,

Is the "secondary form" the "form with 2 listboxes"?

What is the main form? What is its concern regarding the data, and the
values specified by the user?

- pass an additional parameter as a flag identifying the current set,
and

What do you mean by "flag identifying the current set"? Typically,
"flag" implies a boolean value. How does a boolean value identify a
"current set", and what is the "current set"? Do you mean the values
for the keys as they are currently set? Or something else?

- when the 'secondary form' closes via 'ok' it _directly_ updates the
variable in the 'main form', where the set came from (using the flag
to determine which one).
Works, no problem.

Assuming that the "secondary form" is the one with the ListBox controls
where the user can modify the values for the keys, and the main form is
some class that for some reason uses these key/value associations, I
agree...having the secondary form have any specific knowledge of the
main form is a poor design.

So, your goal of "loose coupling" is valid. But, as I mentioned, the
storing of pointers a la C/C++ has its own significant maintenance and
code correctness problems. You should be looking for a solution that
avoids "coupling" as well as works within C#'s own idioms for addressing
what in C/C++ would be implemented by storing a pointer to some variable
or object.

[...]
@Scott: I will stick to #1 - this is what I have right now, it's
working, and apparently coupling cannot be avoided. So be it.

It's not clear to me why Scott's suggestion necessarily implies
"coupling". The reference you provide to the secondary form need not be
of the main form at all. Nor is it clear from your description that the
secondary form need to be provided _any_ reference to _any_ data
structure by the main form. Instead, the main form could simply query
the new state when the secondary form is closed. The secondary form can
represent that new state in whatever form is convenient, including the
same form (but not necessarily the same instance of an object) as was
used during the initialization of the secondary form.

You can (to name some options):

-- declare and use some mutable intermediary class instance in
which the data being passed is stored; the secondary form modifies the
data in that intermediary class, and those changes are visible to the
main form

-- declare and use some (possibly immutable) intermediary class, an
instance of which is used to initialized the secondary form, and a
second instance of which is used to provide the new values back to the
main form (e.g. via a property)

-- expose each key/value individually as a property, and allow the
main form to retrieve them explicitly

Without knowing more about what kind of data exactly you're dealing with
and how the user might modify it (a concise-but-complete code example
would really be helpful), it's impossible to provide some exact advice.
But I can tell you that you definitely should not need to have
"coupling" between your main form and your secondary form. It's just a
matter of getting the design right.

Pete

 

[Scott M.]

Hi Scott, Harlan and Peter,
thank you for your comments.

I'll try to re-phrase the scenario:
I have several sets of key-value pairs where the user should be able
to change the values. So I created a form with 2 listboxes (one for
the keys, one for the values) where the user can change the values to
his heart's delight. Once he is done (clicking on 'Ok' and thereby
closing the form) I need a way to communicate the (possibly changed)
values back.
@ Peter: That's what I meant with 'I want it back'

What I did to get it working:
- pass the 'main form' as an additional parameter to the 'secondary
form's' constructor,
- pass an additional parameter as a flag identifying the current set,
and
- when the 'secondary form' closes via 'ok' it _directly_ updates the
variable in the 'main form', where the set came from (using the flag
to determine which one).
Works, no problem.

However, I am a big fan of loose coupling and in seeing that my
secondary form needed to know the main form _and_ the names of certain
variables there, I was just wondering if something could be done about
it.
In my C++ past the secondary form would have received the data thru a
pointer, would update it on closing and wouldn't need to know nor care
who called it - loose coupling.

I use situations like these to improve my understanding of C# (you may
have guessed that it is quite new to me). So I tried the
// class variables
ref string[] strLstFromCaller; // compiler error
from the (naive) assumption that if you can have 'ref' parameters
maybe you can also have 'ref' variables. Ok, you cannot - now I know.

@Harlan:

Right, you can't just invent new syntax and expect it magically to do
something.

Yes, I know.

@Scott: I will stick to #1 - this is what I have right now, it's
working, and apparently coupling cannot be avoided. So be it.

Thanks again for your thoughts and comments and best regards
Helmut Giese

Hello out there,
I am passing a string[] to a form's constructor, it gets displayed in
a ListBox, the user can change it and in the end I want it back.

I have a solution I don't particularly like and thought about using a
'ref' parameter. Inside a function I can use it to 'pass back' data -
but in this scenario the 'passing back' will have to happen later. So
I thought I could declare a (normal) variable to be a 'ref' - but the
compiler doesn't like it.

// class variables
ref string[] strLstFromCaller; // compiler error

Form(ref string[] strLst) {
// save the reference to strLst "somehow"
strLstFromCaller = strLst;
}

btnClose_Click(...) {
// get the (possibly changed) ListBox's content
...
// and return it to the caller via strLstFromCaller
}

In C or C++ (where I come from) one would just use a pointer and go on
but here I wonder: How could I achieve what I want in C#?

Any insight wll be greatly appreciated.
Best regards
Helmut Giese

Why not create a Console application, that has it's own class (Program) that
does not expose any visual interface to the end-user. This class does have
a method named "Main", which is the automatic starting point for the
program.

If you add a reference to System.Windows.Forms.dll to this project, you can
make normal Windows Forms in this project.

Now, if you were to simply create your String variables for the keys/values
(or even a more suited type like a System.Collections.Generic.Dictionary)
here, it would be in scope for the entire duration of your application and
accessible from any forms you may create. Closing one form would have no
bearing on this data and Form1 doesn't need to have any tight-coupling with
Form2.

-Scott

 

[Helmut Giese]

Hi Peter, hi Scott,
I happened to see your responses (and I appreciate them) but it's
22:30 over here and - well, it's time to go.
I'll be back tomorrow.
By
Helmut Giese

 

[Peter Duniho]

Why not create a Console application, that has it's own class (Program) that
does not expose any visual interface to the end-user. This class does have
a method named "Main", which is the automatic starting point for the
program.

A plain Windows Forms project has the exact same "Program" class and
static "Program.Main()" method.

If you add a reference to System.Windows.Forms.dll to this project, you can
make normal Windows Forms in this project.

Now, if you were to simply create your String variables for the keys/values
(or even a more suited type like a System.Collections.Generic.Dictionary)
here, it would be in scope for the entire duration of your application and
accessible from any forms you may create. Closing one form would have no
bearing on this data and Form1 doesn't need to have any tight-coupling with
Form2.

To do what you suggest, Helmut could just implement it with a normal
Windows Forms project, without the added complication or visual
distraction (console window) of a console application.

That said, what you're suggesting is essentially to create a global
variable (inasmuch as you can have global variables in C#...technically,
all variables are scoped at least statically in a class) in the Program
class (presumably as a static member), shared by both the main form and
secondary form.

I would strongly recommend against this approach. Global data should be
avoided except where absolutely necessary, and while we still have very
little specific information on what Helmut is trying to do, it's clear
enough that there are plenty of alternatives that don't involve global data.

Pete

 

[Scott M.]

A plain Windows Forms project has the exact same "Program" class and
static "Program.Main()" method.

To do what you suggest, Helmut could just implement it with a normal
Windows Forms project, without the added complication or visual
distraction (console window) of a console application.

That said, what you're suggesting is essentially to create a global
variable (inasmuch as you can have global variables in C#...technically,
all variables are scoped at least statically in a class) in the Program
class (presumably as a static member), shared by both the main form and
secondary form.

ACK. I use VB .NET more often and in a VB .NET WinForms project, you don't
get this. Didn't realize C# gives you this for free.

I would strongly recommend against this approach. Global data should be
avoided except where absolutely necessary, and while we still have very
little specific information on what Helmut is trying to do, it's clear
enough that there are plenty of alternatives that don't involve global
data.

If the OP wants to avoid coupling the forms with the data, then the data
will have to reside outside of the forms. Sure, you could create a 3rd
class to hold the data and pass references around or make the class have
static members. But, now you'll have to weigh the pros and cons of adding
complexity to the application that may not be needed where simple global
data will work.

Yes, you're correct that you shouldn't just make stuff global for the sake
of it, but there are certainly reasons to do it.

-Scott

 

[Peter Duniho]

[...]

I would strongly recommend against this approach. Global data should be
avoided except where absolutely necessary, and while we still have very
little specific information on what Helmut is trying to do, it's clear
enough that there are plenty of alternatives that don't involve global
data.

If the OP wants to avoid coupling the forms with the data, then the data
will have to reside outside of the forms.

That depends on your definition of "coupling". It's not true for my
definition of "coupling". For example, do you consider the two types in
the following example "coupled"?

In this example:

class A
{
public DoSomething()
{
B b = new B(0);

b.DoSomething();
Console.WriteLine(b.I);
}
}

class B
{
private int _i;

public B(int i)
{
_i = i;
}

public DoSomething()
{
I++;
}

public int I
{
get { return _i; }
private set { _i = value; }
}
}

or even this:

class A
{
public DoSomething()
{
B b = new B(0);

b.PropertyIChanged += delegate()
{
Console.WriteLine(b.I);
}

b.DoSomething();
}
}

class B
{
private int _i;

public B(int i)
{
_i = i;
}

public DoSomething()
{
I++;
}

public int I
{
get { return _i; }
private set
{
_i = value;
_RaisePropertyIChanged();
}
}

public event Action PropertyIChanged = delegate() { };

private void _RaisePropertyIChanged()
{
PropertyIChanged();
}
}

I wouldn't consider classes A and B coupled in either example. In the
first example, A is simply a client of B, and B knows nothing at all
about A. Even in the second, while B has a reference to A after the
event handler is subscribed, B still has no specific knowledge of the
class A.

And yet, in both examples, A clearly can access data shared by A and B,
even as that data is retained solely by B. There's no specific need to
create yet another type to mediate the storage of the shared data.

Which is not to say that doing so can't be beneficial in some
situations. It's just that it's not _required_ as a mechanism to avoid
both coupling and global data structures.

Again, without knowing more specifics about Helmut's question it's
difficult to say. But so far, he's shared no information that would
suggest that a global data structure is somehow required, or even
beneficial, in his scenario.

Pete

 

[Scott M.]

[...]

I would strongly recommend against this approach. Global data should be
avoided except where absolutely necessary, and while we still have very
little specific information on what Helmut is trying to do, it's clear
enough that there are plenty of alternatives that don't involve global
data.

If the OP wants to avoid coupling the forms with the data, then the data
will have to reside outside of the forms.

That depends on your definition of "coupling". It's not true for my
definition of "coupling". For example, do you consider the two types in
the following example "coupled"?

In this example:

class A
{
public DoSomething()
{
B b = new B(0);

b.DoSomething();
Console.WriteLine(b.I);
}
}

class B
{
private int _i;

public B(int i)
{
_i = i;
}

public DoSomething()
{
I++;
}

public int I
{
get { return _i; }
private set { _i = value; }
}
}

or even this:

class A
{
public DoSomething()
{
B b = new B(0);

b.PropertyIChanged += delegate()
{
Console.WriteLine(b.I);
}

b.DoSomething();
}
}

class B
{
private int _i;

public B(int i)
{
_i = i;
}

public DoSomething()
{
I++;
}

public int I
{
get { return _i; }
private set
{
_i = value;
_RaisePropertyIChanged();
}
}

public event Action PropertyIChanged = delegate() { };

private void _RaisePropertyIChanged()
{
PropertyIChanged();
}
}

I wouldn't consider classes A and B coupled in either example. In the
first example, A is simply a client of B, and B knows nothing at all about
A. Even in the second, while B has a reference to A after the event
handler is subscribed, B still has no specific knowledge of the class A.

And yet, in both examples, A clearly can access data shared by A and B,
even as that data is retained solely by B. There's no specific need to
create yet another type to mediate the storage of the shared data.

Which is not to say that doing so can't be beneficial in some situations.
It's just that it's not _required_ as a mechanism to avoid both coupling
and global data structures.

Again, without knowing more specifics about Helmut's question it's
difficult to say. But so far, he's shared no information that would
suggest that a global data structure is somehow required, or even
beneficial, in his scenario.

Pete

IMHO, rather than argue the merits of coupling definitions, we could look at
what I brought up in my last post, which was the tradeoff between the desire
for loose coupling and the complexity of the code. While your code may, in
fact solve the coupling issue (or get around it), it does make the code more
complex.

Working just from what the OP presented, I see no reason why a "global" data
store (such as a Dictionary) wouldn't be a perfect solution. After all, a
database is the ultimate 'global' data repository. In this scenario (as it
has been presented), it seems that really a 'global' data store is what the
OP is looking for. Of course, a database, in this case, would be overkill.

-Scott

-Scott

 

[Christoph Basedau]

I'll try to re-phrase the scenario:
I have several sets of key-value pairs where the user should be able
to change the values. So I created a form with 2 listboxes (one for
the keys, one for the values) where the user can change the values to
his heart's delight. Once he is done (clicking on 'Ok' and thereby
closing the form) I need a way to communicate the (possibly changed)
values back.

So you have (sth like) a dictionary, at least an object that holds
name-value pairs.
So why not pass the dictionary-alike container to the form's c'tor,
or some other initial routine, bind it to the control(s), let or let
not the data be edited and ... you're fine.
You don't even have to pass it by ref, as long as it's asserted that
only the items are modified and not the dic itself is replaced.
Also you don't have to get headaches from worrying about how to
copy the items back.
The changes are directly available on the calling side.
That's because they belong to a ref-type, so your initial keyword
'ref' was pretty close.

Seems some of these advanced C++-skills tend to obstruct
a clear view on the simple and orderly .NET world ;-)

Christoph

 

[Peter Duniho]

IMHO, rather than argue the merits of coupling definitions, we could look at
what I brought up in my last post, which was the tradeoff between the desire
for loose coupling and the complexity of the code. While your code may, in
fact solve the coupling issue (or get around it), it does make the code more
complex.

You've simply shifted the discussion from the definition of "coupled" to
the definition of "complex".

The fact is, global data structures add a kind of complexity that can be
very hard to manage. That, as opposed to the kind of complexity added
when you create abstractions in classes to manage the same kind of data.
The abstractions have their own complexity, but (properly done) they
eliminate the issues of side-effects and visibility, just to name a
couple of major maintenance problems with global data structures.

In terms of maintenance and code correctness, global data structures
_add_ complexity, not reduce it.

Working just from what the OP presented, I see no reason why a "global" data
store (such as a Dictionary) wouldn't be a perfect solution.

Because, barring specific evidence that it _should_ be used (and we have
none from the OP at this point), global data structures are never "a
perfect solution".

After all, a
database is the ultimate 'global' data repository. In this scenario (as it
has been presented), it seems that really a 'global' data store is what the
OP is looking for. [...]

All that the OP has asked for so far is a mechanism for one of his form
classes to communicate user input to another of his form classes.
There's nothing about that at all that suggests a global data structure.

Pete

 

[Göran Andersson]

Hello out there,
I am passing a string[] to a form's constructor, it gets displayed in
a ListBox, the user can change it and in the end I want it back.

I have a solution I don't particularly like and thought about using a
'ref' parameter. Inside a function I can use it to 'pass back' data -
but in this scenario the 'passing back' will have to happen later. So
I thought I could declare a (normal) variable to be a 'ref' - but the
compiler doesn't like it.

I think that you are confusing reference types with ref parameters. If
you are passing a (mutable) reference type to a method there is no need
for the ref keyword to change it's content. It's only if you need access
to the actual variable passed to the method that you need the ref
keyword, and for a reference type this would only be needed if you want
to replace the object with a completely new object.

// class variables
ref string[] strLstFromCaller; // compiler error

Just declare a regular reference variable:

string[] strLstFromCaller;

Form(ref string[] strLst) {

As you are not going to replace the array with a completely new array,
there is no need for the ref keyword at all. Just pass the parameter as
usual, and you get a reference to the array:

Form(string[] strLst)

// save the reference to strLst "somehow"
strLstFromCaller = strLst;
}

btnClose_Click(...) {
// get the (possibly changed) ListBox's content
...
// and return it to the caller via strLstFromCaller
}

In C or C++ (where I come from) one would just use a pointer and go on
but here I wonder: How could I achieve what I want in C#?

An object reference is actually implemented as a pointer, so it works
pretty much the same. When you pass a reference type as parameter in C#
you are passing a copy of the reference to the object, so that's
practically the same as passing a pointer in C.

 

[Harlan Messinger]

IMHO, rather than argue the merits of coupling definitions, we could look at
what I brought up in my last post, which was the tradeoff between the desire
for loose coupling and the complexity of the code. While your code may, in
fact solve the coupling issue (or get around it), it does make the code more
complex.

Working just from what the OP presented, I see no reason why a "global" data
store (such as a Dictionary) wouldn't be a perfect solution.

Mostly because it's overkill, and it's clunky. You could theoretically
implement *every* class as a Dictionary or something derived from one,
just as in a database you could theoretically replace the entire set of
tables with a single lookup table.

Your main form from has, what, three values, and wants to know if it
should use those values or replace them? So it has to provide those
values to something, and it has to get three values from something. That
scenario calls for an interface with three read/write properties to hold
those values. You can't get any less coupled than that.

Now, that value setter/getter can implement itself however it wants, and
if it wants to do it by displaying those value in a form and giving a
user a chance to replace them, that's entirely it's business; it is of
no concern to the main form. In other words, implementing the
setter/getter interface via a class that inherits from Form and that
also implements the getter/setter properties creates no new coupling.

After all, a
database is the ultimate 'global' data repository.

Mmm, not from the point of view of a strict object-oriented application,
where a connection or link or handle to a database would normally be
held in a local variable or class member.

 

[Scott M.]

Mostly because it's overkill, and it's clunky. You could theoretically
implement *every* class as a Dictionary or something derived from one,
just as in a database you could theoretically replace the entire set of
tables with a single lookup table.

I'm not sure I follow this. To store key/value pairs is exactly what the
Dictionary was made for. Sure, theoretically, you could use it for other
things, but that is not the case here.

Your main form from has, what, three values, and wants to know if it
should use those values or replace them? So it has to provide those values
to something, and it has to get three values from something. That scenario
calls for an interface with three read/write properties to hold those
values. You can't get any less coupled than that.

Ok. A Dictionary provides access to its data via properties...

Now, that value setter/getter can implement itself however it wants, and
if it wants to do it by displaying those value in a form and giving a user
a chance to replace them, that's entirely it's business; it is of no
concern to the main form. In other words, implementing the setter/getter
interface via a class that inherits from Form and that also implements the
getter/setter properties creates no new coupling.

Yes. Neither does a Dictionary.

Mmm, not from the point of view of a strict object-oriented application,
where a connection or link or handle to a database would normally be held
in a local variable or class member.

I think you are getting "global" and "coupling" confused. What you are
describing is how a database would be coupled with an application through a
variable. That doesn't change the fact that to store data in a store that is
as "globally" available as possible, you'd store it outside the application.
That was my point.

-Scott

 

[Harlan Messinger]

I'm not sure I follow this. To store key/value pairs is exactly what the
Dictionary was made for. Sure, theoretically, you could use it for other
things, but that is not the case here.

To store a fixed set of structured, object-oriented, compiler-checked
key/value pairs in a type-safe manner (the items don't all even have to
be the same type) is what classes were made for. You don't have a
situation where you never know what keys you're going to get values for,
calling for a Dictionary to store whatever you got. You know that you're
always going to get strings called Thing1 and Thing2 and an int called
Thing3, so you define a class or an interface with string properties
called Thing1 and Thing2 and an int property called Thing3. Why would
you go through the overhead, not to mention the pointless indirection,
of creating a Dictionary for this?

 

[Scott M.]

To store a fixed set of structured, object-oriented, compiler-checked
key/value pairs in a type-safe manner (the items don't all even have to be
the same type) is what classes were made for. You don't have a situation
where you never know what keys you're going to get values for, calling for
a Dictionary to store whatever you got. You know that you're always going
to get strings called Thing1 and Thing2 and an int called Thing3, so you
define a class or an interface with string properties called Thing1 and
Thing2 and an int property called Thing3. Why would you go through the
overhead, not to mention the pointless indirection, of creating a
Dictionary for this?

I fail to see how the, created from scratch, class that you describe is any
more efficient, or takes any less overhead than a BCL class that was
designed to do exactly what the OP is asking for.

-Scott