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
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
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
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.
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
|
|
|
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.
Top Community Contributors
|