use of 'base.'

[Andrew Robinson]

I have some base class fields that I am updating. I don't need to use the
'base' modifier to qualify the reference to my fields but does its use add
to readability? What do most people do in C#?

base.isValid = true;
or
isValid = true;

Both work. Which is better?

Thanks.

--

Andrew Robinson

[Barry Kelly]

"Andrew Robinson" <ne****@nospam.nospam> wrote:

I have some base class fields that I am updating. I don't need to use the
'base' modifier to qualify the reference to my fields but does its use add
to readability? What do most people do in C#?

base.isValid = true;
or
isValid = true;

Both work. Which is better?

The 'base' qualifier is for accessing the base class's property or
method when overriding a virtual property or method. Since fields are,
by convention and for good reasons, usually private, 'base.' would not
be able to access them in a descendant class.

-- Barry

[Andrew Robinson]

Would it be poor design to declare those fields as protected or should I be
using properties from my inherited class?

For example, I am creating a series of classes that handle shipping
transactions with different shippers. My program interacts with these
objects in the same way but internally, the shipping is handled very
differently from processor to processor. I created a common base class so
that at least the external properties of each 'shipper' are the same.

Make sense?

--

Andrew Robinson
"Barry Kelly" <ba***********@gmail.com> wrote in message
news:bh********************************@4ax.com...

"Andrew Robinson" <ne****@nospam.nospam> wrote:

I have some base class fields that I am updating. I don't need to use the
'base' modifier to qualify the reference to my fields but does its use
add
to readability? What do most people do in C#?

base.isValid = true;
or
isValid = true;

Both work. Which is better?

The 'base' qualifier is for accessing the base class's property or
method when overriding a virtual property or method. Since fields are,
by convention and for good reasons, usually private, 'base.' would not
be able to access them in a descendant class.

-- Barry

[Galcho[MCSD.NET]]

of course. this is the way to reuse code and make application support
much easier

I hope this helps
Galin Iliev[MCSD.NET]
www.galcho.com

[Ignacio Machin \( .NET/ C# MVP \)]

Hi,

"Andrew Robinson" <ne****@nospam.nospam> wrote in message
news:Oq**************@TK2MSFTNGP02.phx.gbl...

Would it be poor design to declare those fields as protected or should I
be using properties from my inherited class?

For example, I am creating a series of classes that handle shipping
transactions with different shippers. My program interacts with these
objects in the same way but internally, the shipping is handled very
differently from processor to processor. I created a common base class so
that at least the external properties of each 'shipper' are the same.

Make sense?

100%, not only that but that is the way of doing it.

[Barry Kelly]

"Andrew Robinson" <ne****@nospam.nospam> wrote:

Would it be poor design to declare those fields as protected or should I be
using properties from my inherited class?

Use properties. There's no cost to using them, only upside. The little
getter and setter functions get inlined at runtime if they're trivial.

-- Barry

[Bruce Wood]

Make your fields private and create protected properties for them. This
allows you to read the base class in isolation and make guarantees
about how the fields are manipulated both by the public and by child
classes. You can add checks into your setters to maintain guarantees in
the base class and know for sure that no other class--neither the
public nor a descendant--can break those guarantees.

If you allow direct field access, even by descendent classes, then you
cannot make any guarantees at all about the base class's state.

[Andrew Robinson]

Barry,

I think that it might be better to stick with accessing protected fields in
the inherited classes since many of the properties are read/get only when
viewed from the outside. Or, I could use a public get and protected set?

--

Andrew Robinson

"Barry Kelly" <ba***********@gmail.com> wrote in message
news:a5********************************@4ax.com...

"Andrew Robinson" <ne****@nospam.nospam> wrote:

Would it be poor design to declare those fields as protected or should I
be
using properties from my inherited class?

Use properties. There's no cost to using them, only upside. The little
getter and setter functions get inlined at runtime if they're trivial.

-- Barry

[Andrew Robinson]

Thanks Bruce. Clarity at last. Makes complete sense.

--

Andrew Robinson
"Bruce Wood" <br*******@canada.com> wrote in message
news:11**********************@g10g2000cwb.googlegr oups.com...

Make your fields private and create protected properties for them. This
allows you to read the base class in isolation and make guarantees
about how the fields are manipulated both by the public and by child
classes. You can add checks into your setters to maintain guarantees in
the base class and know for sure that no other class--neither the
public nor a descendant--can break those guarantees.

If you allow direct field access, even by descendent classes, then you
cannot make any guarantees at all about the base class's state.

[Bruce Wood]

If you are using .NET 2.0 then you can have different permissions on
the get and the set.

In .NET 1.1 I solved this problem by creating a get-only public
property and a protected method to set the value, something like this:

public bool SomethingOrOther
{
get { return this._somethingOrOther; }
}

protected void SetSomethingOrOther(bool something)
{
this._somethingOrOther = something;
}

[Jon Davis]

I would recommend using 'this.', because if you use 'base.' but override the
method or function in the current context ('this' class) your overrides will
be ignored.

On the other hand, use 'base.' if you're referencing something that you want
to be sure won't call back to 'this.', such as when appending functionality
to an overridden method or property.
--
Jon Davis

"Andrew Robinson" <ne****@nospam.nospam> wrote in message
news:e4**************@TK2MSFTNGP03.phx.gbl...

I have some base class fields that I am updating. I don't need to use the
'base' modifier to qualify the reference to my fields but does its use add
to readability? What do most people do in C#?

base.isValid = true;
or
isValid = true;

Both work. Which is better?

Thanks.

--

Andrew Robinson

[Lucian Wischik]

Barry Kelly <ba***********@gmail.com> wrote:

Use properties. There's no cost to using them, only upside.

I think there is a cost to them -- extra code and readability. Indeed,
if I were to use only the simple getter/setter properties for an
internal class, my instinct would be to declare them just as public
fields.

That way, if the complexity of your app later merits the change to
properties, you can change them to properties and recompile. (well, if
you did anything like "obj.field += 5" or passing obj.field by
reference then it would give errors to make you change them. But that
kind of error seems salutory to me.)

--
Lucian

[Bruce Wood]

Two things to note here:

1) This doesn't work for DLLs released to outside audiences with a
published contract. It works only for internal apps where you have the
luxury of recompiling both the class and all classes that use it. I
have that luxury, and maybe the OP does, but not everyone does.

2) See my earlier post about being able to read a base class and get
the warm fuzzy feeling that you know what's going on. If you expose
public fields then any client class can change them to anything, at any
time, and you have no control. I find that if I supply simply getters
and setters to the "outside world" it's usually out of laziness. I
later find that I have to go back and put some sort of validation in
the setters, in order to guarantee things about the state of my class.