sign in | join about | help | sitemap
Connecting Tech Pros Worldwide
Magnus.Moraberg@gmail.com's Avatar

Understanding protected and its use with collections


Question posted by: Magnus.Moraberg@gmail.com (Guest) on August 20th, 2008 10:15 AM
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
4 Answers Posted
KWienhold's Avatar
Guest - n/a Posts
#2: Re: Understanding protected and its use with collections

On 20 Aug., 11:06, Magnus.Morab...@gmail.com wrote:
Quote:
Originally Posted by
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's Avatar
Guest - n/a Posts
#3: 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's Avatar
Magnus.Moraberg@gmail.com August 20th, 2008 10:35 AM
Guest - n/a Posts
#4: Re: Understanding protected and its use with collections

On 20 Aug, 11:12, "Marc Gravell" <marc.grav...@gmail.comwrote:
Quote:
Originally Posted by
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's Avatar
Guest - n/a Posts
#5: 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


 
Not the answer you were looking for? Post your question . . .
197,024 members ready to help you find a solution.
Join Bytes.com

What is Bytes?

We are a network of experts and professionals in IT and software development that help one another with answers to tough questions and share insights. Get the best answers to your questions from over 197,024 network members.
Post your question now . . .
It's fast and it's free

Popular Articles

Top Community Contributors