Static Access, Coupling, and Cohesion in Java SE 25

Correct common misconceptions about static methods and review how dependencies and responsibilities affect Java class design.

1. What is the clearest way to access a static member?

   Answer: Qualify it with the declaring class name, such as Math.max(3, 7) or Integer.MAX_VALUE. Static imports can also be useful when they preserve clarity.

   Java permits some static class-member access through an instance expression, but that syntax misleadingly suggests instance dispatch and can trigger compiler warnings. Access restrictions still apply. Static interface methods are called through their declaring interface and are not inherited as instance methods.

2. Can a static method access an instance field?

   Answer: Yes, through an explicit object reference and subject to access control. It cannot simply use the current class's instance field as though it had an implicit this object.

   For example, a static method receiving a Box parameter can read an accessible box.value. If box is null, instance field access fails with NullPointerException. The field belongs to that particular object, not to the static method.

3. Can a static method call an instance method?

   Answer: Yes. It needs an object receiver, obtained through a parameter, local variable, factory result, or other expression. An unqualified call that requires an implicit current instance is not allowed in a static context.

   public class StaticReceiver {
       private final int value;
       StaticReceiver(int value) { this.value = value; }
       int doubled() { return value * 2; }
       static int calculate(StaticReceiver receiver) {
           return receiver.doubled();
       }
       public static void main(String[] args) {
           System.out.println(calculate(new StaticReceiver(6)));
       }
   }

   The program prints 12. Calculate is static, while doubled operates on the particular object passed to it. Static context does not prohibit virtual calls through explicit references.





4. What can a static method access?

   Answer: It can access permitted static members, its own parameters and locals, and instance members through appropriate object references. It has no implicit this or super receiver.

   Normal access rules remain in force, including private, package, protected, public, and module restrictions where relevant. Static does not mean globally accessible, thread-safe, or independent of mutable state.

5. Why are static methods hidden rather than overridden?

   Answer: Static method selection is tied to the compile-time qualifying type, not to a receiver object's runtime class. A subclass can declare a compatible same-signature static method that hides an accessible superclass static method.

   Using an instance expression to call the static method does not turn hiding into overriding. A same-signature static method also cannot replace an inherited instance method, or vice versa. Those incompatible declarations are compile-time errors.

6. What do coupling and cohesion describe?

   Answer: Coupling describes dependencies between components; cohesion describes how closely the responsibilities within a component belong together. Both help assess whether a design is understandable and can change safely.

   A common aim is focused responsibilities with manageable dependencies. These are design qualities rather than Java compiler rules or simple numerical pass/fail tests. A design can be cohesive yet tightly coupled to another system.




7. How would you explain coupling?

   Answer: It is the degree to which one component depends on another's contract or implementation details. Dependencies can include method signatures, concrete classes, data formats, shared mutable state, timing, and required call order.

   Depending on another object's undocumented field layout or initialization sequence creates more fragile coupling than depending on a small stable operation. Merely counting imports does not capture all these dependencies.

8. Is loose coupling always preferable to tight coupling?

   Answer: Lower coupling across meaningful boundaries usually makes replacement, testing, and independent change easier. However, zero coupling is neither realistic nor a useful goal: collaborating components necessarily share some contract.

   Additional interfaces and indirection have a cost. Introduce them where they clarify a real boundary or enable a needed variation, rather than wrapping every stable library call without benefit. The goal is intentional, manageable dependencies.




9. What makes two classes loosely coupled?

   Answer: They collaborate through a limited, stable contract and avoid assumptions about one another's internal representation or incidental behavior. For example, a service can depend on a PaymentGateway contract supplied through its constructor.

   Using a Java interface helps only if the contract is well designed. A large interface, exposed mutable internals, or undocumented required call sequences can still produce tight coupling. Test whether one implementation can be replaced without changing its callers.

10. What does cohesion mean for a class?

    Answer: It describes how strongly the class's data and operations support related responsibilities. An InvoiceCalculator whose methods calculate invoice amounts has higher conceptual cohesion than one that also sends email and manages database connections.

    High cohesion does not require every class to have one method or force related behavior into subclasses. Group responsibilities that belong together, expose meaningful operations, and split unrelated reasons for change into appropriate collaborators.

References: JLS: class members and method hiding, JLS: field access and invocation, and JLS: interface contracts. The design examples illustrate engineering tradeoffs rather than additional language requirements.