Understanding protected and its use with collections

[Magnus.Moraberg@gmail.com]

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[] testEnvironment s;

void EstablishExcelL ocations()
{
...
}

The function EstablishExcelL ocations 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]

Re: Understanding protected and its use with collections

On 20 Aug., 11:06, Magnus.Morab... @gmail.com 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[] testEnvironment s;
>
void EstablishExcelL ocations()
{
...
}
>
The function EstablishExcelL ocations 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]

Re: Understanding protected and its use with collections

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@gmail.com]

Re: Understanding protected and its use with collections

On 20 Aug, 11:12, "Marc Gravell" <marc.grav...@g mail.comwrote:

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_En glish = "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]

Re: Understanding protected and its use with collections

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