Software

Working with .NET access modifiers

The access modifiers available in .NET allow you to put encapsulation in action by defining who can use classes, methods, properties, and so forth, as well as keeping out those who don't need them. Here is a rundown of the various access modifiers available with the .NET Framework.

An important aspect of any development platform is security and controlling access to resources. There are many facets to security, beginning with controlling application access to defining how code can be used. You can use access modifiers to define the declared accessibility of code. Here is a rundown of the various access modifiers available with the .NET Framework.

Controlling access

Access modifiers are an integral part of object-oriented programming. They support the concept of encapsulation, which promotes the idea of hiding functionality. Access modifiers allow you to define who does or doesn't have access to certain features.

Access levels

There are five levels of access allowed in .NET. The first access level provides access to everyone with no restrictions. This is called public, so any classes, methods, or properties defined as public are visible to all other code. The classes for ASP.NET pages are public since they need to be accessed to render the page.

The exact opposite of this public access is private, which limits access to its own. Properties or methods defined as private are only accessible by code contained within the same class. Private elements may not be accessed by derived classes or other classes.

There are a few other access levels between the public and private spectrum. The protected access level says that properties and methods defined as protected are visible within its own class and any classes derived from it.

The next level is called a friend in VB.NET and internal in C#. It says properties and methods defined as a friend or internal are accessible to all code by any class within its containing assembly. This level may be combined with the protected access level to define properties and methods that are accessible by all derived classes, as well as any classes within its assembly. This is commonly called "protected or friend/internal" since it supports either approach.

These five access modifiers are supported by certain VB.NET and C# keywords as the following sections outline.

Keywords

Both C# and VB.NET includes optional keywords that correspond to the five access levels. The following list provides an overview of these keywords as used in C#:

  • public: No access restrictions.
  • protected: Access limited to containing/derived classes.
  • internal: Access limited to containing type.
  • protected internal: Access limited to the current project.
  • private: Access limited to containing/derived classes and the current project.

The corresponding VB.NET list follows:

  • Public: No access restrictions.
  • Protected: Access limited to containing/derived classes.
  • Private: Access limited to containing type.
  • Friend: Access limited to the current project.
  • Protected Friend: Access limited to containing/derived classes and the current project.

These access modifiers are placed before its associated type. The following VB.NET provides a rudimentary example of the access levels in use. The overall Namespace does not get an access level (it never does) but the class does. The AssemblyOnly class is defined as a Friend, so all code within the assembly may use it. The Function called Test is Public, so it is available for use by everyone within the assembly since its containing class is defined as Friend.

The testField is set as Private, so it is only accessible within its class. Access to the testField is controlled through properties defined as Public, so it is accessible to all within the assembly since the containing class is defined as Friend. The ChildClassMayExtend method is defined as Protected, so it is accessible in derived classes with these derived classes.

Namespace Example

Friend Class AssemblyOnly

Public Function Test

Return "Test"

End Function

End Class

Public Class EverybodyUse

Private testField As String

Public Sub New

End Sub

Public Property TestProperty() As String

Get

Return testField

End Get

Set(ByVal value As String)

testField = value

End Set

End Property

Protected Overridable Sub ChildClassMayExtend()

' Code here

End Sub

End Class

End Namespace

The equivalent C# code follows:

namespace test {

internal class AssemblyOnly {

public string test() {

return "test";

}

public class EverybodyUse {

public EverybodyUse() { }

private string testField;

public string TestField {

get { return testField; }

set { testField = value; }

}

internal virtual void ChildClassMayExtend(){

} } } }

Default access

A default access level is used if no access modifier is specified in a member declaration. The following list defines the default access modifier for certain C# types:

  • enum: The default and only access modifier supported is public.
  • class: The default access for a class is private. It may be explicitly defined using any of the access modifiers.
  • interface: The default and only access modifier supported is public.
  • struct: The default access is private with public and internal supported as well.

The default access may suffice for a given situation, but you should specify the access modifier you want to use to ensure proper application behavior.

More control

Proper object-oriented development involves encapsulation that hides functionality from those who don't need to see it. The access modifiers available in .NET allow you to put encapsulation in action by defining who can use classes, methods, properties, and so forth, as well as keeping out those who don't need them. The five access levels available in both C# and VB.NET provide enough control to cover every design situation.

Have you embraced object-oriented development with the .NET Framework? Share your thoughts and experiences with the .NET community.

Tony Patton began his professional career as an application developer earning Java, VB, Lotus, and XML certifications to bolster his knowledge.

---------------------------------------------------------------------------------------

Get weekly .NET tips in your inbox TechRepublic's free .NET newsletter, delivered each Wednesday, contains useful tips and coding examples on topics such as Web services, ASP.NET, ADO.NET, and Visual Studio .NET. Automatically subscribe today!

About

Tony Patton has worn many hats over his 15+ years in the IT industry while witnessing many technologies come and go. He currently focuses on .NET and Web Development while trying to grasp the many facets of supporting such technologies in a productio...

6 comments
plabranche66
plabranche66

Hi, I'm fairly new to VB, and had a question about modifiers. If I create buttons and when clicked each button opened a different excel file and each button had their modifier set to friend do they or will they ever get mixed up? I don't think they do, but after reading briefly on modifiers I'm not sure? Should I set them to private? Thanks, Paul

lgao8
lgao8

It is a pretty concise summery

lgao8
lgao8

it is a pretty concise summary.

codebozo
codebozo

The access modifiers meanings should be: public - Access is not restricted. protected - Access is limited to the containing class or types derived from the containing class. internal - Access is limited to the current assembly. protected internal - Access is limited to the current assembly or types derived from the containing class. private - Access is limited to the containing type.

jreddy
jreddy

"The five access levels available in both C# and VB.NET provide enough control to cover every design situation." Ahhh, but I wish there was one more level of access. I would like to create a Friendly List for a method or attribute. For example, let's say I have a factory that creates an object and I want to enforce that only the factory can build the object. It would be nice to mark the constructor as FriendlyWith: Factory...or something to that effect. I also like to follow the rule that my business objects only know about business, thus nothing about storing themselves, etc. It would be nice to only expose attributes of the class with the storage mechanism. Right now I mark the properties as Internal but that does not stop coders from getting at the data and breaking encaupsluation. . In other words, we end up with encapsulation by convention as opposed to explicit encapsulation. We can achieve this to a degree with interfaces; however I think being able to define a limited scope would be easier to work with.

RichA
RichA

You might want to review the summary of access modifiers at the end of the article. Looks like someone mixed a few of them up...

Editor's Picks