Design Guidelines
-
I believe all .net programmers should have read MS' guidelines for class library developers. Everyone writes code that others are to use and/or maintain, which means we are library developers! I generally think the guidelines are pretty good, but I noticed this little gem: Error Raising and Handling Guidelines Throw the InvalidOperationException exception if a call to a property set accessor or method is not appropriate given the object's current state. Property Usage Guidelines Allow properties to be set in any order. Properties should be stateless with respect to other properties.
-
I believe all .net programmers should have read MS' guidelines for class library developers. Everyone writes code that others are to use and/or maintain, which means we are library developers! I generally think the guidelines are pretty good, but I noticed this little gem: Error Raising and Handling Guidelines Throw the InvalidOperationException exception if a call to a property set accessor or method is not appropriate given the object's current state. Property Usage Guidelines Allow properties to be set in any order. Properties should be stateless with respect to other properties.
There are other ways to change state than properties. For example, if a form has closed, that would change the state and calling a property on that form might then be invalid. And if an object was constructed with a certain value, that may restrict the values that may be set on properties (if, for example, a collection is read only you would then not be able to call a remove method). And let's not forget about the property itself. You might set the capacity of a collection to a certain value. Subsequently setting that capacity to a lower value might be considered invalid if that collection does not support shrinking. Still, good catch :thumbsup:
Visual Studio is an excellent GUIIDE.
-
I believe all .net programmers should have read MS' guidelines for class library developers. Everyone writes code that others are to use and/or maintain, which means we are library developers! I generally think the guidelines are pretty good, but I noticed this little gem: Error Raising and Handling Guidelines Throw the InvalidOperationException exception if a call to a property set accessor or method is not appropriate given the object's current state. Property Usage Guidelines Allow properties to be set in any order. Properties should be stateless with respect to other properties.
dojohansen wrote:
Properties should be stateless with respect to other properties.
I guess the intent is to let consumers set a bunch of properties in any order. For the Point class, for e.g., it shouldn't matter whether X is set before Y, or vice versa. OTOH, WPF has "freezable" components, which, when frozen, don't allow setters. In any case, the guidelines say that properties should be stateless with respect to other properties, not that they shouldn't use the object's state :)
Regards Senthil _____________________________ My Home Page |My Blog | My Articles | My Flickr | WinMacro
-
There are other ways to change state than properties. For example, if a form has closed, that would change the state and calling a property on that form might then be invalid. And if an object was constructed with a certain value, that may restrict the values that may be set on properties (if, for example, a collection is read only you would then not be able to call a remove method). And let's not forget about the property itself. You might set the capacity of a collection to a certain value. Subsequently setting that capacity to a lower value might be considered invalid if that collection does not support shrinking. Still, good catch :thumbsup:
Visual Studio is an excellent GUIIDE.
aspdotnetdev wrote:
There are other ways to change state than properties.
That is true. But since properties aren't really supposed to represent operations it still seems weird to throw InvalidOperationException from them. Setters should of course throw ArgumentException (or derived classes) for invalid values (but not due to the state of the object). In your closed form example, I can't really imagine what property might be usefully set after it's closed, but nor can I see much use for an exception. Of course there are always cases that are kind of bordering and it's not always obvious if something should be a property or a method. And Microsoft themselves violate the guidelines here and there. For example, the setter of Stream.Position throws NotSupportedException if the stream doesn't support seeking. In this case there's really no alternative other than make a SetPosition() method instead of the property, but then again what's so bad about that? It would signify to the user (of the library) the possibility that setting even a legal and semantically meaningful value may not succeed. [EDIT] I guess they aren't really violating the guideline with Stream.Position. It's not due to the state of the instance but due to the *type* of stream, and throwing NotSupportedException (rather than InvalidOperationException) is probably perfectly within the guidelines. I imagine I've seen cases where properties must be set in a particular order, but I can't remember what they are so I might be mistaken! [/EDIT] Properties allow us to write (or read) a bit less code and often the code using them also becomes more readable, but there is nothing one can achieve with properties that cannot be achieved with get-set methods. It's what they are, after all. So these purely conventional aspects are really what makes them truly useful. If I use a database connection object, I know I can set the connection string to anything I want and nothing should go wrong until (at the earliest) I attempt to open the connection, just because it's a property and not a method for doing this. If an object requires a lot of configuration, it's nice to know I can set the properties in any order, another convention (and of course the reason why they should be stateless with regard to other properties). And if I call Open() without having set the connection string, that would be a truly good time to throw InvalidOperationException.
-
I believe all .net programmers should have read MS' guidelines for class library developers. Everyone writes code that others are to use and/or maintain, which means we are library developers! I generally think the guidelines are pretty good, but I noticed this little gem: Error Raising and Handling Guidelines Throw the InvalidOperationException exception if a call to a property set accessor or method is not appropriate given the object's current state. Property Usage Guidelines Allow properties to be set in any order. Properties should be stateless with respect to other properties.
Wonder if MS follow them as well as their own UI guidelines....
-
I believe all .net programmers should have read MS' guidelines for class library developers. Everyone writes code that others are to use and/or maintain, which means we are library developers! I generally think the guidelines are pretty good, but I noticed this little gem: Error Raising and Handling Guidelines Throw the InvalidOperationException exception if a call to a property set accessor or method is not appropriate given the object's current state. Property Usage Guidelines Allow properties to be set in any order. Properties should be stateless with respect to other properties.
MS actually recognized that CompSci has no absolutes, and you should, too!
Personally, I love the idea that Raymond spends his nights posting bad regexs to mailing lists under the pseudonym of Jane Smith. He'd be like a super hero, only more nerdy and less useful. [Trevel]
| FoldWithUs! | sighist | µLaunch - program launcher for server core and hyper-v server -
I believe all .net programmers should have read MS' guidelines for class library developers. Everyone writes code that others are to use and/or maintain, which means we are library developers! I generally think the guidelines are pretty good, but I noticed this little gem: Error Raising and Handling Guidelines Throw the InvalidOperationException exception if a call to a property set accessor or method is not appropriate given the object's current state. Property Usage Guidelines Allow properties to be set in any order. Properties should be stateless with respect to other properties.
MS wrote:
Property Usage Guidelines Allow properties to be set in any order. Properties should be stateless with respect to other properties.
Well you know what rfc2119 says about "should", right? The way I see it, they just mean that if for some reason you disregarded that bit of advice, you [should?/must? it doesn't say] throw InvalidOperationException instead of something random or corrupting the state
-
MS wrote:
Property Usage Guidelines Allow properties to be set in any order. Properties should be stateless with respect to other properties.
Well you know what rfc2119 says about "should", right? The way I see it, they just mean that if for some reason you disregarded that bit of advice, you [should?/must? it doesn't say] throw InvalidOperationException instead of something random or corrupting the state
Right. "If you want to throw something in that situation, and don't know what, we recommend InvalidOperationException."
-
I believe all .net programmers should have read MS' guidelines for class library developers. Everyone writes code that others are to use and/or maintain, which means we are library developers! I generally think the guidelines are pretty good, but I noticed this little gem: Error Raising and Handling Guidelines Throw the InvalidOperationException exception if a call to a property set accessor or method is not appropriate given the object's current state. Property Usage Guidelines Allow properties to be set in any order. Properties should be stateless with respect to other properties.
What's so strange about that? You might have to initialize the object with a method call prior to accessing the properties. Suppose the object is just a proxy for a remote object - then you'd have to connect the proxy with the remote object somehow before you start accessing the properties (assuming the properties reflect the state of the remote object).
-
What's so strange about that? You might have to initialize the object with a method call prior to accessing the properties. Suppose the object is just a proxy for a remote object - then you'd have to connect the proxy with the remote object somehow before you start accessing the properties (assuming the properties reflect the state of the remote object).
It was perhaps not strange, but the two guidelines seemed internally inconsistent. For a proxy, I think the "initializing method call" would usually be the constructor, or a factory method.
-
MS wrote:
Property Usage Guidelines Allow properties to be set in any order. Properties should be stateless with respect to other properties.
Well you know what rfc2119 says about "should", right? The way I see it, they just mean that if for some reason you disregarded that bit of advice, you [should?/must? it doesn't say] throw InvalidOperationException instead of something random or corrupting the state
:D And programs should be bug free, maintainable, extensible and reusable. As well as developed in thirty seconds by clicking around in a GUI.
-
I believe all .net programmers should have read MS' guidelines for class library developers. Everyone writes code that others are to use and/or maintain, which means we are library developers! I generally think the guidelines are pretty good, but I noticed this little gem: Error Raising and Handling Guidelines Throw the InvalidOperationException exception if a call to a property set accessor or method is not appropriate given the object's current state. Property Usage Guidelines Allow properties to be set in any order. Properties should be stateless with respect to other properties.
I don't see anything funny there. One is talking about object state and other property state with respect to other properties.