I am reading book "C# 4.0 in a nutshell" by Joseph Albabari and Ben Albabari. From there I find a topic restrictions on access modifiers. Page 91, Topic "Restrictions on Access Modifiers".
Quoting from the book.
The compiler prevents any inconsistent use of access modifiers. For
example, a sub- class itself can be less accessible than a base class,
but not more
So this says that base class should be equally or more accessible than subclass. So if base class is internal then subclass should be either private or internal. If base class is private and sub class is public then compile time error will be generated. While trying this in Visual Studio I found some strange behavior.
Try 1: Base is private and sub class is private (Works, right behavior) This also works if both are internal, public.
private class A { }
private class B : A { } // Works
Try 2: Base is private and sub class is public or internal (This fails, right behavior)
private class A { }
public class B : A { } // Error
Try 3 : Base is internal and sub is public (This works, but it should fail. As Base is less accessible than sub class
internal class A { }
public class B : A { } // Works, but why
Now my question is why Try 3 didn't failed? Sub class is public and is more accessible than base class which is internal. Even the book says this should fail. But Visual Studio compiled this successfully. This should work or not?
Edit:
I created a new Console Project in VS. In Program.cs I added my code. Here is complete code of Program.cs file.
using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;
using System.IO;
namespace ConsoleApplication
{
class Program
{
internal class A { }
public class B : A { } // Error
static void Main()
{
}
}
}
You are placing your nested classes within another internal class.
For example, given:
class Program
{
static void Main(string[] args)
{
}
internal class A { }
public class B : A { }
}
It will compile because the internal modifier of the wrapping class makes the public modifier on class B moot. Rather, type B's accessibility is limited by its wrapped class Program -- its accessibility domain is internal as well.
If you update it to be:
class Program
{
static void Main(string[] args)
{
}
}
internal class A { }
public class B : A { }
It will throw the inconsistent visibility compiler error. Or if you redefine Program to be public instead of internal it will also throw the error. In this case, B's accessibility domain is now public and no longer limited by Program's internal accessibility domain.
From the C# specification 3.5.2 Accessibility Domains:
The accessibility domain of a nested member M declared in a type T
within a program P is defined as follows (noting that M itself may
possibly be a type):
If the declared accessibility of M is public, the accessibility domain of M is the accessibility domain of T.
And the MSDN's description of Accessibility Domain:
If the member is nested within another type, its accessibility domain
is determined by both the accessibility level of the member and the
accessibility domain of the immediately containing type.
If the wrapping type Program is internal, then the nested type B being public will have its accessibility to match Program, thus it is treated as internal and no compiler error is thrown.
private inherited classes can not accessible in other classes when you inherit private class with other public class then it contains the reference of private class and its data so it is not possible.
abstract class test
{
public abstract void add();
public int num1;
public string str;
}
class test3 : test1
{
public override void add()
{
throw new NotImplementedException();
}
}
both classes are private.
if you use internal then you can access only in assembly.
Related
First of all let me start by saying that I do understand access specifiers I just don't see the point of using them in classes. It makes sense on methods to limit their scope but on classes, why would you want a private class, isn't it the purpose of classes to be able to reuse them?
What is the purpose of access specifiers when declaring a class in C#? When would you use them?
Thanks
Well, let's say that you want a class to be only accessed inside her own assembly:
internal class Test
Let's say that you have two classes, one inside the other (nested classes):
protected internal class TestA
{
private TestB _testB;
private class TestB
{
}
public TestA()
{
_testB = new TestB();
}
}
The TestB class can be only accessed inside methods/properties/contructors inside TestA or inside herself.
The same applies to the protected modifier.
// Note
If you don't specify the access modifier, by default it will be private, so on my example the following line:
private TestB _testB;
is equal to
TestB _testB;
And the same applies to the class.
Special Modifier
Then, there is the protected internal which joins both modifiers so you can only access that class inside the same assembly OR from a class which is derived by this one even if it isn't in the same assembly. Example:
Assembly 1:
public class TestA : TestB
{
public TestB GetBase()
{
return (TestB)this;
}
public int GetA1()
{
return this.a1;
}
}
protected internal class TestB
{
public int a1 = 0;
}
Program
TestA _testA = new TestA(); // OK
TestB _testB = new TestB(); // ERROR
int debugA = new TestA().a1 // ERROR
int debugB = new TestA().GetA1(); // OK
TestB testB_ = new TestA().GetBase(); // ERROR
Source
Link (Access Modifiers)
Internal
The type or member can be accessed by any code in the same assembly,
but not from another assembly.
Private
The type or member can be accessed only by code in the same class or
struct.
Protected
The type or member can be accessed only by code in the same class or
struct, or in a class that is derived from that class.
Public
The type or member can be accessed by any other code in the same
assembly or another assembly that references it.
I will give you an example of an internal class. Imagine I have some DLL. Form this DLL I want to expose only a single class called A. This class A however, should have access to other classes inside DLL - thus I will make all other classes inside DLL internal. Hence, from the DLL you can only use class A, while A can still access other classes inside DLL - you however, can't.
The greatest benefit of using access specifiers is when someone else is using your classes. By clearly specifying, what should and what should not be touched within your objects, you can protect your object internal mechanism and integrity from being misused or damaged.
With bigger classes, if you made everything public, you would also make it harder for the user of your code to work with IntelliSense, which is something that is very handy when you deal with unknown libraries.
I have created one application to understand Access Specifiers.
It will be more easy to understand it with code instead of Theory.
I have added my notes in code, for better guidance.
namespace ConsoleApplication1
{
//A normal public class which contains all different types of access-modifier classes in the assembly named 'ConsoleApplication1'
public class Base
{
public class PublicBase
{
public static void fn_PublicBase()
{
Console.WriteLine("fn_PublicBase");
}
}
private class PrivateBase
{
public static void fn_PrivateBase()
{
Console.WriteLine("fn_PrivateBase");
}
}
protected class ProtectedBase
{
public static void fn_ProtectedBase()
{
Console.WriteLine("fn_ProtectedBase");
}
}
internal class InternalBase
{
public static void fn_InternalBase()
{
Console.WriteLine("fn_InternalBase");
}
}
protected internal class ProInternalBase
{
public static void fn_ProInternalBase()
{
Console.WriteLine("fn_ProInternalBase");
}
}
//TIP 1:This class is inside the same class 'Base' so everything is accessible from above.Hurray!!
class Base_Inside
{
public static void fn_Base_Inside()
{
//All methods are easily accessible.Does not consider a modified indeed.
PublicBase.fn_PublicBase();
PrivateBase.fn_PrivateBase();
ProtectedBase.fn_ProtectedBase();
InternalBase.fn_InternalBase();
ProInternalBase.fn_ProInternalBase();
}
}
}
//Different class but inside the same assembly named 'ConsoleApplication1'
public class Base_Sibling : Base
{
//TIP 2:This class is NOT in same class 'Base' but in the same assembly so only protected is NOT accessible rest all are accessible.
public void fn_Base_Sibling()
{
PublicBase.fn_PublicBase();
//PrivateBase.fn_PrivateBase(); //ERROR:Accesibility of 'protected'
ProtectedBase.fn_ProtectedBase(); //protected is accessible because Base_Sibling inherit class 'Base'. you can not access it via Base.ProtectedBase
InternalBase.fn_InternalBase();
ProInternalBase.fn_ProInternalBase();
}
}
}
Now to Understand difference between internal, protected internal,
I Have added one for project named with Assembly_1 in same
solution.
I have inherited Base class of ConsoleApplication1 to Derived class of Assembly_1.
namespace Assembly_1
{
//TIP:if it does not inherit class 'ConsoleApplication1.Base' then we can not access any thing beacuse this is different assembly.
//TIP:only INTERNAL is NOT accessible , rest all are accessible from first assembly if it inherits class 'Soul'
public class Derived : ConsoleApplication1.Base
{
public class PublicDerived
{
public static void fn_PublicDerived()
{
PublicBase.fn_PublicBase(); //YES, becuase this is 'public'
//PrivateBase.fn_PrivateBase(); //No, becuase this is 'private'
ProtectedBase.fn_ProtectedBase(); //YES, becuase this is 'protected'
//InternalBase.fn_InternalBase(); //No, becuase this is 'internal'
ProInternalBase.fn_ProInternalBase(); //YES, becuase this is 'protected internal'
}
}
}
}
- Update answer 2019 -
Hi You can find accessibility via below table
What is the purpose of internal abstract method in a abstract class?
why to make an abstract method internal in a abstract class? if we want to restrict abstract class outside the assembly why don't we just make abstract internal class.
Is there any other logic behind it.
Adding internal member to a public abstract class makes it impossible to inherit that abstract class outside of assembly it was declared in. But the class itself as well as all derived classes can still be used (as the types are public) outside of declaring assembly.
Let's say you have an abstract class:
public abstract AMyClass
{
public string DoSomething()
{
return DoSomethingInternal();
}
internal abstract string DoSomethingInternal();
}
And another public class that inherits it, declared in the same assembly
public sealed MyClass : AMyClass
{
internal override string DoSomethingInternal()
{
return "Hey from MyClass!";
}
}
You could still create an instance of MyClass in different assemblies, but you won't be able to implement your own class that derives from AMyClass, because you won't be able to implement abstract DoSomethingInternal method.
The internal keyword is an access modifier for types and type members.
Internal types or members are accessible only within files in the same
assembly, as in this example
public class BaseClass
{
// Only accessible within the same assembly
internal static int x = 0;
}
Now in your case this is something like:
public abstract BaseClass
{
internal abstract void Print();
}
Now, in this case all the class which are in same assembly of BaseClass, will be able to override the Print method of BaseClass. But outside of the assembly classes will only be able to override public members. like
public abstract BaseClass
{
internal abstract void Print();
public abstract void Hello();
}
Classes outside of the assembly of BaseClass won't be able to use this class as one of member of this class is internal. Solution is create sub class in same assembly of BaseClass and use that class outside the assembly.
I suggest you to read the access modifier concept in c# from C# in depth by #john skeet.
Imagine you have a code in your project
lets say its a console app and we call it as ConsoleApplication1
namespace ConsoleApplication1
{
class Program
{
static void Main(string[] args)
{}
}
public abstract class MyAbsClass
{
public string DoSomething()
{
return DoSomethingInternal();
}
internal abstract string DoSomethingInternal();
public abstract string DoSomethingExternal();
}
public class MyClass:MyAbsClass
{
internal override string DoSomethingInternal(){}
public override string DoSomethingExternal(){}
}
}
and now you have (lets say another consoleApp called ConsoleApplication2) you build your consoleapplication1 and add reference to it
using ConsoleApplication1;
namespace ConsoleApplication2
{
class Program
{
static void Main(string[] args)
{
}
}
class NewClass : MyAbsClass
{
public override string DoSomethingExternal()
{
throw new NotImplementedException();
}
}
}
Now when you build this you get an error Error 1 'ConsoleApplication2.NewClass' does not implement inherited abstract member 'ConsoleApplication1.MyAbsClass.DoSomethingInternal()
Why this error?? because compiler is telling you that when you declare member as internal ,the class which is in the same assembly ie (ConsoleApplication1) can have access it.So no matter how many class you create in ConsoleApplication2 you wont be able to access it because it is declared internal.
In C++, in order to define a symbol that is only accessible within the same file, we say
namespace
{
class my_private_class
{ ... }
}
But can I do the same thing in C#? Or do I have to say
namespace __DO_NOT_USE_OUT_OF_.xxx.cs__
{
public MyPrivateClass
{ ... }
}
using __DO_NOT_USE_OUT_OF_.xxx.cs__;
(assuming this is in a file called xxx.cs)?
The later, of cause, will depend on the other programmer regards it or not.
There's no anonymous namespaces in C#, but you can exploit static classes:
namespace MyNamespace // <- Just a namespace
{
// Anonymous Namespace emulation:
// static class can't have instances and can't be inherited,
// it's abstract and sealed
internal static class InternalClass // or public static class
{
// private class, it's visible within InternalClass only
class my_private_class
{ ... }
}
}
There is no such thing in C#, we have something called access modifiers which manage the visibility of types.
The usage is against a class or method, such as:
internal class MyType
{
}
Or
protected void MyMethod()
{
}
You will have to pick the one that applies to your scenario, here are the details:
public
The type or member can be accessed by any other code in the same assembly or another assembly that references it.
private
The type or member can be accessed only by code in the same class or struct.
protected
The type or member can be accessed only by code in the same class or struct, or in a class that is derived from that class.
internal
The type or member can be accessed by any code in the same assembly, but not from another assembly.
protected internal
The type or member can be accessed by any code in the assembly in which it is declared, or from within a derived class in another assembly. Access from another assembly must take place within a class declaration that derives from the class in which the protected internal element is declared, and it must take place through an instance of the derived class type.
This question already has answers here:
What's the difference between a public constructor in an internal class and an internal constructor?
(5 answers)
Closed 9 years ago.
I've seen some C# code that declares a class with an internal modifier, with a public constructor:
internal class SomeClass
{
public SomeClass()
{
}
}
What is the point of having a public constructor, if the visibility of the entire class is internal, thus it can be seen only inside the defining assembly?
Also, does this make any sense in case SomeClass is a nested class?
The internal class scope overrides the public MyClass() constructor scope, making the constructor internal.
Using public on the constructor makes it easier to update the class to public later, but confuses intent. I don't do it.
Edit 3: I missed part of your question. It is still fine to do that if your class is nested. The nesting can't make any difference, even if it is nested in a private class in a public class in a ... (see C# language specification - 3.5.2 Accessibility domains).
EDIT: And, if i recall, if the ctor is internal, it can't be used as a generic type where there is a constraint requiring where T : new(), this would require a public constructor (ref. C# language specification (version 4.0) - 4.4.3 Bound and unbound types).
Edit 2: Code sample demonstrating the above
class Program
{
internal class InternalClass {
internal InternalClass() { }
}
internal class InternalClassPublicCtor {
public InternalClassPublicCtor() { }
}
internal class GenericClass<T>
where T : new() {}
static void Main(string[] args) {
GenericClass<InternalClass> doesNotCompile = new GenericClass<InternalClass>();
GenericClass<InternalClassPublicCtor> doesCompile = new GenericClass<InternalClassPublicCtor>();
}
}
From MSDN - Access Modifiers (C# Programming Guide):
Normally, the accessibility of a member is not greater than the accessibility of the type that contains it. However, a public member of an internal class might be accessible from outside the assembly if the member implements interface methods or overrides virtual methods that are defined in a public base class.
So if, for example, you have an internal implementation of a public interface, you can still expose certain members as public.
Additionally, suppose you suddenly want your internal class to be public. It's a lot easier simply to change the access modifier on the class than all of the members.
I was looking through some C# code for extending language support in VS2010 (Ook example). I saw some classes called internal sealed class
What do these do? Would one use them?
It is a class that:
internal: Can only be accessed from within the assembly it is defined (or friend assemblies).
sealed: Cannot be inherited.
Marking classes as internal is a way of preventing outside users of an assembly from using them. It's really a form of design encapsulation and IMHO it is good practice to mark types that are not part of the intended public API\object models as internal. In the long term this prevents users of your library from coupling themselves to types which you did not intend them to. This sort of unintended coupling harms your ability to change and evolve the way your libraries are implemented as you cannot change them without breaking your clients. Using internal helps to keep the public and usable surface area of a library down to what is intended.
Marking classes as sealed prevents these classes from being inherited. This is a pretty drastic design intent which is sometimes useful if a class is already so specialized that it is sensible that no other functionality should be added to it via inheritance either directly or via overriding its behaviour.
internal and sealed modify types in quite different ways, but they can be used together.
NB You have some further scoping control of internal as you can define a set of other assemblies as 'friends'. These friend assemblies may access your internal types. This can be useful for defining sets of co-operating assemblies such as production and test assemblies. It is often desirable that a test assembly can see all the types in the assembly it is testing.
internal: A class which can only be accessed inside the same assembly.
Assembly1.dll:
namespace test {
internal class InternalClass {
}
public class PublicClass {
}
}
Assembly2.dll:
using test;
...
InternalClass c1; // Error
PublicClass c2; // OK
sealed: A class which cannot be derived from
sealed class SealedClass { ... }
class ChildClass : SealedClass {} //ERROR
Internal means the member is accessible to other types that are defined in the same assembly. A Sealed class is sort of the oppositie of abstract. It can be instantiated but cannot serve as a base class. The primary reason to seal a class is to prevent your users from fiddling around with it and breaking it. It’s also the case that sealing a class permits certain compiler optimizations that are not possible with non-sealed classes.
An internal sealed class is one that is:
internal - Only accessible from within the same assembly
sealed - Cannot be subclassed
In other words, there's no way for you to use it directly.
Internal means it can be used only in same assembly,
The internal keyword is an access
modifier for types and type members.
Internal types or members are
accessible only within files in the
same assembly
sealed that can't be inherited
A sealed class cannot be inherited. It
is an error to use a sealed class as a
base class. Use the sealed modifier in
a class declaration to prevent
inheritance of the class.
INTERNAL
Internal types or members are accessible only within files in the same assembly.
Example
// Assembly1.cs
// Compile with: /target:library
internal class BaseClass
{
public static int intM = 0;
}
// Assembly1_a.cs
// Compile with: /reference:Assembly1.dll
class TestAccess
{
static void Main()
{
var myBase = new BaseClass(); // compile error
}
}
SEALED
First of all, let's start with a definition; sealed is a modifier which if applied to a class make it non-inheritable and if applied to virtual methods or properties makes them non-ovveridable.
public sealed class A { ... }
public class B
{
...
public sealed string Property { get; set; }
public sealed void Method() { ... }
}
An example of its usage is specialized class/method or property in which potential alterations can make them stop working as expected (for example, the Pens class of the System.Drawing namespace).
...
namespace System.Drawing
{
//
// Summary:
// Pens for all the standard colors. This class cannot be inherited.
public sealed class Pens
{
public static Pen Transparent { get; }
public static Pen Orchid { get; }
public static Pen OrangeRed { get; }
...
}
}
Because a sealed class cannot be inherited, it cannot be used as base class and by consequence, an abstract class cannot use the sealed modifier. It's also important to mention that structs are implicitly sealed.
Example
public class BaseClass {
public virtual string ShowMessage()
{
return "Hello world";
}
public virtual int MathematicalOperation(int x, int y)
{
return x + y;
}
}
public class DerivedClass : BaseClass {
public override int MathematicalOperation(int x, int y)
{
// since BaseClass has a method marked as virtual, DerivedClass can override it's behavior
return x - y;
}
public override sealed string ShowMessage()
{
// since BaseClass has a method marked as virtual, DerivedClass can override it's behavior but because it's sealed prevent classes that derive from it to override the method
return "Hello world sealed";
}
}
public class DerivedDerivedClass : DerivedClass
{
public override int MathematicalOperation(int x, int y)
{
// since BaseClass has a method marked as virtual, DerivedClass can override it's behavior
return x * y;
}
public override string ShowMessage() { ... } // compile error
}
public sealed class SealedClass: BaseClass {
public override int MathematicalOperation(int x, int y)
{
// since BaseClass has a method marked as virtual, DerivedClass can override it's behavior
return x * y;
}
public override string ShowMessage()
{
// since BaseClass has a method marked as virtual, DerivedClass can override it's behavior but because it's sealed prevent classes that derive from it to override the method
return "Hello world";
}
}
public class DerivedSealedClass : SealedClass
{
// compile error
}
Microsoft documentation
Sealed: https://learn.microsoft.com/en-us/dotnet/csharp/language-reference/keywords/sealed
Internal: https://learn.microsoft.com/en-us/dotnet/csharp/language-reference/keywords/internal