Partially related to my earlier question , I have a system in which I have to store complex data as a string. Instead of analyzing these strings as all kinds of separate objects, I just created one class containing all these objects, and it has parser logic that will encode all the properties into strings or decode the string to get these objects. This is all beautiful and good. This question is not about the parser itself, but about where I should have the logic for the parser. Is it better to use it as a property or as a method?
In the case of a property, say public string DataAsString, an accessory getwill contain logic to encode all the data into a string, while the accessory setwill decode the input value and set all the data in an instance of the class. This seems convenient because I / O is really a string.
In the case of a method, there will be one method Encode()that returns an encoded string. Then, either the constructor itself will contain the logic for decoding the string and requires a string argument, or I am writing a method Decode(string str)that is called separately. In any case, he would use a method instead of a property.
So, is there a functional difference between these paths in terms of actually running the code? Or are they basically equivalent, and then it comes down to choosing personal preferences or for the better? And in such a question ... which will still look cleaner?
source
share