Is there any difference betwen public interface declaration and interface? (I thought that interfaces are public by default).
I am asking because VS2012 is whining about access levels.
I have declared:
interface Ixyz
{nothing important here}
and property (in another class who is using Ixhz as its type):
public Ixhz Somename
{nothing important here}
And when I try to compile the project, it whines about access levels but when I declare interface like public interface Ixyz it stops doing it. Are there any consequences of adding public to interface?
Members in interfaces are always public, and in fact cannot have access modifiers.
Interfaces themselves have the same default access level as other types.
Specifically, top-level types are internal by default, and nested types are private by default.
Related
I want to create a class outside a namespace so that its default access modifier is 'PRIVATE'. I am doing like this:
namespace KnowStructs
{
class Clas1 {}
}
class MyClass {}
But still my class 'MyClass' is referred as Internal when I look in Reflector.
Can anyone help me out.
From Accessibility Levels:
Top-level types, which are not nested in other types, can only have internal or public accessibility. The default accessibility for these types is internal.
and:
Access modifiers are not allowed on namespaces. Namespaces have no access restrictions.
and for private:
Private members are accessible only within the body of the class or the struct in which they are declared
That is, the private keyword is explicitly defined in terms of a containing class or struct.
So whatever you're trying to do, I don't understand it. How could a top level private type possibly be useful? No other code would be able to reference it (in any way, even if it had e.g. static factory methods).
If a private class is allowed that is not a nested type then what would that mean? If it is more restrictive than internal then how would you use it or create an instance. Any use case will require it to be internal at a minimum. I would like to see how you intend to use it.
It simply makes no logical sense.
Whereas having a private nested class scopes itself to the parent containing class. If it were internal then you still will be able to make an instance within the assembly.
So for classes having no modifier is internal by default for non nested types and private for nested types as .Net always applies the most restrictive access when no modifier is specified.
You can make the class internal, if you only want to be accessible by classes in your namespace
If I declare an interface, or a type as private in one file, is it private to that file or the namespace?
The compiler generates an error for File2: 'Error 14 Inconsistent accessibility: parameter type 'DIDemo1.IImageRepository' is less accessible than method 'DIDemo1.ImageGetter.ImageGetter(DIDemo1.IImageRepository)'
What I don't understand is that MyClass can use the interface but ImageGetter class cannot.
File1:
namespace DIDemo1 {
interface IImageRepository {
Image[] GetImages();
}
public class MyClass : IImageRepository {
#region IImageRepository Members
public Image[] GetImages() {
return new Image[] { };
}
#endregion
}
}
File2:
namespace DIDemo1 {
public class ImageGetter {
IImageRepository _repo;
public ImageGetter(IImageRepository repository) {
_repo = repository;
}
public Image[] GetImages() {
return _repo.GetImages();
}
}
}
Since you did not specify an access modifier for your interface, it defaults to internal, which is lower than public. That means only code in the same assembly are aware of its existence.
A public class can implement an internal interface, because other code inside that same assembly would see your class with the interface, and code outside would simply see the public class, with no interface.
However, in File2, you are making an internal interface part of that class' public contract - that is, your class is public, which means any code can see it, but in order to use it they must also be able to understand the types in the constructor. Since one of the types required in the constructor is internal, external code cannot understand it, and this contract is impossible to fulfill.
What I don't understand is that MyClass can use the interface but ImageGetter class cannot.
ImageGetter can use the interface, it just can't present it in one of its method signatures which are more accessible. Likewise if MyClass tried to use it in one of its method signatures you'd get the same error. Read below.
Top level interfaces, structs, and classes default to internal access. To fix your problem put public before your interface declaration.
internal types in C# are accessible only within the same assembly.
You can't use a more restrictive access modifier in a less restrictive signature for obvious reasons. (How could someone who can't access the more restrictive type call the function for example?)
No, which file the code is in is irrelevant. The interface is private to the namespace, not the file.
The error message is not because the ImageGetter class can't reach the interface, it's because the class can't be used from outside the namespace.
The difference lies in how you use the interface. The class MyClass only implements the interface, so you can still use the class even if you can't use the interface. The constructor in the ImageGetter class requires a reference to the interface, so you can't use that class without also having access to the interface.
Interfaces and classes default to internal accessibility (because there is no concept of a class being private inside a namespace). The error explains what happens there - IImageRepository is less accessible (it is internal) than ImageGetter constructor, which exposes IImageRepository as a parameter.
Basically a public method on ImageGetter exposes a type that is internal. This is not allowed in C#.
I came across some interesting C# syntax that I'm not familiar with in the source code for the Composite Application Library for WPF's DelegateCommand<T> class.
There are some method declarations which are prefixed with the ICommand interface name, and they do not have accessibility modifiers specified. For example:
bool ICommand.CanExecute(object parameter) { ... }
What is this syntax called and where can I read more about it? I assume there's an implicit public, but I can't figure out what the benefit of specifying the class name is. My guess is that it might just be there for organization.
When you place a method like this, you're saying that this is the explicit implementation of the interface. You can read a good tutorial on MSDN via that link.
Also, a comparison might be helpful for a full view of what this means.
It's termed Explicit Interface Implementation:
If a class implements two interfaces
that contain a member with the same
signature, then implementing that
member on the class will cause both
interfaces to use that member as their
implementation.
If the two interface members do not
perform the same function, however,
this can lead to an incorrect
implementation of one or both of the
interfaces. It is possible to
implement an interface member
explicitly—creating a class member
that is only called through the
interface, and is specific to that
interface. This is accomplished by
naming the class member with the name
of the interface and a period.
Explicit Interface Implementation Tutorial
This is called explicit interface implementation and you can read about it here.
The basic idea is that those methods/properties are only accessable when explicitly used via an interface instance of that type.
It is called explicit implementation of interfaces. What it means is that this particular implementation of CanExecute will not be visible (and will not run) UNLESS the object is cast as an ICommand.
This can be useful in allowing a class to provide different implementations for different interfaces where method names overlap
public interface InterfaceOne {
void SomeMethod();
}
public interface InterfaceTwo {
void SomeMethod();
}
public class Impl : InterfaceOne, InterfaceTwo {
public void InterfaceOne.SomeMethod() {Console.WriteLine("One");}
public void InterfaceTwo.SomeMethod() {Console.WriteLine("Two");}
}
I personally hate this this syntax. Take the example of OracleParameter which provides only an explicit implementation of ICloneable.
If you have a reference to OracleParameter, the Clone() method will not appear in intellisense and will not be visible when you "Go To Definition". However the ability IS there if you do ((ICloneable)parameter).Clone(). In order to even know that this is possible, you can do that you are pretty much stuck googling around in blogs.
This is called explicit interface implementation and you can read more about it here.
In Visual Studio, if you inherit from an interface, you can right-click on the interface name in your class definition. You can click either "Implement Interface", or in the submenu, "Implement Interface Explicitly". This is a handy shortcut for implementing interfaces.
I have an interface, IFindable that is implemented by a few classes. One other World class holds a List<IFindable> items;
I have set up a getItems method in my World class, to return the list of IFindables. Now, I am trying to access that list from my Default.aspx.cs class (this is a web project). Unfortunately, I don't seem to be able to since this class doesn't understand what IFindable is. I get the following error:
Inconsistent accessibility: return type
'System.Collections.Generic.List<IFindable>' is less accessible than
method 'World.getItems()'
Why is this? Have I gone about this wrong?
It sounds like your IFindable interface isn't public, change it to this
public interface IFindable ...
If your current declaration looks like this
interface IFindable ...
Then the compiler is using the default accessibility which is internal
Interfaces, like classes, can be declared as public or internal types. Unlike classes, interfaces default to internal access. Interface members are always public, and no access modifiers can be applied. http://msdn.microsoft.com/en-us/library/ms173121%28VS.80%29.aspx
Have you defined your interface as public ?
public interface IFindable
{
...
}
Others have suggested making your interface public. An alternative is to make your getItems() method internal:
internal List<IFindable> getItems()
{
...
}
(While you're at it, I suggest you either make it GetItems() or a property called Items, in order to follow .NET conventions. getItems() is very Java-like.)
You might also need to put a using statement to the correct namespace at the top of your class file
Suppose that we have a class named class1.
The class1 has several properties and methods and we have decided to specify the access specifier of class1 as internal.
Now, can we set the access specifier of class1 methods as public?
For your specific question, Class 1 which is declared as internal can have a public method.
Why?
Look at Jon Skeets explanation:
You can certainly mark a class as
internal, but that's different from
making its public members internal.
For instance, suppose you have a class
which implements a public interface.
Even though the class may be internal,
an instance may still "get out of the
assembly" by being returned from a
member in another (public) class. That
instance would have to be referenced
by the interface it implements rather
than the class name itself (as the
class isn't known to the outside
assembly) but the public methods can
still be called.
If the public methods aren't
implementing any interfaces, I suspect
it would only make a difference in a
very few reflection cases which you
may not care about.
community wiki - as credit should go to Jon Skeet
Yes, you can set public on members of internal/private/etc types.
As other replies have noted, external code won't be able to see the properties unless it can see the type - but there are lots of nuances:
if the member is on an interface it will be (essentially) part of the public API
the member might be a public override of a virtual/abstract member - in which case it will truly be publicly visible, but via the base-class (again, similar to interfaces)
But there is a lot of other code in the framework that uses reflection and demands public accessibility:
data binding usually works on the public properties
security checks for partial-trust can be fussy about public members
serialization (for example XmlSerializer) may want public members
etc
So there are still lots of reasons to think about public rather than just internal, even if your code is only referenced by the local assembly.
By rule access specifiers on methods and properties can not be more more accessible than that of the class containing it.
But I've tried this:
internal class Test
{
public string Testing{get;set;}
}
and it compiles without any exception! I think it is okay as the class Test will not be accessible outside the namespace assembly we have declared so public property will not make any difference.
This does not works:
private class Test
{
public string Testing{get;set;}
internal string TestingAgain{get;set;}
}