Reputation: 9 Worker
- Active Members
- Active Posts:
- 98 (0.04 per day)
- 15-April 10
- Profile Views:
- Last Active:
- Dec 05 2014 07:58 AM
- OS Preference:
- Favorite Browser:
- Favorite Processor:
- Favorite Gaming Platform:
- Your Car:
- Who Cares
- Dream Kudos:
Posts I've Made
Posted 4 Dec 2014I'm sorry, I think you misunderstood me. I did not mean any offense or to imply that I wanted to see a copy/paste template.
I'm still learning and I considered both the OP's approach (a class to handle validation) and the approach mentioned in the properties tutorial and to me having a class do it seemed more sensible so I pointed out what problem I saw with using properties to handle validation.
Since I'm still learning this is probably just me talking out of my arse, but this is the way I understand it and it can be handled in two general different ways. Let's say we have a field that can be changed both by the user and by some other part of the program (maybe a meeting date or something that can be set by the user manually, or changed automatically by some scheduler or something).
So by having a class handle validation, we can eliminate the biggest issue that is pointed out in the properties tutorial - doing it once in one place instead of having the same code copied in many places. The flow would be something like this, from what I imagine:
- User enters an invalid value into a field.
- UI calls validation on the entered value. The value is invalid.
- UI can now easily prompt the user to enter a correct value.
- User enters a valid value into the field.
- UI calls validation on the value. It is valid.
- UI sets the property to equal the value.
Or if the property is updated by something else:
- Some kind of calculation is done and due to some factors the value to be set is invalid.
- Validation is called on the new value. The value is invalid.
- We now again have immediate information of where and why the value is no longer valid, so we can either throw errors or handle it whatever other way.
So all that is to say is that the caller that would be setting the property is the one that would handle invalid values.
Now if I do it using properties, then the flow becomes like this, and it's the same flow for either user input or a change from somewhere else:
- Invalid value is passed to the property.
- Property validates it and finds it to be invalid.
- Property now doesn't really know what to do next.
So now there's some different ways I can go from here.
I could, like in the properties tutorial, have a pre-defined value to mean that it is invalid. So age of 0 is pretty obviously not a valid age in most cases. So then I could have the caller check the value after setting it to see that the value was valid.
age = value;
if (age == 0)
//handle invalid value
That seems pretty clunky to me, and what about properties that hold values that cannot easily have a pre-defined value to act as a means to convey that the value is incorrect?
Or another way, I could instead issue some kind of event about validation failing from the property itself. But this presents the following problem - if I'm setting the property from different places, they would all be listening to the event at the same time, so how do I know which one it was meant for? Maybe I could subscribe to the event only when setting the property, and then immediately unsubscribe from it afterwards? Sounds to me like unnecessary complexity. I'd have to remember to do this for any new code that sets that property. And although I haven't yet done any kind of multi-threading, this also appears to me that it might cause issues there, too.
I'm just trying to fully understand this pattern and where it fits. I do not currently have a programming job and so have no specific requirements to see if this pattern fits, and so instead, I'm actually trying to figure out what requirements would fit this pattern.
Posted 2 Dec 2014Hi tlhIn`toq, that's a good explanation and I understand the point you have in the Properties tutorial in your signature, but then I'm a bit confused.
What happens when the property validates itself, finds a problem, and sets itself to 0? There still needs to be code now to handle the problem, and the change to the property might have come from the UI, or it might have come from elsewhere entirely. So how then does the property know how to handle it?
Whereas if you handle the validation on the UI then the UI of course knows everything it needs to handle the problem.
Posted 18 Nov 2014Quick question for you, modi - From your experience, does having a class that acts as the communication between client and server lead to any problems in large applications? For example the Agent class from your example you linked. Let's say it was part of a large scale commercial application (just curious how this works out in real applications), any change to the Agent class would require identical changes deployed to both the client program and the server program.
Posted 18 Nov 2014I see. Serialization is what I was missing. So I can create an object that holds whatever command information I want to send to the server, and then serialize it and pass it over. The server deserializes it and acts upon the data. Perfect, thanks!
- Member Title:
- D.I.C Head
- Age Unknown
- Birthday Unknown
KBoogle hasn't added any friends yet.