Is this good use of Properties?

[Jon Skeet [C# MVP]]

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]

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

 

[Jon Skeet [C# MVP]]

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 ?

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.

 

[Steve Walker]

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

 

[Rick Elbers]

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

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

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.

But adding indirection isn't bad OO.

No..its just bad..if thats all there is.

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

 

[Jon Skeet [C# MVP]]

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?

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.

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?

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.

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.

 

[Rick Elbers]

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

 

[Jon Skeet [C# MVP]]

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

 

[Rick Elbers]

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

 

[Bill Butler]

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/jw-09-2003/jw-0905-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

 

[Jon Skeet [C# MVP]]

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.

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

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/jw-09-2003/jw-0905-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.

 

[Rick Elbers]

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/jw-09-2003/jw-0905-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));
}

I gave you much more I think then code.

Rick

 

[Rick Elbers]

<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

 

[Bill Butler]

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?

....

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

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

 

[Rick Elbers]

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?

...


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.

...

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

 

[Jon Skeet [C# MVP]]

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.

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.

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.

 

[Rick Elbers]

Jon,

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.

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.


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

 

[Brett]

Jon,



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.




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]

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