- Feature Articles
- CodeSOD
- Error'd
-
Forums
-
Other Articles
- Random Article
- Alex's Soapbox
- Announcements
- Best of…
- Best of Email
- Best of the Sidebar
- Bring Your Own Code
- Coded Smorgasbord
- Mandatory Fun Day
- Off Topic
- Representative Line
- News Roundup
- Editor's Soapbox
- Software on the Rocks
- Souvenir Potpourri
- Sponsor Post
- Tales from the Interview
- The Daily WTF: Live
- Virtudyne
Admin
What is also a bit interesting, is the Status property-changed event appears to be raised, but the value... meh, not so much.
Admin
The comment doesn't even justify making the property private. The justification given supports a public property with a private setter.
Edit Admin
You gotta admit: it does keep clients from changing the status. Mission accomplished!
Edit Admin
I'm a bit confused, because this seems perfectly fine.
You cannot change the status but there's a setter so that you can get the event that you didn't change the status.
This is actually how it should be in an API with an observer; you can still trigger the event but you can't change the internal state and the event will appropriately reflect that. There is tons of reasons why you do this, one major one is E2E and integration testing. It's basically design by contract: you can only enforce a contract where a contract can be validated. If the property setter is private, there is no testable contract and this means there will be no tests to enforce it.
Edit Admin
The only personal issue I have with this setter is that it is missing an Obsolete attribute on a warning level.
BUT I had many clients in the past that used something like Sonar as a management hammer instead of actually for what it is actually intended, as a tool to empower devs to deliver better quality, so I totally understand why developers would avoid proper life cycle management of their APIs, especially when it's an internal one with no consequences. But eh, that's pretty much the only issue I can spot with this code for the reason stated right above.
Edit Admin
You are, indeed, confused, because you go on to say that this is perfectly fine. In what weird world is it remotely acceptable to (strikeout)have this property even exist(1)(/strikeout) have a property whose "set" method completely ignores the requested new value and simply raises some sort of event that the requested new value was accepted.
(1) I return to my general thesis that whoever it was that thought that properties were a good idea was ... well, even among first-stripe fucknuts, this person was a first-stripe fucknut.