Is this good use of Properties?

[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.

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

Jon,

On Sun, 15 May 2005 07:58:17 +0100, Jon Skeet [C# MVP]

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

 

[Bill Butler]

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

 

[Jon Skeet [C# MVP]]

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.

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 [C# MVP]]

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!

 

[Guest]

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]

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?

 

[Jon Skeet [C# MVP]]

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.

 

[Guest]

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.