Skip to content

Scope It Out: Choosing the Right Scope for Methods, Properties, Controls and More

 Methods, properties, controls, any member that you add to project items can have its own scope. What is the scope? The scope essentially describes the code-wise accessibility of the member.

For example, when you add a control to a Window/WebPage/iOSView, its scope is set to Private€ by default. You can change the scope to Public€ if you want. A control with a Private scope means that the control is only accessible to the code within its container. So the control can only be referenced in code that is on the Window/WebPage/iOSView. If you were to have the scope set to public, then the control would be accessible to any code that can access the Window/WebPage/iOSView itself.

For example, say you have a Window (Window1) with a button on it called OKButton with its scope set to private. In the Open event of the Window, you could have code like this:

OKButton.Caption = "€œOK"€

Now say you have another window (Window2) that needs to display Window1, but you want it to change the caption of OKButton to “Hello”€. You might write code like this:

Dim w As New Window1
w.OKButton.Caption = "€œHello"€

Unfortunately, that code will not compile. Because OKButton is private, it cannot be accessed outside of Window1 itself. If you need to be able to change the caption, you could of course change the scope of OKButton to Public and then the above code would work.

But that may not be the best approach. For one thing, you now have a specific dependency between Window1 and Window2. If you were to rename OKButton to StandardButton, then the code in Window2 would also need to be updated. Some might consider it bad practice for Window2 to know such intimate details of Window1.

An alternative might be to create a public ChangeButton method on Window1 that changes the button caption. Such a method could look like this:

Public Sub ChangeButton
  OKButtion.Caption = "Hello"
End Sub

Of course for a simple example like this you probably think a dedicated method is overkill. And it probably is. But real-world apps often have to change many things and consolidating things into a single method you can control might be a better solution than making everything public so that it can be accessed by any code in your app.

Methods and properties are another place where setting scope to private often makes sense. In fact, those items can have three scope values: Private, Protected and Public. Private and Public work as described above. Protected is not as commonly used. It means that the property/method can be accessed by its container or any subclasses of the container.

For your own projects, you’ll have to decide what makes the most sense. But it is generally a good idea to use the most restrictive scope possible so that you do not not inadvertently create dependent, brittle code that gets harder to update as your project gets larger.

Want to learn more? Consider joining me at XDC in October!