Java SOLID Review

Scope

• Treat SOLID and object-oriented design rules as heuristics, not automatic mandates.
• Prefer maintainable, testable, intention-revealing, simple local designs over pattern-heavy code or hypothetical abstractions and optimizations.
• Apply project conventions and more specific Java skills first when they are relevant.

Skill Precedence

• For tests, use java-testing-style. This skill must not override its rules for test naming, mocking style, unit versus integration boundaries, assertions, layout, or verification scope.
• For readable Java naming, guard clauses, Optional, factories, utilities, and test-only production code, use java-readable-code.
• For domain-sensitive behavior, identifiers, persistence shape, or invariants, use java-domain-clarification before proposing or coding changes when rules are unclear.
• Use java-clean-architecture and java-ddd-architecture only when project instructions explicitly state those architectures; do not move code across such boundaries as incidental cleanup.

Review Workflow

1. Identify production behavior, required change, root cause, responsibilities, contracts, and boundaries before editing non-trivial code.
2. Locate the primary responsibility of each affected class or method.
3. Check for SOLID violations, hidden assumptions, or mixed concerns that create real change, testability, or comprehension risk.
4. Prefer the simplest local or vertical-slice refactor that removes the risk without changing behavior.
5. Verify with the narrowest credible test scope, following java-testing-style.