Is this good use of Properties?

  • Thread starter Thread starter Brett
  • Start date Start date
B

Brett

If I do this without declaring a corresponding field, is it considered bad
design? What are the advantages or disadvantages to either method? Notice
there is not set.

public string URL
{
get
{
return "www.somewhere.com/test.aspx";
}
}

vs. a more common approach:


private readonly string _URL = "www.somewhere.com/test.aspx";

public string URL
{
get
{
return _URL;
}
}

Also, if I only have a get accessor, is it necessary to declare the field as
readonly?

Thanks,
Brett
 
If I do this without declaring a corresponding field, is it considered bad
design?
Click to expand...

Not in my opinion.

What are the advantages or disadvantages to either method?
Click to expand...

If you add an instance field to store a constant value you're wasting
some memory for every object created of that class. That may not be a
big deal unless you're going to have lots of such objects, but still
it would make more sense to make it a (static) constant or just place
the string inline in the property getter.

Also, if I only have a get accessor, is it necessary to declare the field as
readonly?
Click to expand...

No



Mattias
 
If I do this without declaring a corresponding field, is it considered
bad design? What are the advantages or disadvantages to either
method? Notice there is not set.
Click to expand...

Sure I do that all the time. If you are only returning a constant value
then you could just as easily expose it as a public readonly, but there's
nothing wrong with doing it this way. In fact, this is used sometimes if
you want to show a value in the designer but don't want the user to be able
to change the value.

You do not have to declare a field that is controlled by a get-only
accessor as readonly if you don't want to, and in fact may not want to if
other parts of the code change the value.

-mdb
 
The C# compiler, unlike the brain-dead VB compiler, can figure out for
itself that if a property only has a get accessor then it's probably a
read-only property. It's one of my VB pet hates.

Perhaps the type of property you mention would be better as a static
property similar to Pi in the Math class or "Red" in the Color class.

--
Bob Powell [MVP]
Visual C#, System.Drawing

Find great Windows Forms articles in Windows Forms Tips and Tricks
http://www.bobpowell.net/tipstricks.htm

Answer those GDI+ questions with the GDI+ FAQ
http://www.bobpowell.net/faqmain.htm

All new articles provide code in C# and VB.NET.
Subscribe to the RSS feeds provided and never miss a new article.
 
I could declare it as static but only one instance of this class will ever
exists. Given that scenario, isn't that basically the same as declaring it
static?

What are some of your reasons for saying the VB compiler is brain dead? I'm
always interested in the detailed differences between C# and VB.NET and
where one is better than the other.

Thanks,
Brett
 
The property is completey self-contained, requires no instance data and
returns a constant or literal value. This makes it an ideal candidate for
static usage. Whether you refine your achitecture in that way is up to you.

Whether a class has one instance or a million, the code is not duplicated on
a per-instance basis, only the data, so essentitially your argument is
valid, the only thing that matters is whether you intend to create a
consistent and robust architecture or just fudge what your doing because it
seems to work at the time. Not marking the property as static implies to the
user that the property requires an instance of the class, which it doesn't

As to your other question, I'll just don my flame-proof trousers quickly and
say that I believe VB.NET was primarily expected to be code generated and so
is unnecessarily wordy and insists on some quite ridiculous langage
constructs. The insistence of the compiler that read-only is declared when
it can easily be inferred is just one example in a long list of things that
I find intensely annoying when using VB. Another is the stupidity of the
Overloads-Overrides construct because an overload isn't neccesarily an
override and vice-versa. Overloads can also be inferred by the compiler
simply by looking at the method signature so this introduces more redundant
waffle into the language.

To be dispassionate VB.NET does have some advantages. I've seen code
compiled with VB.NET that outperformed an exact equivalent program in C# on
a couple of occasions now. This is not to say that the advantages are
across-the-board however so I don't advocate VB as a performance enhancer.

I think that if you write a lot of code by hand, which I do, C# has the
leanest source code and the most sensible language structure. C# never makes
me pull my hair out in despair like VB.NET does.


--
Bob Powell [MVP]
Visual C#, System.Drawing

Find great Windows Forms articles in Windows Forms Tips and Tricks
http://www.bobpowell.net/tipstricks.htm

Answer those GDI+ questions with the GDI+ FAQ
http://www.bobpowell.net/faqmain.htm

All new articles provide code in C# and VB.NET.
Subscribe to the RSS feeds provided and never miss a new article.
 
Brett,

The disadvantage of both methods is that you encapsulate=do nothing.
Start thinking in objects means a lot of times do completely away with
accessors! It will really help you to be really critical about every
one of those.


Rick
 
What do you mean do away with accessors? I thought they were fundamental to
object oriented programming.

Brett
 
Good stuff on VB.NET Bob. I'd love to hear more about specific scenarios in
VB.NET that you wish the language would have handled it better. Please
email me at brett1_at_cygen_dot_com, when you have time. It really helps me
understand both languages more.

Thanks,
Brett
 
C# Learner said:
How about the following?

public const string URL = "www.somewhere.com/test.aspx";
Click to expand...

Don't like it, personally. The point of properties is that they hide the
implementation. You make it a public string constant and you're stuck
with it.

Make it a property, a static one returning the value of a constant if
that makes sense, and you can subsequently change the implementation
without clients of the class needing to know.

So, if the requirements change such that, instead of URL being a
constant, it needs to be a value loaded from a config file, or a
database, or a value calculated on the fly, you can change it.

I think I'd only make a constant public if it really was a constant;
Avogadro number, e, c, Pi, max/min values of a signed 32 bit integer...

Even then, I'd think about it.
 
Bill,

Yes I can. Try it and you buy it:
don't use accessors and see what
problems you encounter. All of those
point you to the right design.

Rick
 
Rick Elbers said:
Yes I can. Try it and you buy it:
don't use accessors and see what
problems you encounter. All of those
point you to the right design.
Click to expand...

Unfortunately that way you end up using all kinds of sloppy programming
practices until you ship a product and *then* get bitten when you need
to upgrade it, etc.

Imagine doing threading using that kind of methodology - you could get
away with any number of things until you encounter a multi-processor
box, or a version of the CLR which doesn't have quite as strong a
memory model.
 
Jon,

Methodology as a concept is not widely accepted.
Best practices,patterns, tests and key concepts are. I can't think of
any better short way to learning OO design then tell somebody
to avoid accessors. Every OO methodology on the planet
supported technique lol

And btw sloppy programming ? Joker. Accessors bite you when you need
upgrade or bugs, cause they make you tighly couple. Localization and
encapulation are closely related. Encapsulation and !Accessors too.

Rick
 
Methodology as a concept is not widely accepted.
Best practices,patterns, tests and key concepts are. I can't think of
any better short way to learning OO design then tell somebody
to avoid accessors. Every OO methodology on the planet
supported technique lol

And btw sloppy programming ? Joker. Accessors bite you when you need
upgrade or bugs, cause they make you tighly couple. Localization and
encapulation are closely related. Encapsulation and !Accessors too.
Click to expand...

Rick,

I could accept your arguments if you were making them in favour of using
accessors. Are you saying this:

public string myString;

is better than this:

private string myString;
public string MyString
{
get{return myString;}
set{myString=value;}
}

?

I don't think so.
 
Steve Walker said:
Rick,

I could accept your arguments if you were making them in favour of using
accessors. Are you saying this:

public string myString;

is better than this:

private string myString;
public string MyString
{
get{return myString;}
set{myString=value;}
}

?

I don't think so.
Click to expand...

I was wondering which books he's been reading. He seems to be going against
OOP methology.

Brett
 
Rick Elbers said:
Jon,

Methodology as a concept is not widely accepted.
Best practices,patterns, tests and key concepts are. I can't think of
any better short way to learning OO design then tell somebody
to avoid accessors. Every OO methodology on the planet
supported technique lol

And btw sloppy programming ? Joker. Accessors bite you when you need
upgrade or bugs, cause they make you tighly couple. Localization and
encapulation are closely related. Encapsulation and !Accessors too.
Click to expand...

OK,

I am reading the words that you are writing.
I understand the words.
What I don't understand is what point you are trying to make.
Perhaps English is your second language, but I really need clarification.

I THINK you are advocating making the string field public, but I am not sure

Could you produce a sample program that demonstrates what it is that you
are talking about?

Thank you
Bill
 
Rick,

Can you clarify why you think accessors result in code that is more
tightly coupled than using class members directly? A short example
would be nice as well.

Also, can you provide an example where using an accessor causes
problems when fixing/upgrading code?

Brian
 
Back
Top