Re: fields or properties

Tech-Archive recommends: Fix windows errors by optimizing your registry


"glenn" <ghan***@xxxxxxxxxxxxxxxxxx> wrote in message
news:u2MiLJPQFHA.3288@xxxxxxxxxxxxxxxxxxxxxxx
> Actually I fail to see your point. There seem to be a couple things you
> might be forgetting.

>From what I have read below, I can see that you failed to see my point. But
I'll try to explain it to you.
As a systems architect, I am responsible for making sure that each project
I'm involved in; have a certain amount of quality; they vary in scale and
can easily be translated into how much our customers are willing to pay.

'Quality' for me, is a jagged array. There is performance issues, milestone
issues, deadline issues, readability and maintainability, and also a lot of
coffee involved. But in the end; - Quality == Economics.

> 1) Its impossible to know today what might come up next week or even next
> year that causes a design to change. Starting out with public fields
> allows
> decendents of a class to directly access those fields, even if later you
> decide that exposing the customer name field was a huge mistake. Having
> it
> use properties up front might take a little extra work on your part, but
> your class is much more adaptable to future needs.

RUP might think so, while Agile-spawned methologies having the
YAGNI-principle. - You Ain't Gonna Need It!

How often do entities change? Do we code in Notepad or Visual Studio? How
much time does it take to refactor a sequence of objects? I know that ctrl-h
enables me to search and replace. VS2005 and especially Eclipse have
excellent support for turning a field into a property (get./set-method), and
a property into a method.

This is the real problem with the oldschool OO-purist camp. They still live
in a world of Notepad (edlin?) and Emacs. .NET is built on namespaces and
typed classes, not files and variant functions. Refactoring is a simple task
nowadays. Many principles in OO are just dogma.

> 2) Your argument that exposing a field allows your class to be much more
> powerful seems rediculous. What it seems you are actually doing is making
> your class much less capable of changing with future needs that may arrise
> because trying to go back and change a public field to a private field
> might
> be an impossible task 2 years later.

Rediculous?

This is the classic Java-argument. They don't need Properties and Events
(while still having them in .jsp/struts in an awkward way *s*).

The Java argument: - Sure we don't need properties, we can settle for
getters and setters. We don't need events, we can have nested classes and
interfaces.

The great thing with (Anders Hjelsberg and...) the MPE-model, Methods,
Properties and Events, is that the destinction tells you something.

And I've heard the argument before. - But what if a property does work? But
if the method just return a value?

- Well, then you are a lousy coder and don't belong in my crew. The argument
is just not there. What if a programmer write the boolean method IsValid
that deletes all files with .mp3 as an extention on all your drives? That
dude is evil, incompetent and/or have a serious communication problems.

It's all about granularity. If you know how to use MPE and fields you know
what to expect. If you do it wrong you just have poor communication skills
as a coder.

> If you choose to have public fields in your class designs then that is
> your
> business and perhaps it works for you, however, telling someone that
> doesn't
> understand the ramifications of doing that, that you "Should" do it, seems
> a
> little rediculous. I think that exposing fields like that should be given
> extreme care and in the end, I just don't see the advantage. You saved
> yourself a very few keystrokes up front, but what have you potentially
> done
> to yourself and those using your components later on?

Oh, I see your problem. The ctrl-shift-h and a find/replace takes seconds. A
ctrl-shift-b to rebuild also takes seconds. And by your reasoning; I should
have my coders do hours of coding and pageup/pagedown for the fear of
change?

Change is natural. There is nothing to fear. This is our job...

I do code in languages that sports properties. One of them is C#. Another is
Delphi. For obvious reasons netiher can handle a property as ref (var). And
that may be one argument why public fields are bad. If you sport a field and
it turns into a property it will no longer work with out and ref in C# and
therefor break code.

But there is a simple solution to that problem: - Treat fields as
properties.
As properties may or may not do work and may or may not do validation, we
already have the idiom of always making sure to pull the value from a
property once, use it locally, and set it after your done with it. The grand
old snapshot/transaction dilemma.

- Treat fields as properties.

Tada! Problem solved...

> Sorry if my wording sounds like I'm attacking you as I'm not. Just
> expressing my opinion...

This is an interesting topic. Our opinions may vary, the arguments may be
flamable; but I do respect you while I attack you!

My argument is still:

If a class (Person) denotes a concept of description (Name) while the class
has no concept of what Name might contain, it is far better to keep it as a
public field than turning into a property that does nothing.

A Method implies Work.
A Property implies Knowledge
An Event implies Action.
A field is just a variable (with type).

I live by the above implicit rules.

And back to Economics. If you worked for me and spent (invoicing)-time on
making a field into a property that does nothing, you would get some serious
spanking an also have to de-bloat your code on you spare time. Your code
would simple not pass my eye-balling test...

>
> just my 2 cents,

I see your 2 cents and raise you 5. And I will raise you on the flop, street
and river. I've got two aces.. =)

> glenn

- Michael S


.

Quantcast