December 22, 2008

Back to basics: Access Modifiers

Someone asked me this weekend about modifiers, what they are, how they're used and most specifically, what the differences are. They'd already done a search on Google and the explanations were hard to understand. Given the spirit of my blog and explaining programming terms in simplistic non-jargonated [if that's even a word?] language, I thought I'd post a quick note...

First up, what are the modifiers? Put in simple terms, modifiers are the keywords designated to mark code on a "Need to know" basis. For those of you that read/watch James Bond, you'll be familiar with this concept. For the moment, I will only cover the four most basic modifiers - Private, Public, Friend and Public, there are some others but they will just complicate the explanation unecessarily for the moment.

How does this apply to code design? Well - consider this, you want to write an API for later use by other programs/programmers, but you want to restrict access to different areas of your code to prevent it being tampered with unecessarily. So...let's apply my James Bond analogy to a simple programming model to explain this concept.

Create a new project called MI6 - this project is our assembly. It will be used to contain a political hierarchy restricting access to data and actions to interested parties on a need to know basis.

M controls MI6 and so she (or he if classic Bond is more your thing) has access to all information. Some of this information is for M's eyes only [private], only she has access to that. So lets consider M as the base class in our assembly and that all information marked as eyes only is read and committed to memory before it's shredded.

Enter stage left, Moneypenny, the cute red-head that's had a thing for James from the outset. As M's assistant, she could be considered an extension of M and thus has information to all information not specifically marked as for M's eyes only [private]. That is, anything marked as public, protected or friend.

And where would any of the 00 agents be without the gadgets they need to perform their job. We need our illustrious Q. Q is part of MI6's inner circle, but really doesn't have much control of anything. He needs to know everything the agents will be doing in order to design the most useful gadgets. He doesn't, however, need access to all of the information at M or Moneypenny's disposal. So let's add a Q class to our assembly too:

Namespace MI6

  Public Class M
    
    Private Property1 As String
    Protected Property2 As String
    Friend Property3 As String
    Public Property4 As String

    Private Sub DrinkWhisky()
      'Do stuff the rest of the agency 
      'don't need to know about
    End Sub

    Public Sub ControlTheAgency()
      'Do stuff to control the agency
    End Sub

  End Class

  Public Class MoneyPenny
    Inherits M

    'As you create methods/properties inside 
    'this class, you will see that you can 
    'only directly access the properties 
    'within our class M that are not marked 
    'as private - that is Access2, 3 and 4, 
    'but not 1

    Private Sub DayDreamAboutJames()
      'Waste time while supposedly working
    End Sub

    Public Function ArrangeCoverStory(ByVal Mission As String) As CoverStory
      'Arrange cover story for specified agent
    End Sub

  End Class

  Public Class Q

    'You will notice that from inside this 
    'class you can only access M's properties 
    'marked as friend or public - that is 
    'Property3 and 4, but but not 1 or 2.

    Public Function IssueGadget() As Gadget
      'Issue a gadget
    End Function

  End Class

End Namespace

So now we have our compiled our assembly we have a basic code representation of MI6's hierarchical structure - and no I haven't forgotten the 00 agents...

Because 00 agents are out in the world and could be compromised (captured & interrogated), we don't want them to have access to all of the information that the inner circle have access to, that could be disasterous for national security, so we will break these guys out into their own assembly. So create a new project for our agents, this way we can control their access to only the information that they really need access to.

Namespace Agents

  Public Class Bond

    'From inside this class you can only directly access
    'M's properties marked as public - that is Property 4, but
    'not 1, 2 or 3.

    Public Event GotTheGirl()
    Public Event FlirtedWithMoneypenny()
    Public Event KilledTheBadGuy()
    Public Event UsedGadget()
    Public Event CompletedTheMission()

    Public Sub GetTheGirl()

    End Sub

    Public Sub FlirtWithMoneypenny()

    End Sub

    Public Sub BlowThingsUp()

    End Sub

    Public Sub KillTheBadGuy()

    End Sub

    Public Sub UseGadget()

    End Sub

    Public Sub DestroyTheCar()

    End Sub

  End Class

End Namespace

As you will notice, James has a bunch of methods and events pertinent to him doing his every day job. When I reference M [by creating a new instance of my M class], I only have access to M's public properties and methods, what goes on behind closed doors remains behind closed doors.

There is one slightly more contrived example, and that is of the Protected Friend. The protected friend a combination of the protected and friend modifiers as you might expect. A property that is marked as protected friend can be accessed inside any class derived from this class or any other class within our assembly.

So that's what modifiers are for and how they can be used to protect the flow of your code.

2 comments:

  1. real nice way of explaining things... "out of box" way of writing... get a clear picture of things .... enjoy reading it ...

    ReplyDelete
  2. Thanks, glad you enjoyed reading it.

    ReplyDelete