Develop Reference

Is it possible to a variable/class be accessible to only other specific class? [duplicate]

This question already has answers here:
How to restrict class members to only one other class
(6 answers)
Closed 1 year ago.
Is it possible to have a class that is available just to other specific class, and inaccessible to the "rest" of the code?
Thank you.

For one class, you make nest one class inside another. If you need to later expand this, you can do it by breaking the Solution up among different Projects (dlls), marking a class internal, and using the [InternalVisibleTo] attribute.

Best practices for restricting access to enum parameter in C# [closed]

Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 9 years ago.
Improve this question
Consider for the question this String.Split overload, which takes a StringSplitOptions enum as a parameter.
Isn't it bad that the enum itself is public and accessible to everything that includes the System namespace? I mean, the enum is completely specific to options of the Split method, yet it's available outside of it's scope.
Perhaps there is a better way to model this, like putting the enum inside the String class itself, and accessing it by using String.SplitOptions for instance? I very rarely see this (I actually can't remember any such case now), so I assume it is not preferred for some reason. In general, I think reducing the scope of things is a best practice because you lower the chance of problems occurring by using a class/member in an incorrect scope, so to speak.
I'm using Split as an example here, but it is quite common for a Enum to be used only by a method or class in our code base too. I generally create the enum as a public type in a separate cs file like any other class, but I would love to hear other approaches to this 'problem'.
Update:
I just found this article that attacks this exact problem, with a Folder class and a Filter enum but again seems go against what I believe would be more correct in that case (placing the enum inside the class somehow). One of the comments in there from ToddM (which I happen to agree with) states:
...
But, even then, I feel your logic is wrong. Your main complaint
against embedding the enum inside of the class is that it will take
too long to type. Given how verbose C# tends to be, this is not really
a sensible argument. In VS, CTRL+SPACE is your friend.
Logically, I feel placing the enum inside of the class is far more
correct. Take your example: what is a MyNameSpace.Filter? Where does
it apply? I guess it's a filter for your namespace? It's impossible to
tell, especially if your namespace grows to contain dozens of classes.
Now consider MyNameSpace.Folder.Filter -- it is, in my mind, far more
intuitive that Filter applies in some way, shape, or form to the
Folder class. Indeed, another class can be added to the namespace with
its own concept of filter, one of whose members may be 'File'. Just
because you've introduced a new class into the namespace doesn't give
you the right to pollute that namespace with various 'helper' types.
If you are developing as part of a large development team, your style
is, well, rude.
...

It's an interesting idea to nest the enum in order to suggest that it has a reduced scope, or to give it better semantics. I have used this idea before in order to have both error codes and warning codes in a post-compiler I developed. This way, I could use the same enum name Code nested either in the Error class or the Warning class.
On the other hand, public nested types are generally discouraged. They can be confusing to clients who have to qualify them with the outer class name. Look at the related guidelines on MSDN. Some that are relevant:
DO NOT use public nested types as a logical grouping construct; use namespaces for this.
AVOID publicly exposed nested types. The only exception to this is if variables of the nested type need to be declared only in rare scenarios such as subclassing or other advanced customization scenarios.
DO NOT use nested types if the type is likely to be referenced outside of the containing type.
For example, an enum passed to a method defined on a class should not be defined as a nested type in the class.
I believe those guidelines were followed when developing the StringSplitOptions enum, and most of the others in the BCL.

String.Split() is public, so StringSplitOptions has to be public too. Both String and StringSplitOptions exist in the System namespace. Both have public scope. Neither is "available outside of [the other's] scope".

I think one of the reasons is that it would make every call using an embedded enum wider (the name of the class becomes a mandatory prefix).
I personally wouln't appreciate having to use ResultSetTransformer.ResultSetTransformerOptions every time I have to use this enum, it would make my line horribly long.
But as others pointed out, I don't think it's standard in the framework to embed enums in classes at all, possibly for this reason.

Usage of namespaces in C# [duplicate]

This question already has answers here:
Using Statements vs Namespace path? C#
(6 answers)
Closed 9 years ago.
What is the difference between defining a namespace by using keyword and simply giving the path to access the file wherever it is used ?? Does it cause any change in the internal working of the program, because the results seem to be the same

It doesn't have any impact other than code readability and resolving type ambiguity.
Say you have 2 namespaces SampleNamespace1 and SampleNamespace2 that both have MyClass class. In order for you to specifically identify which MyClass to use is to correctly use the namespace.

As long as you actually access the same namespace, there is no difference in the result. From the compiled code it's impossible to tell which way the namespace was specified.
Note that the namespace has nothing to do with the path of the file. They may be the same, but it's only the namespace statements that specify the namespace. To make it the same as the folder where the file lies, is only to make it easier to find the right file.

Yes, the result is the same, because there's no difference.
Using is for clarify which class do You want to use, if there exists two class with the same name in more namespaces.
If You want to use both, with using, You can also create aliases for namespaces too to shorten Your code.

No difference. except it make your code organizer because you don't write the full path every time.
one of it's advantages is when you have 2 or more classes with the same name but in different namespaces in that case you 'll need to write the full path for readability.

Is using System.* Namespaces on your own classes considered Bad Practice? [duplicate]

This question already has answers here:
Placing custom code in a System namespace
(3 answers)
Closed 8 years ago.
I have a class called ConfigurationElementCollection<T>
It's a generic implementation of System.Configuration.ConfigurationElementCollection
It's stored in our solutions', Project.Utility.dll but I've defined it as being part of the System.Configuration namespace
namespace System.Configuration
{
[ConfigurationCollection(typeof(ConfigurationElement))]
public class ConfigurationElementCollection<T> :
ConfigurationElementCollection where T : ConfigurationElement, new()
{
...
}
}
Is putting classes in the System.* namespaces considered bad practice when they aren't part of the System.* Base Class Libraries ?
On the face of it, it seems to make sense, as it keeps similar classes with similar functionality in the same place. However it could cause confusion for someone who didn't realise it was actually part of a non .net BCL as they wouldn't know where to go hunting for the reference.

While your class is similar it is still not part of the BCL. I would not put it in System.* because of this. It will cause confusion especially when one goes to use it and they have System.* referenced and then get a nasty can't find message when they go to use your class.... :-)

I'd recommend either replacing System by your company/project name or prefixing the namespace with your company/project name.
That way you make it clear that it's not part of the BCL, but exactly how it's related to them.
Also in the (admittedly unlikely) event Microsoft ever implement these classes/methods with exactly the same names you won't get a clash.

Attributes in .net [duplicate]

This question already has answers here:
Closed 12 years ago.
Possible Duplicate:
When should I use attribute in C#?
Hi, I am trying to understand how Attributes in .net works.
As we all know Attributes are of two types metadata and context attributes.
Metadata attributes: it allows some data to be attached to a class or method. This data becomes part of the metadata for the class, and can be accessed via reflection.
Firstly, why do we need custom attributes please give examples and How is that information attached with that class and how will it be interpreted.
Custom attributes: Please explain this and explain the flow how is that custom class which is derived System.Attribute is executed and how will that information be useful to the current class or method which uses that attribute. (best example is Validation Block is applied as attributes to the property or methods and it will be automatically validated. how is this possible).
I have the basic understanding of attributes and how it works and looking at the process how that works.
Thanks in advance.

I think these tutorials might help you:
http://oreilly.com/catalog/progcsharp/chapter/ch18.html
http://msdn.microsoft.com/en-us/library/aa288454(v=vs.71).aspx
http://www.dotnetjohn.com/articles.aspx?articleid=273