Write access to 'get'-only public property from within a class - best practice?

[Jack]

Hi,

I have a class with a get-only public bool property. This is good because I
want users of this class to ONLY READ it.
So I've defined it thus:

private bool _IsDirty;
public bool IsDirty{
get{ return _IsDirty; }
}

.... no problems there.

But the methods from WITHIN this class needs to write to it, but the
compiler will not allow me. So I guess I have 2 choices:

1. Put a set{ _IsDirty = value; } clause. This will allow the methods from
WITHIN this class to write to it (i.e. IsDirty = true;), but it defeats the
purpose because the users of this class are now ALSO able to modify it -
THIS IS BAD!.
2. When writing to it, write to the private value (i.e. _IsDirty = true; ).
This is my preferred choice at the moment, but it seems to defeat the
purpose of encapsulation and good programming practice; because it the
implementation of IsDirty is to be changed in the future, I'll have to step
through all the code where I reference it.

What is the preferred way, or is there another approach? have I missed
something?

Thanks,
jack.

[SvenC]

Hi Jack,

"Jack" <ja**@nospam.co m.ukwrote in message
news:45******@q uokka.wn.com.au ...

Hi,

I have a class with a get-only public bool property. This is good because
I want users of this class to ONLY READ it.
So I've defined it thus:

private bool _IsDirty;
public bool IsDirty{
get{ return _IsDirty; }
}

... no problems there.

But the methods from WITHIN this class needs to write to it, but the
compiler will not allow me. So I guess I have 2 choices:

Don't know if this works in VS2002/2003 also but in VS2005 you can have
different visibilities on getter and setter:

public bool IsDirty
{
get { return _IsDirty; } // this is public
internal set { _IsDirty = value; } // this is internal
}

--
SvenC

1. Put a set{ _IsDirty = value; } clause. This will allow the methods from
WITHIN this class to write to it (i.e. IsDirty = true;), but it defeats
the purpose because the users of this class are now ALSO able to modify
it - THIS IS BAD!.
2. When writing to it, write to the private value (i.e. _IsDirty =
true; ). This is my preferred choice at the moment, but it seems to defeat
the purpose of encapsulation and good programming practice; because it the
implementation of IsDirty is to be changed in the future, I'll have to
step through all the code where I reference it.

What is the preferred way, or is there another approach? have I missed
something?

Thanks,
jack.

[Jack]

SvenC, thanks.

This was just what I was looking for: I took a look at this modifier before,
but I had no idea you could place it at the Get & Set level of the public
variable (like your code example)

Again, thank-you.
Jack.
"SvenC" <Sv***@communit y.nospamwrote in message
news:OE******** ******@TK2MSFTN GP06.phx.gbl...

Hi Jack,

"Jack" <ja**@nospam.co m.ukwrote in message
news:45******@q uokka.wn.com.au ...

>Hi,

I have a class with a get-only public bool property. This is good because
I want users of this class to ONLY READ it.
So I've defined it thus:

private bool _IsDirty;
public bool IsDirty{
get{ return _IsDirty; }
}

... no problems there.

But the methods from WITHIN this class needs to write to it, but the
compiler will not allow me. So I guess I have 2 choices:

Don't know if this works in VS2002/2003 also but in VS2005 you can have
different visibilities on getter and setter:

public bool IsDirty
{
get { return _IsDirty; } // this is public
internal set { _IsDirty = value; } // this is internal
}

--
SvenC

>1. Put a set{ _IsDirty = value; } clause. This will allow the methods
from WITHIN this class to write to it (i.e. IsDirty = true;), but it
defeats the purpose because the users of this class are now ALSO able to
modify it - THIS IS BAD!.
2. When writing to it, write to the private value (i.e. _IsDirty =
true; ). This is my preferred choice at the moment, but it seems to
defeat the purpose of encapsulation and good programming practice;
because it the implementation of IsDirty is to be changed in the future,
I'll have to step through all the code where I reference it.

What is the preferred way, or is there another approach? have I missed
something?

Thanks,
jack.

[Bill Butler]

"Jack" <ja**@nospam.co m.ukwrote in message
news:45******@q uokka.wn.com.au ...

Hi,

I have a class with a get-only public bool property. This is good
because I want users of this class to ONLY READ it.
So I've defined it thus:

private bool _IsDirty;
public bool IsDirty{
get{ return _IsDirty; }
}

... no problems there.

But the methods from WITHIN this class needs to write to it, but the
compiler will not allow me.

<snip>

There is no reason the compiler should prevent you from changing the
value of the private member.I suspect you are attempting to change it
via the non existent setter.

You need to type
_IsDirty = true;
as opposed to
IsDirty = true;

If this is not your problem then I suggest you post your code since this
should not be a problem.

Hope this helps
Bill

[Bruce Wood]

Jack wrote:

I have a class with a get-only public bool property. This is good because I
want users of this class to ONLY READ it.
So I've defined it thus:

private bool _IsDirty;
public bool IsDirty{
get{ return _IsDirty; }
}

... no problems there.

But the methods from WITHIN this class needs to write to it, but the
compiler will not allow me. So I guess I have 2 choices:

1. Put a set{ _IsDirty = value; } clause. This will allow the methods from
WITHIN this class to write to it (i.e. IsDirty = true;), but it defeats the
purpose because the users of this class are now ALSO able to modify it -
THIS IS BAD!.

Yes, this is bad. THIS violates incapsulation.

2. When writing to it, write to the private value (i.e. _IsDirty = true; ).
This is my preferred choice at the moment, but it seems to defeat the
purpose of encapsulation and good programming practice; because it the
implementation of IsDirty is to be changed in the future, I'll have to step
through all the code where I reference it.

This doesn't violate encapsulation: "encapsulat ion" refers to the fact
that there are certain things that code _outside_ your class cannot
change without going through your class's code to do it.
"Encapsulat ion" places no restrictions on what the code _inside_ the
class can do. Your class's private code always has wide-open access to
your class's state.

That said, setting the value directly may or may not be what you want.
It comes with advantages and disadvantages. The disadvantage being that
if you want to make some guarantees about the values of that field it's
much easier to put some code between your internal class code and the
value, rather than making sure in every place you set it that you don't
violate the guarantees. I find that I very rarely care about this, and
usually set private members directly in code.

In those cases in which you need to place a code buffer between the
class code and the field, there are two ways to do it. As other posters
pointed out, in .NET 2.0 you can specify a setter and give it a
different scope modifier. However, this isn't possible in .NET 1.1.
Since I'm on 1.1, I do this:

public bool IsSelected
{
get { return this._isSelecte d; }
}

private void SetIsSelected(b ool isSelected)
{
this._isSelecte d = isSelected;
}