Clever Geek Handbook

Why does System.Console expose the SetIn method?

This is a bit of something that struck me when I wrote the adapter for the class System.Console

. Why properties In

, Out

and are Error

coupled with methods SetIn

, SetOut

and SetError

? Why not use the setter property instead? Is this an architectural decision or is there a limitation that hinders the .NET Framework developer?

+3


source to share


1 answer


I can't speak for the original author, but there are at least five good reasons to use a setter in conjunction with a getter (and possibly a protected installer):

  • When setting the value, you need additional parameters (to or from).
  • You need a few overloads of the installer. It is possible that a certain specific property is usually given by both a string and a certain type.
  • You need different attributes or permissions to set and get.
  • You have different functions to update the property and set the value. For example, consider a client side proxy that needs to update a value from the server data in addition to allowing the user to set a value that needs to be propagated to the server.
  • Maybe you want to separate your interfaces into covariance so that you need your getter and setter on different interfaces.


Having said all this, I considered in dotPeek code for these methods ( SetIn

and get_In

). I can’t find an excuse for not using a setter. The getter In

has the same permission attributes as the method SetIn

.

+1


source






More articles:


All Articles