nested class in lieu of private fields

[Guest]

I'm perusing a class that seems to utilize a nested class for private
fields. In a nutshell, it looks as follows:

public class Foo
{
public Property1
{
get/set Bar.field1
}

public Property2
{
get/set Bar.field2
}

public class Bar
{
public field1;
public field2;
}
}

1. I've never seen a technique like this. What's the big idea of lumping
"private" fields in a nested class?

2. If it is a big idea, wouldn't a struct be better than a class?

Thank you.

 

[Jon Skeet [C# MVP]]

I'm perusing a class that seems to utilize a nested class for private
fields. In a nutshell, it looks as follows:

public class Foo
{
public Property1
{
get/set Bar.field1
}

public Property2
{
get/set Bar.field2
}

public class Bar
{
public field1;
public field2;
}
}

That won't work as written though - because you've got instance fields
of Bar, but you're accessing them as if they were static fields.

Does Foo have an instance of Bar, by any chance?

1. I've never seen a technique like this. What's the big idea of lumping
"private" fields in a nested class?

I've used this idea once, to configure a class. It worked like this:

1) I want to be able to configure an object, and there are lots of
configuration options.
2) I don't want the options to be changed after the object is
initialized.
3) There are enough options that I don't want to have to specify each
of them individually in a constructor call - properties are much
cleaner.

I created the nested class, giving it mutable properties with some
validation. The "main" class then took an instance of the nested class
as a constructor parameter, and cloned it. I could then refer to my own
private copy of the configuration, knowing that I'd never change it
within my class. The code constructing the instance could go on to
change the configuration object they passed into the constructor if
they wanted, but that would make no odds after I'd created a copy.

2. If it is a big idea, wouldn't a struct be better than a class?

That really depends on the usage, to be honest. Could you give us more
information about where you've seen it?

 

[Guest]

That won't work as written though - because you've got instance fields

Jon, I said "In a nutshell."

Could you give us more
information about where you've seen it?

http://www.codeplex.com/MyWebPagesStarterKit

My Web Pages Starter Kit 1.1.1 (doesn't seem available any longer)

MyWebPagesStarterKit_1.1.1\App_Code\WebSite.cs

 

[John]

I'm perusing a class that seems to utilize a nested class for private
fields. In a nutshell, it looks as follows:

1. I've never seen a technique like this. What's the big idea of lumping
"private" fields in a nested class?

This sounds to me like the Handle/Body pattern (Bridge pattern) that
allows you to detach/abstract the actual data from the interface to
that data so the two can independently vary from each other. I am
paraphrasing here so please allow me to illustrate. I recently
implemented classes similar to this but rather than go into all of the
intricacies of that project let's explore something a bit lighter.

class DataSurrogate
{
public Data (string name)
{
this.name = name;
this.id = Guid.NewGuid();
}
string name;
Guid id;
public string Name { get { return this.name; } set { this.name =
value; } }
public Guid { get { return this.id; } }
}

class DataUser
{
DataSurrogate data;
public DataUser(string name)
{
this.data = new Data(name);
}

public string Name { get { return (this.data == null) ? "Default
Name" : this.data.Name; } }

public DataSurrogate ReplaceData(DataSurrogate newData)
{
DataSurrogate oldData = this.data;
this.data = newData;
return oldData;
}
}

Now, obviously the above example is hardly useful but with it you
should be able to see how easy it is slide the underlying data in and
out of the containing object without having to recreate it. There are
a number of uses I can think of but a very convenient one is for
testing a variety of data values. Consider also a more complex data
surrogate wherein other classes are also using the same surrogate
object. Assume also you have a data provider that can arbitrarily
change all of the data in one operation. This pattern would allow you
to change that data without having to also recreate and reinitialize
all of the classes that depend on it.

2. If it is a big idea, wouldn't a struct be better than a class?

Sure, why not? Depending on the data you are abstracting a struct
would be just fine and potentially better suited to the situation.

Thank you.

I hope my explaination did not confuse matters any worse.

John

 

[Jon Skeet [C# MVP]]

Jon, I said "In a nutshell."

Yes, but unfortunately the sample removed vital missing information
about how it could possibly work.

http://www.codeplex.com/MyWebPagesStarterKit

My Web Pages Starter Kit 1.1.1 (doesn't seem available any longer)

MyWebPagesStarterKit_1.1.1\App_Code\WebSite.cs

Right - it looks like the point in this case is for the nested class to
represent the persistable state of the site, used in the declaration of
the class:
public class WebSite : Persistable<WebSite.WebSiteData>