Theory
Who may see the cost price?
Mehta Uncle's one business secret is the cost price: what he paid for the soap he sells at 40. ShopKeeper must store it (profit reports need it), but who should be able to read it?
The till form? Yes: same project, family. A plugin DLL someone installs next year? Absolutely not.
Java gave you 4 access levels keyed on class, package and children. VB.NET also has levels keyed on class, project and children, with 2 renames and 1 genuinely different meaning. The differences are where exams aim.
At a glance
The 5 doors, narrowest first
| Specifier | Who gets in | ShopKeeper use |
|---|---|---|
| Private | Only the declaring class | _price backing field |
| Protected | The class + derived classes ONLY | Helper for a future DiscountedItem child |
| Friend | Anything in the same project (assembly) | CostPrice: the shop's code, nobody else's |
| Protected Friend | Derived classes OR same project (union) | Hooks for children and in-house tools alike |
| Public | Everyone, everywhere | Name, Price, LineTotal |
Practical
Item with its doors labelled
Public Class Item
Private _price As Decimal ' this class only
Friend CostPrice As Decimal ' whole ShopKeeper project
Protected Sub MarkRepriced() ' me + my derived classes
' audit note for children like DiscountedItem
End Sub
Public Property Price As Decimal
Get
Return _price
End Get
Set(value As Decimal)
If value >= 0 Then _price = value
End Set
End Property
End Class
' Same project, in the till form: itm.CostPrice = 32D ' legal (Friend)
' A derived class calling MarkRepriced() ' legal (Protected)
' An external DLL reading itm.CostPrice ' COMPILE ERROR: wrong assembly
' Anyone: itm._price = 5 ' COMPILE ERROR: Private
Theory
The 2 renames and the 1 real difference
Mapping from BCA403's Java:
- Private and Public: identical twins, nothing new
- Friend plays the role of Java's package-private, with the boundary drawn at the assembly (the compiled project, the .exe or .dll) instead of a package folder
- Protected is the real difference: VB's Protected admits derived classes only. Java's protected ALSO admitted the whole package. Carrying Java's definition into a VB answer claims access that does not exist
- Protected Friend is the union (derived OR same assembly), which lands closest to what Java's protected actually was
Quiz
A Friend member of Item is accessed from another class in the SAME ShopKeeper project, one that does NOT inherit from Item. What happens?
- Compile error: Friend requires an inheritance relationship
- It works: Friend admits any code in the same project (assembly)
- It works only if the other class is in the same source file
- Runtime security exception when the line executes
Show the answer
It works: Friend admits any code in the same project (assembly)
Friend's boundary is the assembly: every class compiled into the ShopKeeper project is family, inheritance or not. Option A describes Protected, the neighbouring door, and mixing the 2 up is this topic's classic slip. Option C invents a file rule VB does not have; source-file layout never affects access. Option D is the wrong phase: like Java, like BCA403, access control is settled entirely at compile time. One-line memory: Friend = my project, Protected = my children.
Think first
The union door
Protected Friend combines 2 specifiers. Work out precisely who can access such a member: list the yes cases and the one important no case, then tap.
Show the answer
Yes: code anywhere in the same assembly (the Friend half, inheritance not required), AND derived classes in any assembly (the Protected half: an outside DLL that Inherits Item still gets in). The important no: an unrelated class in a different assembly: neither family nor project, both doors shut. It is an OR of permissions, so Protected Friend is WIDER than either part alone: the widest door before Public, and the answer to "which VB specifier behaves most like Java's protected?"
Watch out
Three specifier slips
Quoting Java's protected in a VB answer: VB Protected does NOT include the rest of the project; write "the class and its derived classes only".
Reading Friend as friendship between 2 classes: it is not C++'s friend declaration naming a specific class; it is a blanket same-assembly grant.
Forgetting the defaults: a plain Dim field inside a class is Private; a class declared without a specifier is Friend. Silence has meanings; know them.
Theory
Choose doors like an architect
Practical recipe for every member you declare: start Private; widen to Protected only when a child class genuinely needs it; use Friend for in-project plumbing (CostPrice); reserve Public for the surface you would happily document. That progression IS encapsulation policy, and the pillar lesson 2 pages ahead names it formally. Next, though, come the family pronouns: Me, MyBase and the one Java never had, MyClass.
Summary
Key takeaways
- Five specifiers: Private (class), Protected (class + derived only), Friend (same assembly/project), Protected Friend (union of those 2), Public (everywhere).
- Friend is .NET's package-private, drawn at the assembly boundary.
- VB Protected is NARROWER than Java's: derived classes only, no project-mates.
- Protected Friend = Protected OR Friend: the closest match to Java's protected.
- Access violations fail at compile time.
- Defaults: Dim fields in a class are Private; unspecified classes are Friend.
- Memory hook: Friend = my project, Protected = my children, Protected Friend = either.