I have a class created in some namespace, like SomeNameSpace.SubNameSpace.StaticClassName
Here is a code snippet from other code file where I want to use this class many more times, so I created a property in the code file like this
//Just to provide an Alias for long name "SomeNameSpace.SubNameSpace.StaticClassName.PropertyName"
public StaticClassName ServerProxyAlias
{
get
{
return SomeNameSpace.SubNameSpace.Instance.PropertyName;
}
set
{
SomeNameSpace.SubNameSpace.Instance.PropertyName = value;
}
}
Is there any problem in doing like this ?
3
I think it’s about consistency as much as readability. Other developers may miss the fact that you implemented a “proxy property” and still refer to SomeNameSpace.SubNameSpace.Instance.PropertyName directly.
Then you end up with code where sometimes ServerProxyAlias is used and sometimes isn’t – even in the same method – and it’s not obvious they’re the same thing, lest one actually looks up how ServerProxyAlias is implemented.
I’m not saying it’s a major problem, but you ask about any problems with your approach. Well, that’s one that comes to my mind.
Referring the question in the title, it costs you as much as invoking a method does. Java’s equivalent of properties for example would be getters and setters.
So you are creating a class for the sole purpose of being able to use a shorter name? Don’t you have enough classes in your system already? Good software developers work hard to make their system easier to understand. You seem to be working hard to make it more convoluted and difficult to understand.
There’s no problem with this code whatsoever.
As long as the actual PropertyName doesn’t invoke a long running process then it should be OK.
However, you should really access the property directly. I don’t see what the problem is with using the full name.
1
As mentioned, it will not make difference. Because once code is compiled into IL it will have almost same hit on performance. Maybe there would be only minor (nano-seconds) difference in compile time.