Understanding protected and its use with collections

[Magnus.Moraberg]

Hi,

I am a newbie to C# and I have a simple question for you. I have the
following two classes which are used to present information in Excel.

public class Environment : ICloneable, IComparable
{
readonly string name;
readonly int id; // the id of this env
with respect to the env sql table

public int LeftmostCell; // The column number in
Excel

...
}

public class Environments : IEnumerable, ICloneable
{
TestEnvironment[] testEnvironments;

void EstablishExcelLocations()
{
...
}

The function EstablishExcelLocations sets the values of LeftmostCell.
The problem I have is that I have to make LeftmostCell public and it
can now be set from anywhere.
When I derive a class, I often use protected to ensure that only the
derived class can access a certain property. But in this case I'm not
deriving, but it still feels to me that Environments comes from
Environment. Do you understand what I mean? It feels like Environments
should be able to access "protected" members in Environment.

Is there a better way of implementing the above if I don't want to
expose LeftmostCell?

Thanks,

Barry

[KWienhold]

On 20 Aug., 11:06, [e-mail] wrote:

Hi,

I am a newbie to C# and I have a simple question for you. I have the
following two classes which are used to present information in Excel.

public class Environment : ICloneable, IComparable
{
readonly string name;
readonly int id; // the id of this env
with respect to the env sql table

public int LeftmostCell; // The column number in
Excel

...
}

public class Environments : IEnumerable, ICloneable
{
TestEnvironment[] testEnvironments;

void EstablishExcelLocations()
{
...
}

The function EstablishExcelLocations sets the values of LeftmostCell.
The problem I have is that I have to make LeftmostCell public and it
can now be set from anywhere.
When I derive a class, I often use protected to ensure that only the
derived class can access a certain property. But in this case I'm not
deriving, but it still feels to me that Environments comes from
Environment. Do you understand what I mean? It feels like Environments
should be able to access "protected" members in Environment.

Is there a better way of implementing the above if I don't want to
expose LeftmostCell?

Thanks,

Barry

If both classes reside within the same assembly, you could use the
"internal" modifier to allow Environments to access LeftmostCell.

hth,
Kevin Wienhold

[Marc Gravell]

Well, you can make it "internal" to limit access to just the calling
assembly, and simply don't change it from your other code... maybe that is
enough? By the way, I would recommend exposing this as a property (not a
field); if you are using C# 3 (VS2008 etc) then this is trivial:

internal int LeftmostCell {get;set;}

In C# 2 (VS2005 etc) you need more code:

private int leftmostCell;
internal int LeftmostCell {
get {return leftmostCell;}
set {leftmostCell = value;}
}

Marc

[Magnus.Moraberg]

On 20 Aug, 11:12, "Marc Gravell" <[e-mail]:

Well, you can make it "internal" to limit access to just the calling
assembly, and simply don't change it from your other code... maybe that is
enough? By the way, I would recommend exposing this as a property (not a
field); if you are using C# 3 (VS2008 etc) then this is trivial:

internal int LeftmostCell {get;set;}

In C# 2 (VS2005 etc) you need more code:

private int leftmostCell;
internal int LeftmostCell {
* get {return leftmostCell;}
* set {leftmostCell = value;}

}

Marc

Thanks for the replies! By exposing as a property, am I simply
informing the user of this class as to how I intend them to use this
property?

I usually do the following -

public const string HasNoResults_English = "Has No Results"; // get,
but not set. Initialised prior to Constructor

public readonly string Name; // get, but not set. Initialised in
Constructor

public int Result // get, but not set. Value
updated after Constructor
{
get { return resultCount; }
}

public int LeftmostCell; // both get and set

Its feels tidier to me, but if its not good practice then I can stop.

Thanks,

Barry.

[Marc Gravell]

Public fields are indeed not /generally/ considered good practice
(especially if writeable), but ultimately it is your code. Using a property
simply separates the API from the implementation; other benefits:
* you can inject validation / notification
* you can change the implementation without impacting callers
* it'll work with data-binding (fields don't without some serious hacks)
* it'll work with interfaces
* it can be "virtual" for inheritance purposes
* if you have a mutable struct [please don't do it!] then it completely
changes the behavior - better to do that from the outset
* you can get clearer instrumentation / profiling markers (i.e. you can look
at the call-frequency of the accessors)

etc

There are no real downsides; the JIT will typically inline simple pass-thru
properties, so there is no performance penalty.

Marc