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
45  2364  If I do this without declaring a corresponding field, is it considered bad
design?
Not in my opinion.
What are the advantages or disadvantages to either method?
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?
No
Mattias
--
Mattias Sjögren [MVP] mattias @ mvps.org http://www.msjogren.net/dotnet/ | http://www.dotnetinterop.com
Please reply only to the newsgroup.
"Brett" <no@spam.com> wrote in
news:#C**************@tk2msftngp13.phx.gbl: 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.
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.
"Brett" <no@spam.com> wrote in message
news:%2****************@tk2msftngp13.phx.gbl... 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
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
"Bob Powell [MVP]" <bob@_spamkiller_bobpowell.net> wrote in message
news:OE**************@TK2MSFTNGP14.phx.gbl... 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.
"Brett" <no@spam.com> wrote in message
news:%2****************@tk2msftngp13.phx.gbl... 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
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" <no@spam.com> wrote in message
news:eK**************@TK2MSFTNGP12.phx.gbl... 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
"Bob Powell [MVP]" <bob@_spamkiller_bobpowell.net> wrote in message
news:OE**************@TK2MSFTNGP14.phx.gbl... 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.
"Brett" <no@spam.com> wrote in message
news:%2****************@tk2msftngp13.phx.gbl... 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
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
On Mon, 9 May 2005 09:17:09 -0400, "Brett" <no@spam.com> wrote: 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
What do you mean do away with accessors? I thought they were fundamental to
object oriented programming.
Brett
"Rick Elbers" <ri*********@chello.nl> wrote in message
news:8t********************************@4ax.com... 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
On Mon, 9 May 2005 09:17:09 -0400, "Brett" <no@spam.com> wrote:
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
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
"Bob Powell [MVP]" <bob@_spamkiller_bobpowell.net> wrote in message
news:O5**************@TK2MSFTNGP15.phx.gbl... 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" <no@spam.com> wrote in message
news:eK**************@TK2MSFTNGP12.phx.gbl...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
"Bob Powell [MVP]" <bob@_spamkiller_bobpowell.net> wrote in message
news:OE**************@TK2MSFTNGP14.phx.gbl... 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.
"Brett" <no@spam.com> wrote in message
news:%2****************@tk2msftngp13.phx.gbl...
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
Brett <no@spam.com> wrote: public string URL
{
get
{
return "www.somewhere.com/test.aspx";
}
}
How about the following?
public const string URL = "www.somewhere.com/test.aspx";
From what I've seen, the .NET library code tends to use this approach. For
example, System.Int32 has these two members:
public const int MaxValue = 0x7fffffff;
public const int MinValue = -2147483648;
In message <c4***************@csharp.learner>, C# Learner
<cs****@learner.here> writes Brett <no@spam.com> wrote:
public string URL
{
get
{
return "www.somewhere.com/test.aspx";
}
}
How about the following?
public const string URL = "www.somewhere.com/test.aspx";
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.
--
Steve Walker
Brett,
Its wysiwyg: dont use accessors
Rick
On Mon, 9 May 2005 14:16:54 -0400, "Brett" <no@spam.com> wrote: What do you mean do away with accessors? I thought they were fundamental to
object oriented programming.
Brett
"Rick Elbers" <ri*********@chello.nl> wrote in message
news:8t********************************@4ax.com.. . 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
On Mon, 9 May 2005 09:17:09 -0400, "Brett" <no@spam.com> wrote:
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
Rick Elbers <ri*********@chello.nl> wrote: 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.
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 Skeet - <sk***@pobox.com> http://www.pobox.com/~skeet
If replying to the group, please do not mail me too
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
On Tue, 10 May 2005 19:15:37 +0100, Jon Skeet [C# MVP]
<sk***@pobox.com> wrote: Rick Elbers <ri*********@chello.nl> wrote: 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.
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.
In message <d6********************************@4ax.com>, Rick Elbers
<ri*********@chello.nl> writes On Tue, 10 May 2005 19:15:37 +0100, Jon Skeet [C# MVP]
<sk***@pobox.com> wrote:
Rick Elbers <ri*********@chello.nl> wrote: 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.
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.
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,
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
"Steve Walker" <st***@otolith.demon.co.uk> wrote in message
news:uq**************@otolith.demon.co.uk... In message <d6********************************@4ax.com>, Rick Elbers
<ri*********@chello.nl> writes
On Tue, 10 May 2005 19:15:37 +0100, Jon Skeet [C# MVP]
<sk***@pobox.com> wrote:
Rick Elbers <ri*********@chello.nl> wrote:
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.
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.
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,
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
I was wondering which books he's been reading. He seems to be going against
OOP methology.
Brett
"Rick Elbers" <ri*********@chello.nl> wrote in message
news:d6********************************@4ax.com... 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.
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
Rick Elbers wrote: Jon,
[snip]
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
Rick Elbers <ri*********@chello.nl> wrote: 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
Best practices say to use accessors, however.
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.
As others have said, accessors are a *looser* coupling than assuming
that the string will always be something which is known at compile-
time, or is available as a simple field at runtime.
--
Jon Skeet - <sk***@pobox.com> http://www.pobox.com/~skeet
If replying to the group, please do not mail me too
Jon and others,
I dunno the audience here very well, but ofcourse I was not talking
about using public members instead of accessors. For every solution
( don't use accessors) there seems to be a problem( then use public
members:-)) I guess.
The fact that none of the people in reaction understood the basic
pattern of encapsulation very well is bothering me bigtime..
O well lets just assume language problems..
For the record: encapsulation is not considered the same as using
private members and making them accessable again afterwards.
Thats just a style kind of thing, which in fact has no value or deed.
Its just another indirection and thats exactly why OO is a problem
for starters. Bad OO is worse then good procedural programming.
Back to the ground rule that accessors is bad news...
Lets examplify ?
Lets assume we have observation's( yes I am talking a
object-class:-)), and we have decision's( another one of those).
Some kind of model like: D = [w * O]*
Decisions are losely based upon Observation, one or more if you like
which have some weight(w) too. Lets say we want an application which
simulates the results of my decisions if I change weights to
observation's.
For calculating your decisions you have quit a few options where to
put weight.
One option might be to give Observation a weight and value accessor
and let Decision have an ObservationList where it asks every
Observation for its weight and value and accumalates.
What is the problem of that approach ?
Observation does nothing. Its a meaningless object. Its a bag where
you throw values at which later on you extract them. In my view if you
have a solution like this your Observation class should be removed
from the scene.
A second option might be to give Observation a method CalculateResult
in which it internally multiplies weight * value. Much better if we do
this because we want to remove accessors. So lets remove those. Life
of Observations is getting more meaningfull. Its getting constructed
from Value and Weight and Calculates its own Result.
*problems*
But wait we wanted to build a simulation, so we want possibilities to
change weights. Can you feel the tendency to keep the Weight Accessor?
Still your mentor told you not to use accessors and you are getting
the hang of it. If you have a weight accessor what kind of observation
do we have then ? Its literally a meaningless value in our system.
So at this moment you are caught in a sweat box.
Now design starts.
You have observations to which you want to give weight in simulations.
What are other options besides weight accessor in Observation ?
1) Lets consider creating a simulation class.
2) Lets consider creating observations for every new weight. Within
the context of our simulation the concept of observation might really
be some weighted one..( here design enforces domain modelling)
3) Lets consider to give observation the added responsibility to add
itself to some decisions with some value, maybe dependent upon which
simulation you run...
4) Good Questions arise( here design enforces analysis): what
determins the simulations we want to run ? Does the weight domain
is dependent upon the Observation( Type ), or upon the Decision, upon
both or just user choice and not dependent upon Observation nor
Decision.
5) etc..etc..
I am very sorry that I dont have time or guts to fully explain or
examplify, but I hope you can see the ground rule that Accessor =
AntiPattern can be very strong and short. If you publish more then
50% of your class members in properties consider strongly to remove
the class altogether,or factor out those published properties since
this way the class probably is too dumb..or has an ambigui character.
Rick
On Wed, 11 May 2005 19:27:05 +0100, Jon Skeet [C# MVP]
<sk***@pobox.com> wrote: Rick Elbers <ri*********@chello.nl> wrote: 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
Best practices say to use accessors, however.
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.
As others have said, accessors are a *looser* coupling than assuming
that the string will always be something which is known at compile-
time, or is available as a simple field at runtime.
Rick Elbers <ri*********@chello.nl> wrote: I dunno the audience here very well, but ofcourse I was not talking
about using public members instead of accessors. For every solution
( don't use accessors) there seems to be a problem( then use public
members:-)) I guess.
It would have helped if you'd given your alternative solution then - to
the OP's question, not one that you made up yourself. "Don't use
accesseors" isn't a solution in itself anyway - it's a claim of an
"anti-solution". Saying "don't do that" isn't solving a problem, it's
just telling someone how to not solve the problem.
The fact that none of the people in reaction understood the basic
pattern of encapsulation very well is bothering me bigtime..
O well lets just assume language problems..
For the record: encapsulation is not considered the same as using
private members and making them accessable again afterwards.
Thats just a style kind of thing, which in fact has no value or deed.
Yes it does - it means you can change the implementation of the
property later, if instead of using a private member you wish to
consult a database, or a separate object, or whatever. That
implementation change can be distributed without affecting binary
compatibility, which definitely *does* have value.
Its just another indirection and thats exactly why OO is a problem
for starters. Bad OO is worse then good procedural programming.
But adding indirection isn't bad OO.
Back to the ground rule that accessors is bad news...
Lets examplify ?
<snip>
I am very sorry that I dont have time or guts to fully explain or
examplify, but I hope you can see the ground rule that Accessor =
AntiPattern can be very strong and short.
Absolutely not. You've just shown that in one particular example it
might not be appropriate, and (I think) come up with the idea that
immutable classes should be preferred to mutable ones (which I
generally agree with). That has nothing to do with whether or not a
property is suitable for the OP's situation.
--
Jon Skeet - <sk***@pobox.com> http://www.pobox.com/~skeet
If replying to the group, please do not mail me too
In message <h9********************************@4ax.com>, Rick Elbers
<ri*********@chello.nl> writes I am very sorry that I dont have time or guts to fully explain or
examplify, but I hope you can see the ground rule that Accessor =
AntiPattern can be very strong and short. If you publish more then
50% of your class members in properties consider strongly to remove
the class altogether,or factor out those published properties since
this way the class probably is too dumb..or has an ambigui character.
This is a different concept to what you appeared to be talking about.
You are talking about exposing too much of a class's internal state
breaking encapsulation, not specifically about the property language
construct.
public int foo;
and
void SetFoo(int i){this.foo=i;}
int GetFoo(){return this.foo;}
and
int Foo{get{return foo;}set{foo=value;}}
Are all equally objectionable to your scheme, yes? OK. Leaving that
aside, the point I and others were making was that if foo is to be
exposed, of the three, the last is preferable.
Whether exposing some or all of the internal state of the class is bad
design or not is going to depend on the problem domain. It may be
legitimate to expose it in a read-only way (get property only), it may
be necessary to expose it all, it may be necessary to hide it all.
In many business applications there will be classes which expose almost
all of their fields. The behaviour of the class is to validate, persist
and retrieve the fields, and not much else. I don't think you can
necessarily say that this is bad design, it's simply that what the class
is modelling is very simple.
I'd agree that a class consisting of nothing but private fields and dumb
public properties is a code smell unless it is being used for a very
specific purpose (say, memento pattern, or parameter object).
--
Steve Walker
Jon,
I challenge: And it would be nice if you came up with the best
practice Pattern example to use Properties instead of telling the
world that ensapsulation might be a good idea after all..lol
Rick
On Thu, 12 May 2005 07:16:55 +0100, Jon Skeet [C# MVP]
<sk***@pobox.com> wrote: Rick Elbers <ri*********@chello.nl> wrote: I dunno the audience here very well, but ofcourse I was not talking
about using public members instead of accessors. For every solution
( don't use accessors) there seems to be a problem( then use public
members:-)) I guess.
It would have helped if you'd given your alternative solution then - to
the OP's question, not one that you made up yourself. "Don't use
accesseors" isn't a solution in itself anyway - it's a claim of an
"anti-solution". Saying "don't do that" isn't solving a problem, it's
just telling someone how to not solve the problem.
And that road its the shortest way to put somebody on track in my
5 years of experience as a OO teacher and mentor
The fact that none of the people in reaction understood the basic
pattern of encapsulation very well is bothering me bigtime..
O well lets just assume language problems..
For the record: encapsulation is not considered the same as using
private members and making them accessable again afterwards.
Thats just a style kind of thing, which in fact has no value or deed.
Yes it does - it means you can change the implementation of the
property later, if instead of using a private member you wish to
consult a database, or a separate object, or whatever. That
implementation change can be distributed without affecting binary
compatibility, which definitely *does* have value.
Truth, theoretically. In practice however at least 80% of accessors
are simple published private properties, and only very few properties
are ever changed in implementation. Indeed the use of PRIVATE or
PROTECTED properties however is a very good idiom for exactly the
reasons you gave if you suspect implementation changes or
polymorphism. Just today I changed some private member access to
a protected property access because I had to support ASynch
Notifications. Its just another indirection and thats exactly why OO is a problem
for starters. Bad OO is worse then good procedural programming.
But adding indirection isn't bad OO.
No..its just bad..if thats all there is. Back to the ground rule that accessors is bad news...
Lets examplify ?
<snip>
I am very sorry that I dont have time or guts to fully explain or
examplify, but I hope you can see the ground rule that Accessor =
AntiPattern can be very strong and short.
Absolutely not. You've just shown that in one particular example it
might not be appropriate, and (I think) come up with the idea that
immutable classes should be preferred to mutable ones (which I
generally agree with). That has nothing to do with whether or not a
property is suitable for the OP's situation.
The OP's situation being ? Its the richest advice I have to give him,
and it stays that way too. You cant convince me without a counter
example I am afraid.
Regards,
Rick
Rick Elbers <ri*********@chello.nl> wrote: I challenge: And it would be nice if you came up with the best
practice Pattern example to use Properties instead of telling the
world that ensapsulation might be a good idea after all..lol
Sorry, I'm not entirely sure what you're after here. I maintain that:
a) Properties are better than exposing variables directly
b) Properties are useful in many situations
That doesn't mean they're universally applicable, of course, but then
no-one said they were.
Out of interest, if you don't think accessors should be used, how would
you expose the length of a string? Or wouldn't you? What would you use
instead? It would have helped if you'd given your alternative solution then - to
the OP's question, not one that you made up yourself. "Don't use
accesseors" isn't a solution in itself anyway - it's a claim of an
"anti-solution". Saying "don't do that" isn't solving a problem, it's
just telling someone how to not solve the problem.
And that road its the shortest way to put somebody on track in my
5 years of experience as a OO teacher and mentor
Well the fact that so many people had no idea what you *were*
suggesting indicates that you didn't really enlighten anyone just by
saying not to use properties. Yes it does - it means you can change the implementation of the
property later, if instead of using a private member you wish to
consult a database, or a separate object, or whatever. That
implementation change can be distributed without affecting binary
compatibility, which definitely *does* have value.
Truth, theoretically. In practice however at least 80% of accessors
are simple published private properties, and only very few properties
are ever changed in implementation. Indeed the use of PRIVATE or
PROTECTED properties however is a very good idiom for exactly the
reasons you gave if you suspect implementation changes or
polymorphism. Just today I changed some private member access to
a protected property access because I had to support ASynch
Notifications.
I thought you didn't like properties though, that using an accessor was
an anti-pattern? Its just another indirection and thats exactly why OO is a problem
for starters. Bad OO is worse then good procedural programming.
But adding indirection isn't bad OO.
No..its just bad..if thats all there is.
No, it's bad if that's all there is and you're absolutely sure that's
all there will *ever* be. Absolutely not. You've just shown that in one particular example it
might not be appropriate, and (I think) come up with the idea that
immutable classes should be preferred to mutable ones (which I
generally agree with). That has nothing to do with whether or not a
property is suitable for the OP's situation.
The OP's situation being ? Its the richest advice I have to give him,
and it stays that way too. You cant convince me without a counter
example I am afraid.
The counter-example is just to use the property - you haven't actually
shown anything wrong with that. Instead, you've shown that it might be
the wrong way of working in a completely different situation.
--
Jon Skeet - <sk***@pobox.com> http://www.pobox.com/~skeet
If replying to the group, please do not mail me too
On Thu, 12 May 2005 21:38:02 +0100, Jon Skeet [C# MVP]
<sk***@pobox.com> wrote: Rick Elbers <ri*********@chello.nl> wrote: I challenge: And it would be nice if you came up with the best
practice Pattern example to use Properties instead of telling the
world that ensapsulation might be a good idea after all..lol
Sorry, I'm not entirely sure what you're after here. I maintain that:
a) Properties are better than exposing variables directly
b) Properties are useful in many situations
That doesn't mean they're universally applicable, of course, but then
no-one said they were.
Out of interest, if you don't think accessors should be used, how would
you expose the length of a string? Or wouldn't you? What would you use
instead?
Very good example (of my point). Never expose the length of the string
would be the instantiation of my global advice here. Give me one
reason why you would want to and I show you two why doing it is less
design then not doing it.
Rick
Rick Elbers <ri*********@chello.nl> wrote: Out of interest, if you don't think accessors should be used, how would
you expose the length of a string? Or wouldn't you? What would you use
instead?
Very good example (of my point). Never expose the length of the string
would be the instantiation of my global advice here. Give me one
reason why you would want to and I show you two why doing it is less
design then not doing it.
Sure: if you're trying to create a new char array which will hold the
concatenation of two existing strings, it's helpful to be able to know
how big to make that char array.
Similarly, knowing the length of a string lets you easily iterate
through two strings comparing characters.
Similarly, knowing the length of a string can often easily let you work
out the number of bytes required for the encoded form of a string (if
you're writing an Encoding).
--
Jon Skeet - <sk***@pobox.com> http://www.pobox.com/~skeet
If replying to the group, please do not mail me too
On Fri, 13 May 2005 17:37:59 +0100, Jon Skeet [C# MVP]
<sk***@pobox.com> wrote: Rick Elbers <ri*********@chello.nl> wrote: >Out of interest, if you don't think accessors should be used, how would
>you expose the length of a string? Or wouldn't you? What would you use
>instead?
Very good example (of my point). Never expose the length of the string
would be the instantiation of my global advice here. Give me one
reason why you would want to and I show you two why doing it is less
design then not doing it.
Sure: if you're trying to create a new char array which will hold the
concatenation of two existing strings, it's helpful to be able to know
how big to make that char array.
Good example. No design which is worth the name will ever do something
like - concatenate to the string class only the feature to tell how
big concatenated strings are. Only if you work in smalltalk you can
just add this method to the string class which might help if its not
already there...(lol). You are not really telling me that exposing the
length of two concatenated strings is a real behavior of one of your
classes, do you ? You must be either the programmer of the dotnet
framework string class...or something from outer space...
This kind of behaviors are normally implementation details of real
domain classes..which certainly dont expose length of strings..jeee..
that really defeats every encaps.
Similarly, knowing the length of a string lets you easily iterate
through two strings comparing characters.
Another one of those. If the string class not already had split etc
behaviors you might want to add it to a string class in smalltalk. One
thing you will *never* want to do is to expose the length because a
client would do something you want to do yourself( comparing
characters that is..how about the compareTo interface for string
class?)
Similarly, knowing the length of a string can often easily let you work
out the number of bytes required for the encoded form of a string (if
you're writing an Encoding).
And again..thats the responsibility of the encoder. Ergo: you again
proved my point. Exposing the length of a string is something which
makes your design rotten and expose something you want to hide( that
you need the length of a string for its proper encoding that is)
More complicated examples please..
Rick
"Rick Elbers" <ri*********@chello.nl> wrote in message
news:j0********************************@4ax.com...
I hunted around a bit and came up with this:
"Why getter and setter methods are evil " by Alan Holub http://www.javaworld.com/javaworld/j...5-toolbox.html
pay close attention to the forum that follows the article.
(He does not get unanimous acceptance)
It seems to describe your point (if I understand correctly)
-----------------------------------
I can firmly agree that loose coupling is a good idea. (but not always)
I can firmly agree that excessive use of accessors can be bad.
Never using accessors is just plain stupid.
******************************************
By the way.
You were quite rude in your response to Jon.
Instead of insults and rhetoric, how about examples
to back up your claims (In C#)
You blew off his examples instead of producing the code
******************************************
Questions
Should Arrays/collections expose a Length/Count property?
Should strings provide accessors for individual characters?
Assuming some class external to string needed to know it's length How would you get it?
----------------------
Simple example
I read in a string from a file (I don't control the format).
I need to send it across the pipe to another process (I don't control the format)..
The other process is expecting it in this format
NNstring
where NN is the 2 digit length.
anything over 99 characters is truncated to 99 characters
so
"QWERTY" would be 06QWERTY
"Happy Birthday" would be 14Happy Birthday
I would do something like this
public string CustomFormat(string str)
{
if (str.Length > 99)
str = str.Substring(0, 99);
return (string.Format("{0:d2}{1}",str.Length, str));
}
--------------------------------
Please post C# code showing how you would solve this
Thank you
Bill
Rick Elbers <ri*********@chello.nl> wrote: Very good example (of my point). Never expose the length of the string
would be the instantiation of my global advice here. Give me one
reason why you would want to and I show you two why doing it is less
design then not doing it.
Sure: if you're trying to create a new char array which will hold the
concatenation of two existing strings, it's helpful to be able to know
how big to make that char array.
Good example. No design which is worth the name will ever do something
like - concatenate to the string class only the feature to tell how
big concatenated strings are. Only if you work in smalltalk you can
just add this method to the string class which might help if its not
already there...(lol). You are not really telling me that exposing the
length of two concatenated strings is a real behavior of one of your
classes, do you ? You must be either the programmer of the dotnet
framework string class...or something from outer space...
This kind of behaviors are normally implementation details of real
domain classes..which certainly dont expose length of strings..jeee..
that really defeats every encaps.
I think you've missed my point entirely. It's not *my* code which is
exposing the length of a string - it's the String class itself. If you
think accessors are so bad, you presumably think that String shouldn't
have a Length property. I was giving examples where I would *use* the
fact that String has a length property.
So, do you believe the String class should have a Length property or
not? If not, I've given examples of where I'd want it, and it's up to
you to specify how you'd work round it not being available. If so, it's
clearly not the "never do it ever" anti-pattern you've implied it is,
and you should expand on which situations *do* warrant it and which
don't. Similarly, knowing the length of a string can often easily let you work
out the number of bytes required for the encoded form of a string (if
you're writing an Encoding).
And again..thats the responsibility of the encoder.
Read what I wrote again: "if you're writing an Encoding" (which is
something I've done a few times).
--
Jon Skeet - <sk***@pobox.com> http://www.pobox.com/~skeet
If replying to the group, please do not mail me too
Bill Butler <qw****@asdf.com> wrote:
"Rick Elbers" <ri*********@chello.nl> wrote in message
news:j0********************************@4ax.com...
I hunted around a bit and came up with this:
"Why getter and setter methods are evil " by Alan Holub
http://www.javaworld.com/javaworld/j...5-toolbox.html
pay close attention to the forum that follows the article.
(He does not get unanimous acceptance)
<snip>
Ah yes - I seem to remember seeing it before and disagreeing with it
then. The idea that a class should be able to draw itself just in case
it's needed in a UI seems ridiculous to me - which UI should be picked,
for instance? SWT? Swing? AWT? All three? What about a web UI? What
happened to separating presentation logic from business logic? How can
the author of a business class know all the different ways in which it
may need to be drawn?
It puts the onus on a class to know all the ways in which it might be
used, rather than providing something which can be used in a variety of
situations. I can see it working in some situations, but overall I'm
not a fan.
--
Jon Skeet - <sk***@pobox.com> http://www.pobox.com/~skeet
If replying to the group, please do not mail me too
On Sat, 14 May 2005 01:54:03 GMT, "Bill Butler" <qw****@asdf.com>
wrote:
"Rick Elbers" <ri*********@chello.nl> wrote in message
news:j0********************************@4ax.com.. .
I hunted around a bit and came up with this:
"Why getter and setter methods are evil " by Alan Holub
http://www.javaworld.com/javaworld/j...5-toolbox.html
pay close attention to the forum that follows the article.
(He does not get unanimous acceptance)
It seems to describe your point (if I understand correctly)
-----------------------------------
I can firmly agree that loose coupling is a good idea. (but not always)
I can firmly agree that excessive use of accessors can be bad.
Never using accessors is just plain stupid.
Ofcourse it is. It is however a very good beginnersadvice.
It will make it necessary for them to think before using
obvious functional desicions like using classes as property bags.
Thats in my view probably the single most used abusive of OO.
******************************************
By the way.
You were quite rude in your response to Jon.
Instead of insults and rhetoric, how about examples
to back up your claims (In C#)
You blew off his examples instead of producing the code
Was not ment to be rude. Rather be short, if you take that
for rude I apologize. I believe a lot in being short, even if
the statements are not entiraly correct -good heuristics
never are 100% correct-.
Also I am not any more in the habit of programming for free,
nor in the business of programming as a backing of design-heuristic
statements nor- and thats most important- in the business of
lengthy discusions/arguments. You can try my heuristic in the process
of mentoring if you want, or you don't...suite yourself. If you don't
do mentoring and you are not a beginner yourself then my heuristic
will probably not apply to you.
******************************************
Questions
Should Arrays/collections expose a Length/Count property?
Yes.
Should Custom Collections expose them ?
Less sure
Should your domain object which has a collection expose its
Length/ Count ?
Probably not.
Should strings provide accessors for individual characters?
Sure.
Should your domain object use a string class
Sure
Should your domain object expose characters of its used strings ?
Probably not.
Assuming some class external to string needed to know it's length How would you get it?
Thats where my heuristic points! You dont get it is my *short(rude) *
answer. Think design Think Encapsulatin and take on the challenge to
make your client encapsulate the needed behavior of the client wanting
to know lengthy string..
Not ment to be stupid ofcourse, ment to put programmer in design frame
of mind.
----------------------
Simple example
I read in a string from a file (I don't control the format).
I need to send it across the pipe to another process (I don't control the format)..
The other process is expecting it in this format
NNstring
where NN is the 2 digit length.
anything over 99 characters is truncated to 99 characters
so
"QWERTY" would be 06QWERTY
"Happy Birthday" would be 14Happy Birthday
I would do something like this
Oke stop there!
You have a kind of file! why would you want to send it anywhere if you
know it can't be processed there ? Make either your file check it
himself, or change put to pull mechanism and let your client tell the
file the format he understands.
Thus: NO CODING before design( *dont mean to be rude*)
public string CustomFormat(string str)
{
if (str.Length > 99)
str = str.Substring(0, 99);
return (string.Format("{0:d2}{1}",str.Length, str));
}
--------------------------------
Please post C# code showing how you would solve this
I gave you much more I think then code.
Rick
Thank you
Bill
On Sat, 14 May 2005 06:29:17 +0100, Jon Skeet [C# MVP]
<sk***@pobox.com> wrote: Bill Butler <qw****@asdf.com> wrote:
"Rick Elbers" <ri*********@chello.nl> wrote in message
news:j0********************************@4ax.com...
I hunted around a bit and came up with this:
"Why getter and setter methods are evil " by Alan Holub
http://www.javaworld.com/javaworld/j...5-toolbox.html
pay close attention to the forum that follows the article.
(He does not get unanimous acceptance)
<snip>
Ah yes - I seem to remember seeing it before and disagreeing with it
then. The idea that a class should be able to draw itself just in case
it's needed in a UI seems ridiculous to me - which UI should be picked,
for instance? SWT? Swing? AWT? All three? What about a web UI? What
happened to separating presentation logic from business logic? How can
the author of a business class know all the different ways in which it
may need to be drawn?
We agree! In this kind of cases I rather use bridge pattern which you
only implement IF you need a specific OS/Framework. On the other hand
if you have the choice to make a shape know how to connect to other
shapes and draw itself on device context the shape itself has identity
and is a valid class. If on the otherhand shape is only telling
client-"managers" what it is, can do and how it draws in my view shape
is a property bag which is not a valid class. My choice is to make it
without the managers..:-)
It puts the onus on a class to know all the ways in which it might be
used, rather than providing something which can be used in a variety of
situations.
Interesting statement. Do you think we can formulate a basic tension
in design: encapsulation versus usability ? Class for all users is on
the one hand the absolute monolite, property bag for all users in on
the other hand the absolute dumbo.
I can see it working in some situations, but overall I'm
not a fan.
If we talk the context of beginners it might be different from
experienced programmers. Experienced programmers have made some smart
objects, and know the value of encapsulation. Maybe they are on the
risk of goldplating. Beginners on the other hand certainly those from
procedural or database worlds might gain from the challenge to make
smart objects since their risk might be to make goto spaghetti code
with objects in property bags..
Regards of course,,
Rick
"Rick Elbers" <ri*********@chello.nl> wrote in message
news:bp********************************@4ax.com... On Sat, 14 May 2005 01:54:03 GMT, "Bill Butler" <qw****@asdf.com>
wrote:
Also I am not any more in the habit of programming for free,
nor in the business of programming as a backing of design-heuristic
statements nor- and thats most important- in the business of
lengthy discusions/arguments. You can try my heuristic in the process
of mentoring if you want, or you don't...suite yourself. If you don't
do mentoring and you are not a beginner yourself then my heuristic
will probably not apply to you.
Listen, we are not trying to get you to give away intellectual property for free.
We are attempting to understand your assertions.
It would HELP if you demonstrated with code. (Pseudocode will do)
Do you have any Links you can post that will get across your point?
Can you list any books that promote your point of view?
.... Assuming some class external to string needed to know it's length How would you get it?
Thats where my heuristic points! You dont get it is my *short(rude) *
answer. Think design Think Encapsulatin and take on the challenge to
make your client encapsulate the needed behavior of the client wanting
to know lengthy string..
Not ment to be stupid ofcourse, ment to put programmer in design frame
of mind.
OK, let's expand upon this.
For the sake of arguement (and there has been a lot of that)
I NEED to know the length of a string ... No IFS, ANDS, or BUTS about it.
Since the ElbersString class does not expose it's length I have a dilema
Do I inherit from ElbersString to get at the protected Length?
Is the length available to subclasses or is it inaccesible to them too?
Do I perform a foreach on all of the characters of an ElbersString to get the length.?
Do you call ElbersString.ToCharArray() and then use the length property of the array?
....
----------------------
Simple example
I read in a string from a file (I don't control the format).
I need to send it across the pipe to another process (I don't control the format)..
The other process is expecting it in this format
NNstring
where NN is the 2 digit length.
anything over 99 characters is truncated to 99 characters
so
"QWERTY" would be 06QWERTY
"Happy Birthday" would be 14Happy Birthday
I would do something like this
Oke stop there!
You have a kind of file! why would you want to send it anywhere if you
know it can't be processed there ? Make either your file check it
himself, or change put to pull mechanism and let your client tell the
file the format he understands.
This is a third party file. I have no control over it's format.
The process uses a predefined format that I need to conform to if I am to use it.
I am tasked with creating a way to join the 2.
Thus I need to morph the file format to the format that the external process expects.
I cannot realistically ask either of them to change.
This situalion comes up frequently in my experience.
I really can't think of many good reasons for NOT exposing the string length
The only reason that I can think of is that the string is limited to ~4Gig in size.
In the domain of VERY LARGE strings this is a problem.
in that case you would need to wrap the length inside a class that represented
numbers of arbitrary size. This is massive overkill for most strings.
Thank you
Bill
On Sat, 14 May 2005 14:51:28 GMT, "Bill Butler" <qw****@asdf.com>
wrote:
"Rick Elbers" <ri*********@chello.nl> wrote in message
news:bp********************************@4ax.com.. . On Sat, 14 May 2005 01:54:03 GMT, "Bill Butler" <qw****@asdf.com>
wrote:
Also I am not any more in the habit of programming for free,
nor in the business of programming as a backing of design-heuristic
statements nor- and thats most important- in the business of
lengthy discusions/arguments. You can try my heuristic in the process
of mentoring if you want, or you don't...suite yourself. If you don't
do mentoring and you are not a beginner yourself then my heuristic
will probably not apply to you.
Listen, we are not trying to get you to give away intellectual property for free.
We are attempting to understand your assertions.
It would HELP if you demonstrated with code. (Pseudocode will do)
Do you have any Links you can post that will get across your point?
Can you list any books that promote your point of view?
...
Assuming some class external to string needed to know it's length How would you get it?
Thats where my heuristic points! You dont get it is my *short(rude) *
answer. Think design Think Encapsulatin and take on the challenge to
make your client encapsulate the needed behavior of the client wanting
to know lengthy string..
Not ment to be stupid ofcourse, ment to put programmer in design frame
of mind.
OK, let's expand upon this.
For the sake of arguement (and there has been a lot of that)
I NEED to know the length of a string ... No IFS, ANDS, or BUTS about it.
Since the ElbersString class does not expose it's length I have a dilema
Do I inherit from ElbersString to get at the protected Length?
Is the length available to subclasses or is it inaccesible to them too?
Do I perform a foreach on all of the characters of an ElbersString to get the length.?
Do you call ElbersString.ToCharArray() and then use the length property of the array?
Nice but no tx about ElbersString...its too lengthy:-)
Lets for the sake of argument say I am programmer of the .net
framework team for version 3.0 and we are at this moment just
reviewing features of the framework. The string class has no problems.
It's practically exactly the c++ string class from the stl. NP there.
Do you know that only 10% of programmers are writing business
framework code ? That those are the most experienced in the field.
Do you know that only 1% of programmers write widely published
framework code ? That those are probably the best or most experienced
in the world, or should be ?
Therefore to test some heuristic for learning OO on the hypotheses
that a beginner is writing instead of using stringclass is not sane
imho.
...
----------------------
Simple example
I read in a string from a file (I don't control the format).
I need to send it across the pipe to another process (I don't control the format)..
The other process is expecting it in this format
NNstring
where NN is the 2 digit length.
anything over 99 characters is truncated to 99 characters
so
"QWERTY" would be 06QWERTY
"Happy Birthday" would be 14Happy Birthday
I would do something like this
Oke stop there!
You have a kind of file! why would you want to send it anywhere if you
know it can't be processed there ? Make either your file check it
himself, or change put to pull mechanism and let your client tell the
file the format he understands.
This is a third party file. I have no control over it's format.
The process uses a predefined format that I need to conform to if I am to use it.
I am tasked with creating a way to join the 2.
Thus I need to morph the file format to the format that the external process expects.
Its a third party file. You have no control over its format. Do you
have control over its parsing ? Yes you have. Do you have control over
its use. Yes you have..The design question is not *if you have to
validate*. I can understand that often we have too. The question is
where !( like always with encaps). As soon as possible would be my
answer. Meaning that there is no publicity about the length and all
other features. Its just your first class encountering the format
which knows everything there is to know to connect the 3d party file
to your own components.
I cannot realistically ask either of them to change.
This situalion comes up frequently in my experience.
Yes, sure. Its however besides the argument.
I really can't think of many good reasons for NOT exposing the string length
The only reason that I can think of is that the string is limited to ~4Gig in size.
In the domain of VERY LARGE strings this is a problem.
in that case you would need to wrap the length inside a class that represented
numbers of arbitrary size. This is massive overkill for most strings.
The reason is that exposure should be avoided if possible. Exposure !=
Encapsulation. Therefore.
Thank you
Bill
Thanks too,
Rick
Rick Elbers <ri*********@chello.nl> wrote: Ah yes - I seem to remember seeing it before and disagreeing with it
then. The idea that a class should be able to draw itself just in case
it's needed in a UI seems ridiculous to me - which UI should be picked,
for instance? SWT? Swing? AWT? All three? What about a web UI? What
happened to separating presentation logic from business logic? How can
the author of a business class know all the different ways in which it
may need to be drawn?
We agree! In this kind of cases I rather use bridge pattern which you
only implement IF you need a specific OS/Framework. On the other hand
if you have the choice to make a shape know how to connect to other
shapes and draw itself on device context the shape itself has identity
and is a valid class. If on the otherhand shape is only telling
client-"managers" what it is, can do and how it draws in my view shape
is a property bag which is not a valid class. My choice is to make it
without the managers..:-)
Well, that depends on whether it knows in advance what the managers
will want to do. Again I give the example of String - is that not a
proper class? It only knows about itself and what it consists of. It
allows manipulation (into new strings) and retrieval of the text.
That's all it needs to do.
In other words, it concentrates on its domain (text) and nothing else.
That appeals to me. It puts the onus on a class to know all the ways in which it might be
used, rather than providing something which can be used in a variety of
situations.
Interesting statement. Do you think we can formulate a basic tension
in design: encapsulation versus usability ? Class for all users is on
the one hand the absolute monolite, property bag for all users in on
the other hand the absolute dumbo.
No-one has suggested that all classes should expose everything about
their implementation as properties though. No-one's claimed that
properties are the universal solution - we've just claimed that they're
not the anti-pattern you see them as.
I only expose things as properties when I see a need to, but I often
*do* see a need to expose *some* of the state of a class as a property.
That state isn't always a direct mapping with the variables of the
class, of course - it's the logical state of what the class logically
describes. As such, the state is part of the interface of the class
just as much as the methods are. I can see it working in some situations, but overall I'm
not a fan.
If we talk the context of beginners it might be different from
experienced programmers. Experienced programmers have made some smart
objects, and know the value of encapsulation. Maybe they are on the
risk of goldplating. Beginners on the other hand certainly those from
procedural or database worlds might gain from the challenge to make
smart objects since their risk might be to make goto spaghetti code
with objects in property bags..
So tell people not to expose every variable as a property - tell them
to be selective. I have no problem with that. When you tell them that
properties are anti-patterns with simple statements like "don't use
accessors" you're making far too strong a statement in my view.
--
Jon Skeet - <sk***@pobox.com> http://www.pobox.com/~skeet
If replying to the group, please do not mail me too
Jon,
On Sun, 15 May 2005 07:58:17 +0100, Jon Skeet [C# MVP]
<sk***@pobox.com> wrote: Rick Elbers <ri*********@chello.nl> wrote: >Ah yes - I seem to remember seeing it before and disagreeing with it
>then. The idea that a class should be able to draw itself just in case
>it's needed in a UI seems ridiculous to me - which UI should be picked,
>for instance? SWT? Swing? AWT? All three? What about a web UI? What
>happened to separating presentation logic from business logic? How can
>the author of a business class know all the different ways in which it
>may need to be drawn?
We agree! In this kind of cases I rather use bridge pattern which you
only implement IF you need a specific OS/Framework. On the other hand
if you have the choice to make a shape know how to connect to other
shapes and draw itself on device context the shape itself has identity
and is a valid class. If on the otherhand shape is only telling
client-"managers" what it is, can do and how it draws in my view shape
is a property bag which is not a valid class. My choice is to make it
without the managers..:-)
Well, that depends on whether it knows in advance what the managers
will want to do. Again I give the example of String - is that not a
proper class? It only knows about itself and what it consists of. It
allows manipulation (into new strings) and retrieval of the text.
That's all it needs to do.
In other words, it concentrates on its domain (text) and nothing else.
That appeals to me.
Strange concept of domain do you display here. In my view domain is
application domain. String has no application domain, its a framework
class and as such very special. The string class is appealling ever
since stl prototyped the first version thats sure, however its not my
model for domain classes at all. Its an utility kind of class in my
view. It might be that this is the reason for our miscommunication. >It puts the onus on a class to know all the ways in which it might be
>used, rather than providing something which can be used in a variety of
>situations.
Interesting statement. Do you think we can formulate a basic tension
in design: encapsulation versus usability ? Class for all users is on
the one hand the absolute monolite, property bag for all users in on
the other hand the absolute dumbo.
No-one has suggested that all classes should expose everything about
their implementation as properties though. No-one's claimed that
properties are the universal solution - we've just claimed that they're
not the anti-pattern you see them as.
I only expose things as properties when I see a need to, but I often
*do* see a need to expose *some* of the state of a class as a property.
That state isn't always a direct mapping with the variables of the
class, of course - it's the logical state of what the class logically
describes. As such, the state is part of the interface of the class
just as much as the methods are.
> I can see it working in some situations, but overall I'm
>not a fan.
If we talk the context of beginners it might be different from
experienced programmers. Experienced programmers have made some smart
objects, and know the value of encapsulation. Maybe they are on the
risk of goldplating. Beginners on the other hand certainly those from
procedural or database worlds might gain from the challenge to make
smart objects since their risk might be to make goto spaghetti code
with objects in property bags..
So tell people not to expose every variable as a property - tell them
to be selective. I have no problem with that. When you tell them that
properties are anti-patterns with simple statements like "don't use
accessors" you're making far too strong a statement in my view.
Ok. Strong statements sometimes work, sometimes they dont lol
Regards and see u around,
Rick
"Rick Elbers" <ri*********@chello.nl> wrote in message
news:q9********************************@4ax.com... Jon,
On Sun, 15 May 2005 07:58:17 +0100, Jon Skeet [C# MVP]
<sk***@pobox.com> wrote:
Rick Elbers <ri*********@chello.nl> wrote: >Ah yes - I seem to remember seeing it before and disagreeing with it
>then. The idea that a class should be able to draw itself just in case
>it's needed in a UI seems ridiculous to me - which UI should be picked,
>for instance? SWT? Swing? AWT? All three? What about a web UI? What
>happened to separating presentation logic from business logic? How can
>the author of a business class know all the different ways in which it
>may need to be drawn?
We agree! In this kind of cases I rather use bridge pattern which you
only implement IF you need a specific OS/Framework. On the other hand
if you have the choice to make a shape know how to connect to other
shapes and draw itself on device context the shape itself has identity
and is a valid class. If on the otherhand shape is only telling
client-"managers" what it is, can do and how it draws in my view shape
is a property bag which is not a valid class. My choice is to make it
without the managers..:-)
Well, that depends on whether it knows in advance what the managers
will want to do. Again I give the example of String - is that not a
proper class? It only knows about itself and what it consists of. It
allows manipulation (into new strings) and retrieval of the text.
That's all it needs to do.
In other words, it concentrates on its domain (text) and nothing else.
That appeals to me.
Strange concept of domain do you display here. In my view domain is
application domain. String has no application domain, its a framework
class and as such very special. The string class is appealling ever
since stl prototyped the first version thats sure, however its not my
model for domain classes at all. Its an utility kind of class in my
view. It might be that this is the reason for our miscommunication.
>It puts the onus on a class to know all the ways in which it might be
>used, rather than providing something which can be used in a variety of
>situations.
Interesting statement. Do you think we can formulate a basic tension
in design: encapsulation versus usability ? Class for all users is on
the one hand the absolute monolite, property bag for all users in on
the other hand the absolute dumbo.
No-one has suggested that all classes should expose everything about
their implementation as properties though. No-one's claimed that
properties are the universal solution - we've just claimed that they're
not the anti-pattern you see them as.
I only expose things as properties when I see a need to, but I often
*do* see a need to expose *some* of the state of a class as a property.
That state isn't always a direct mapping with the variables of the
class, of course - it's the logical state of what the class logically
describes. As such, the state is part of the interface of the class
just as much as the methods are.
> I can see it working in some situations, but overall I'm
>not a fan.
If we talk the context of beginners it might be different from
experienced programmers. Experienced programmers have made some smart
objects, and know the value of encapsulation. Maybe they are on the
risk of goldplating. Beginners on the other hand certainly those from
procedural or database worlds might gain from the challenge to make
smart objects since their risk might be to make goto spaghetti code
with objects in property bags..
So tell people not to expose every variable as a property - tell them
to be selective. I have no problem with that. When you tell them that
properties are anti-patterns with simple statements like "don't use
accessors" you're making far too strong a statement in my view.
Ok. Strong statements sometimes work, sometimes they dont lol
Regards and see u around,
Rick
I still don't see your points Rick. Sorry. Asking a string object for its
length is no problem. It wouldn't be a method in that class if it were.
Accessors are good and allow you to valide incoming values to set on the
property. Properties allow more levels of encapsulation. I still don't see
any point for not using them. Although you believe universally they
shouldn't be part of OO. The large number of OO books published will
religiously disagree with you.
What I gather is Rick believes accessors are bad and stings shouldn't expose
length, of which I have seen him make no valid point for those reasons.
Jon, if you believe Rick has made any valid points, please rephrase them
into your own thoughts. I find his wording difficult to understand. It
would help me to see what exactly he is argueing against.
Any who, thanks.
Brett
Brett,
Either you dont want to understand or you really dont.
None of us here is programming stringclasses, so its NOT a valid key
example.
What I said was that in your applications you dont publish things like
stringlength. Maybe you understand this ?
Then for the generalization: in general properties make publicity to
easy. If you want to know something simply ask some class to tell it
to you. Thats not making use of the force of OO. OO shines when
complex behaviors are encapsulated and *not* its implementation
details published.
-One more example about stringlength ?
Lets say we have some compact framework event recorder. Possiblee
events are preconfigured as behaviors and subjects. The configuration
will be done on desktop. Now for the specific stringlength
requirement. It turns out that since we want to score in a datagrid in
a pda behaviors or subject with a name longer then 20 characters is a
problem since they dont fit nicely next to each other on the screen.
On the desktop this is not a problem.
Now how to encapulate this requirement ?
I gave you a few solutions in specific order..
1) Do you want to have an ordinary textbox on a form which asks
Subject for length and performs some truncate if needed ?
* worst solution and will probably use stringlength properties here*
2) Do you want specific inherited textbox's for Subject and Behavior
which knows how to truncate ?
3) Do you want to make Subject and Behavior themselves smart enough to
know how to truncate if needed ?
4) Do you want a new formatter class which to give to Subject and
Behavior to formats its name ?
All of the last three ( and much more of those) allow you to keep the
implementation details with the Subject and Behavior themselves.
Anyways...gl
Rick
On Sun, 15 May 2005 12:11:32 -0400, "Brett" <no@spam.net> wrote:
"Rick Elbers" <ri*********@chello.nl> wrote in message
news:q9********************************@4ax.com.. . Jon,
On Sun, 15 May 2005 07:58:17 +0100, Jon Skeet [C# MVP]
<sk***@pobox.com> wrote:
Rick Elbers <ri*********@chello.nl> wrote:
>Ah yes - I seem to remember seeing it before and disagreeing with it
>then. The idea that a class should be able to draw itself just in case
>it's needed in a UI seems ridiculous to me - which UI should be picked,
>for instance? SWT? Swing? AWT? All three? What about a web UI? What
>happened to separating presentation logic from business logic? How can
>the author of a business class know all the different ways in which it
>may need to be drawn?
We agree! In this kind of cases I rather use bridge pattern which you
only implement IF you need a specific OS/Framework. On the other hand
if you have the choice to make a shape know how to connect to other
shapes and draw itself on device context the shape itself has identity
and is a valid class. If on the otherhand shape is only telling
client-"managers" what it is, can do and how it draws in my view shape
is a property bag which is not a valid class. My choice is to make it
without the managers..:-)
Well, that depends on whether it knows in advance what the managers
will want to do. Again I give the example of String - is that not a
proper class? It only knows about itself and what it consists of. It
allows manipulation (into new strings) and retrieval of the text.
That's all it needs to do.
In other words, it concentrates on its domain (text) and nothing else.
That appeals to me.
Strange concept of domain do you display here. In my view domain is
application domain. String has no application domain, its a framework
class and as such very special. The string class is appealling ever
since stl prototyped the first version thats sure, however its not my
model for domain classes at all. Its an utility kind of class in my
view. It might be that this is the reason for our miscommunication.
>It puts the onus on a class to know all the ways in which it might be
>used, rather than providing something which can be used in a variety of
>situations.
Interesting statement. Do you think we can formulate a basic tension
in design: encapsulation versus usability ? Class for all users is on
the one hand the absolute monolite, property bag for all users in on
the other hand the absolute dumbo.
No-one has suggested that all classes should expose everything about
their implementation as properties though. No-one's claimed that
properties are the universal solution - we've just claimed that they're
not the anti-pattern you see them as.
I only expose things as properties when I see a need to, but I often
*do* see a need to expose *some* of the state of a class as a property.
That state isn't always a direct mapping with the variables of the
class, of course - it's the logical state of what the class logically
describes. As such, the state is part of the interface of the class
just as much as the methods are.
> I can see it working in some situations, but overall I'm
>not a fan.
If we talk the context of beginners it might be different from
experienced programmers. Experienced programmers have made some smart
objects, and know the value of encapsulation. Maybe they are on the
risk of goldplating. Beginners on the other hand certainly those from
procedural or database worlds might gain from the challenge to make
smart objects since their risk might be to make goto spaghetti code
with objects in property bags..
So tell people not to expose every variable as a property - tell them
to be selective. I have no problem with that. When you tell them that
properties are anti-patterns with simple statements like "don't use
accessors" you're making far too strong a statement in my view.
Ok. Strong statements sometimes work, sometimes they dont lol
Regards and see u around,
Rick
I still don't see your points Rick. Sorry. Asking a string object for its
length is no problem. It wouldn't be a method in that class if it were.
Accessors are good and allow you to valide incoming values to set on the
property. Properties allow more levels of encapsulation. I still don't see
any point for not using them. Although you believe universally they
shouldn't be part of OO. The large number of OO books published will
religiously disagree with you.
What I gather is Rick believes accessors are bad and stings shouldn't expose
length, of which I have seen him make no valid point for those reasons.
Jon, if you believe Rick has made any valid points, please rephrase them
into your own thoughts. I find his wording difficult to understand. It
would help me to see what exactly he is argueing against.
Any who, thanks.
Brett
"Rick Elbers" <ri*********@chello.nl> wrote in message
news:1d********************************@4ax.com... Brett,
Either you dont want to understand or you really dont.
None of us here is programming stringclasses, so its NOT a valid key
example.
What I said was that in your applications you dont publish things like
stringlength. Maybe you understand this ?
Then for the generalization: in general properties make publicity to
easy. If you want to know something simply ask some class to tell it
to you.
And how do you expect to ask if all of the answers are hidden? I ask an
object a question. Meaning I access a property. The property has a value.
I guess you call this the answer. What else are you thinking of?
Thats not making use of the force of OO.
What do you mean by "force of OO"?
OO shines when
complex behaviors are encapsulated and *not* its implementation
details published.
I agree. Why do you believe stringlength is an implementation detail? How
the object calculates string length is an implementation detail. The result
of it is not...if it is made public. At some point, if you need string
length, you have to ask for it and the object will give it. i.e.
mystring.length. Or do you plan on calculating this this everytime via some
function you've devised?
-One more example about stringlength ?
Lets say we have some compact framework event recorder. Possiblee
events are preconfigured as behaviors and subjects. The configuration
will be done on desktop. Now for the specific stringlength
requirement. It turns out that since we want to score in a datagrid in
a pda behaviors or subject with a name longer then 20 characters is a
problem since they dont fit nicely next to each other on the screen.
On the desktop this is not a problem.
Now how to encapulate this requirement ?
I gave you a few solutions in specific order..
1) Do you want to have an ordinary textbox on a form which asks
Subject for length and performs some truncate if needed ?
* worst solution and will probably use stringlength properties here*
2) Do you want specific inherited textbox's for Subject and Behavior
which knows how to truncate ?
3) Do you want to make Subject and Behavior themselves smart enough to
know how to truncate if needed ?
4) Do you want a new formatter class which to give to Subject and
Behavior to formats its name ?
All of the last three ( and much more of those) allow you to keep the
implementation details with the Subject and Behavior themselves.
I agree. However, at some point you'll need to ask for this length (via
property because I doubt the FLC exposes it as a field) or calculate it.
Maybe I'm still not understanding your point. Sorry if that is the case.
Anyways...gl
Rick
On Sun, 15 May 2005 12:11:32 -0400, "Brett" <no@spam.net> wrote:
"Rick Elbers" <ri*********@chello.nl> wrote in message
news:q9********************************@4ax.com. .. Jon,
On Sun, 15 May 2005 07:58:17 +0100, Jon Skeet [C# MVP]
<sk***@pobox.com> wrote:
Rick Elbers <ri*********@chello.nl> wrote:
> >Ah yes - I seem to remember seeing it before and disagreeing with it
> >then. The idea that a class should be able to draw itself just in
> >case
> >it's needed in a UI seems ridiculous to me - which UI should be
> >picked,
> >for instance? SWT? Swing? AWT? All three? What about a web UI? What
> >happened to separating presentation logic from business logic? How
> >can
> >the author of a business class know all the different ways in which
> >it
> >may need to be drawn?
>
> We agree! In this kind of cases I rather use bridge pattern which you
> only implement IF you need a specific OS/Framework. On the other hand
> if you have the choice to make a shape know how to connect to other
> shapes and draw itself on device context the shape itself has identity
> and is a valid class. If on the otherhand shape is only telling
> client-"managers" what it is, can do and how it draws in my view shape
> is a property bag which is not a valid class. My choice is to make it
> without the managers..:-)
Well, that depends on whether it knows in advance what the managers
will want to do. Again I give the example of String - is that not a
proper class? It only knows about itself and what it consists of. It
allows manipulation (into new strings) and retrieval of the text.
That's all it needs to do.
In other words, it concentrates on its domain (text) and nothing else.
That appeals to me.
Strange concept of domain do you display here. In my view domain is
application domain. String has no application domain, its a framework
class and as such very special. The string class is appealling ever
since stl prototyped the first version thats sure, however its not my
model for domain classes at all. Its an utility kind of class in my
view. It might be that this is the reason for our miscommunication.
> >It puts the onus on a class to know all the ways in which it might be
> >used, rather than providing something which can be used in a variety
> >of
> >situations.
>
> Interesting statement. Do you think we can formulate a basic tension
> in design: encapsulation versus usability ? Class for all users is on
> the one hand the absolute monolite, property bag for all users in on
> the other hand the absolute dumbo.
No-one has suggested that all classes should expose everything about
their implementation as properties though. No-one's claimed that
properties are the universal solution - we've just claimed that they're
not the anti-pattern you see them as.
I only expose things as properties when I see a need to, but I often
*do* see a need to expose *some* of the state of a class as a property.
That state isn't always a direct mapping with the variables of the
class, of course - it's the logical state of what the class logically
describes. As such, the state is part of the interface of the class
just as much as the methods are.
> > I can see it working in some situations, but overall I'm
> >not a fan.
>
> If we talk the context of beginners it might be different from
> experienced programmers. Experienced programmers have made some smart
> objects, and know the value of encapsulation. Maybe they are on the
> risk of goldplating. Beginners on the other hand certainly those from
> procedural or database worlds might gain from the challenge to make
> smart objects since their risk might be to make goto spaghetti code
> with objects in property bags..
So tell people not to expose every variable as a property - tell them
to be selective. I have no problem with that. When you tell them that
properties are anti-patterns with simple statements like "don't use
accessors" you're making far too strong a statement in my view.
Ok. Strong statements sometimes work, sometimes they dont lol
Regards and see u around,
Rick
I still don't see your points Rick. Sorry. Asking a string object for
its
length is no problem. It wouldn't be a method in that class if it were.
Accessors are good and allow you to valide incoming values to set on the
property. Properties allow more levels of encapsulation. I still don't
see
any point for not using them. Although you believe universally they
shouldn't be part of OO. The large number of OO books published will
religiously disagree with you.
What I gather is Rick believes accessors are bad and stings shouldn't
expose
length, of which I have seen him make no valid point for those reasons.
Jon, if you believe Rick has made any valid points, please rephrase them
into your own thoughts. I find his wording difficult to understand. It
would help me to see what exactly he is argueing against.
Any who, thanks.
Brett
"Brett" <no@spam.com> wrote in message
news:eG**************@TK2MSFTNGP09.phx.gbl...
Hi Brett,
I think that we will have to agree to disagree with Rick.
Encapsulation is a great idea, but not at the expense of usability.
Rick has quite a few valid points.
I just don't agree with the degree of zeal he uses in eliminating accessors.
I think that we can all agree that certain aspects of a object's structure
SHOULD remain unknown.
This allows for changes in implementation of the class that don't break code
that relies on the class.
Outwardly, I don't care HOW an X class is implemented.
I do care if it's interface changes however.
If X class was originally designed using a linear search algorithm and later
changed to use a Binary search, it would be nice is nothing more than a
recompile was required to get the benefits.
In an old app I was working on there was a real problem when they started
doing business in Canada.
It turns out that Postal codes in Canada don't fit in a 5 digit field. (They
are composed of 6 Alphanumeric characters)
I guess making Zip to be of type int was a bad idea. :^)
International addresses/phone numbers cause problems as well.
or
"Hey, we only have 230 products, lets store it in a byte to save space."
(not a problem if only used internally)
"Oooops, we just added 30 new products" (I hope no one is going to break)
I saw this happen. Only internal apps where effected, but there where
HUNDREDS of them. (OUCH!!!)
In the case of your original request:
Unless a URL will ever be anything other than a string, I think you are
safe.
Bill
Rick Elbers <ri*********@chello.nl> wrote: Well, that depends on whether it knows in advance what the managers
will want to do. Again I give the example of String - is that not a
proper class? It only knows about itself and what it consists of. It
allows manipulation (into new strings) and retrieval of the text.
That's all it needs to do.
In other words, it concentrates on its domain (text) and nothing else.
That appeals to me.
Strange concept of domain do you display here.
Not particularly - but not the same as business domain, which I agree
the word "domain" is also often used for. As far as I'm concerned, the
domain of a class is the area in which it works - what its concerns
are, etc. So tell people not to expose every variable as a property - tell them
to be selective. I have no problem with that. When you tell them that
properties are anti-patterns with simple statements like "don't use
accessors" you're making far too strong a statement in my view.
Ok. Strong statements sometimes work, sometimes they dont lol
Yup - just like my strong statements didn't work for you when it came
to operator overloading :)
--
Jon Skeet - <sk***@pobox.com> http://www.pobox.com/~skeet
If replying to the group, please do not mail me too
Rick Elbers <ri*********@chello.nl> wrote: Either you dont want to understand or you really dont.
None of us here is programming stringclasses, so its NOT a valid key
example.
It is if you claim properties to be anti-patterns *in general* - it's
suggesting that basically the whole of the framework (which uses
properties fairly heavily) is horrendously designed.
What I said was that in your applications you dont publish things like
stringlength. Maybe you understand this ?
Then for the generalization: in general properties make publicity to
easy. If you want to know something simply ask some class to tell it
to you. Thats not making use of the force of OO. OO shines when
complex behaviors are encapsulated and *not* its implementation
details published.
I would say that OO shines when the interface is designed appropriately
- when thought goes into the difference between the fundamental
properties of an interface, and its implementation. I see nothing wrong
with exposing properties where they naturally form part of the public
nature of an object which is being represented. Indeed, restricting
yourself to using methods can force behaviour to be complex when it
needn't be. Complexity should be avoided where possible!
--
Jon Skeet - <sk***@pobox.com> http://www.pobox.com/~skeet
If replying to the group, please do not mail me too
Well, what you've implemented using a property is a good candidate for
implementation as a public constant. After all, the URL is but a constant! So
you'd better implement such things as public constants rather than properties
that return hard quoted values.
Now to your second question. It's not necessary to declare a field as
readonly if you've only a get accessor. You should however mark a field as
readonly if you're not going to change its value other than in the
constructor or in the declaration statement.
Regards,
"Brett" wrote: 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
"Ejan" <Ej**@discussions.microsoft.com> wrote in message
news:3C**********************************@microsof t.com... Well, what you've implemented using a property is a good candidate for
implementation as a public constant. After all, the URL is but a constant!
So
you'd better implement such things as public constants rather than
properties
that return hard quoted values.
What are the advantages/disadvantages of both approaches in my case?
Now to your second question. It's not necessary to declare a field as
readonly if you've only a get accessor. You should however mark a field as
readonly if you're not going to change its value other than in the
constructor or in the declaration statement.
Regards,
"Brett" wrote:
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
Ejan <Ej**@discussions.microsoft.com> wrote: Well, what you've implemented using a property is a good candidate for
implementation as a public constant. After all, the URL is but a constant! So
you'd better implement such things as public constants rather than properties
that return hard quoted values.
Well, it currently is. There's nothing to say it'll stay as a constant
though. I don't think we can really say for sure without knowing more
about the situation.
Now to your second question. It's not necessary to declare a field as
readonly if you've only a get accessor. You should however mark a field as
readonly if you're not going to change its value other than in the
constructor or in the declaration statement.
Yup.
--
Jon Skeet - <sk***@pobox.com> http://www.pobox.com/~skeet
If replying to the group, please do not mail me too
Yes, the second method is absolutely better than the first.
1.) Hides the source of the data. It is impossible to switch out where
myString comes from without changing the signature of the class. Fields vs.
ViewState vs. SessionState vs ApplicationState is a perfect example in the
ASP.NET world. Accessors keep the design flexible.
2.) Exposing a field makes it impossible to do (externally) read only/write
only data.
3.) It is impossible to do error checking (ex. Range Checking) on data, as
you can not tell when it is being set.
4.) myString can not be abstracted into an interface because you can not
have fields in interfaces.
It's less typing to create a field, yes. However, the flexibility gained by
using them definately makes up for it. Furthurmore, Visual Studio
(especially w/2005) will put in much of this property get/set framework in
for you automatically.
"Steve Walker" wrote: In message <d6********************************@4ax.com>, Rick Elbers
<ri*********@chello.nl> writes
On Tue, 10 May 2005 19:15:37 +0100, Jon Skeet [C# MVP]
<sk***@pobox.com> wrote:
Rick Elbers <ri*********@chello.nl> wrote:
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.
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.
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,
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 This thread has been closed and replies have been disabled. Please start a new discussion. Similar topics
by: James Thurley |
last post by:
I'm having a problem figuring out the best way to use Properties in my
code. Here are the 'good practices' I have in my head:
1) Variables should always be accessed through Properties where...
|
by: Jam Pa |
last post by:
I would like to hear recommendations on good CSS editors.
Personally, I would like a CSS editor with 'code-completion'.
In effect, I would like to be able to see different properties and their...
|
by: Raposa Velha |
last post by:
Hello to all!
Does any of you want to comment the approach I implement for
instantiating a form? A description and an example follow.
Cheers,
RV
jmclopesAThotmail.com replace the AT with the...
|
by: Sky Sigal |
last post by:
Hello:
I'm currently messing around, and need as much feedback/help as I can get, trying to find the most
economical/graceful way to build usercontrols that rely on styling to look any good...
...
|
by: Daniel Sélen Secches |
last post by:
I found a good class to do a simple FTP.
Very good....
I'm posting it with the message, i hope it helps someone
==============================================================
Imports...
|
by: GS |
last post by:
Hi,
I'd rather start from a good design and go from there so would be greatfull
for any input.
I have a simple ASP.NET application and would like to make solution elegant.
I store settings in...
|
by: Kevin Hall |
last post by:
C++ is one of my favorite languages to work in. This is because it has
so many differrent strengths. But there is also a number of blemishes
in the language -- some could potentially be fixed,...
|
by: Nathan Sokalski |
last post by:
I am looking for a reference that lists the equivelant JavaScript/JScript
properties (for example, it took me a while to find that event.x/event.y
were the IE equivelant of...
|
by: David Thielen |
last post by:
Hi;
I've got 2 questions about features in the new C#.
The first is where I can do "var x = new MyObject()" instead of
"MyObject x = new MyObject()". This strikes me as a step back to Basic...
|
by: Charles Arthur |
last post by:
How do i turn on java script on a villaon, callus and itel keypad mobile phone
|
by: emmanuelkatto |
last post by:
Hi All, I am Emmanuel katto from Uganda. I want to ask what challenges you've faced while migrating a website to cloud.
Please let me know.
Thanks!
Emmanuel
|
by: BarryA |
last post by:
What are the essential steps and strategies outlined in the Data Structures and Algorithms (DSA) roadmap for aspiring data scientists? How can individuals effectively utilize this roadmap to progress...
|
by: nemocccc |
last post by:
hello, everyone, I want to develop a software for my android phone for daily needs, any suggestions?
|
by: Sonnysonu |
last post by:
This is the data of csv file
1 2 3
1 2 3
1 2 3
1 2 3
2 3
2 3
3
the lengths should be different i have to store the data by column-wise with in the specific length.
suppose the i have to...
|
by: Hystou |
last post by:
There are some requirements for setting up RAID:
1. The motherboard and BIOS support RAID configuration.
2. The motherboard has 2 or more available SATA protocol SSD/HDD slots (including MSATA, M.2...
|
by: jinu1996 |
last post by:
In today's digital age, having a compelling online presence is paramount for businesses aiming to thrive in a competitive landscape. At the heart of this digital strategy lies an intricately woven...
|
by: tracyyun |
last post by:
Dear forum friends,
With the development of smart home technology, a variety of wireless communication protocols have appeared on the market, such as Zigbee, Z-Wave, Wi-Fi, Bluetooth, etc. Each...
|
by: agi2029 |
last post by:
Let's talk about the concept of autonomous AI software engineers and no-code agents. These AIs are designed to manage the entire lifecycle of a software development project—planning, coding, testing,...
| |
