List all Access Modifiers (public, private, protected, internal/package-private).
Access Modifiers
Access modifiers control the visibility and accessibility of classes and their members. In Java, the primary access levels are public, protected, package-private, and private. C# provides public, private, protected, internal, protected internal, and private protected. As a senior engineer, I treat access modifiers as part of API and encapsulation design: the narrowest visibility that satisfies the requirement is generally preferable.
- 1
public: accessible wherever the language's visibility rules permit.
- 2
private: restricted to the declaring class/type.
- 3
protected: accessible to the declaring type and appropriate derived types.
- 4
Java package-private: accessible within the same package.
- 5
C# internal: accessible within the same assembly.
- 6
C# private protected: accessible to derived types within the same assembly.
- 7
Use the least visibility necessary to preserve encapsulation.
Scenario Questions
0-2 years experience
- 1You need to expose a utility method to other classes in the same package but hide it from external packages. Which access modifier would you use and why?
- 2If you declare a class member as private, can it be accessed from a subclass in the same package? Explain what happens.
2-5 years experience
- 1We have a class hierarchy where a subclass needs to override a method but we want to prevent external code from calling it directly. Which modifier would you choose and what are the trade‑offs?
- 2During a code review you notice a field marked as package‑private that is being accessed from a different module, causing a compilation error after we modularized the project. How would you resolve it and what considerations guide your choice of modifier?
5-8 years experience
- 1Our microservice exposes a public API class, but internal helper classes should not be used by other services. How would you structure the access modifiers and package layout to enforce this at compile time and aid future refactoring?
- 2We are refactoring a legacy monolith to a modular Java 9+ system. Some classes currently use protected members for cross‑module access. What issues can arise, and how would you redesign the visibility to maintain encapsulation while minimizing breaking changes?
8+ years experience
- 1Across several teams we have a shared library that defines core domain models. Some fields are currently public for convenience, but we want to tighten encapsulation without breaking downstream services. Describe a migration strategy, including how you’d use access modifiers, module exports, and deprecation to manage the transition.
- 2When designing a platform SDK that will be consumed by external partners, how do you decide which classes and members should be public versus package‑private or protected, considering versioning, backward compatibility, and security?
Follow-up Questions
- Can you describe a situation where using protected led to an unexpected bug?
- How would you verify that a member's visibility is correctly enforced in a large codebase?
- What are the risks of changing a public member to private in a released library?