Welcome to the Lounge
For lazing about and discussing anything in a software developer's life that
takes your fancy except programming questions.
Technical discussions are encouraged,
but click here to ask your programming
The Lounge is rated PG. If you're about to post something you wouldn't want your
kid sister to read then don't post it. No flame wars, no abusive conduct, no programming
questions and please don't post ads.
|I read the article from the Insider[^] about properties and methods and the author states
Quote:Properties should be stable: that is, the value of a property shouldn't change “on its own". Rather, changes in properties are the results of calling property setters, or some other action changing the state of the object
So the mass of a car can be a property since it doesn't change, but the total mass, including fuel, can't be since fuel is burned and so changes.
A specific example is
DateIime.Now which should not be a property because it changes and really ought to have been a method
I'm assuming the author means we should have a
IimeZone object with a
Now property, with
Now being updated explicitly through some process such as
TimeZone.Now = DateTime.GetCurrentDateIime(). Which seems a great way to spend your spare CPU cycles.
Can someone smarter than me please explain why properties should only be things that can't change? To stretch the car analogy if you have an
Radiator object with the
Radiator having a property
Temperature then I can accept the argument that the water doesn't get hotter on its own. You'd have something like
water.Temperature += Degrees(10);
But what of the
Car object that aggregates an
Engine and a
Radiator object? The car's
EngineIemperature property (which is a façade for the
Engine.Temperature property) is going to change "on its own" sorta kinda. It'll change due to changes passed on by internal objects.
The author states
Quote:Property getters should always succeed: they should never throw an exception. Return some reasonable default value if the property cannot be logically computed right now because the object is in a bad state.
Doesn't this fly in the face of the "use exceptions not error codes" argument. I understand we're not talking about returning an error code - we're talking about completely hiding the fact that there was an error and simply returning a value that is "reasonable". In fact aren't we simply bypassing the entire exception-vs-errorcode debate and simply ignore it?
Sure - you can return
null values for properties that don't currently exist on an object, but what if a property is expansive to retrieve and a timeout / resource error / whatever happens while querying the property. Surely something should be mentioned to the caller that may the value they have is a little dodgy and maybe they should try again later?
All in all this seems like a discussion on theoretical guidelines that ignore important realities.
What are your thoughts? Where am I going wrong in my thinking here?
General News Suggestion Question Bug Answer Joke Praise Rant Admin
Use Ctrl+Left/Right to switch messages, Ctrl+Up/Down to switch threads, Ctrl+Shift+Left/Right to switch pages.