Java Solid

---
description: Checks Java code for SOLID principles violations with Java-specific patterns. Use when user asks to "check SOLID principles", "is this good OOP", "single responsibility", "SOLID violations", "open closed principle", or "dependency inversion".
argument-hint: "[paste class or paste multiple related classes]"
allowed-tools: Read, Grep, Glob
---

Review the provided Java code for SOLID principles violations. For each principle, check for violations and suggest targeted improvements. Tailor suggestions to the detected Java version.

## S — Single Responsibility Principle
A class should have one reason to change.

**Violations to flag:**
- Classes named `*Manager`, `*Helper`, `*Utils` with more than 3 unrelated methods
- Service classes that also contain validation logic, email sending, AND database calls
- Classes with more than ~200 lines (often a signal of multiple responsibilities)
- Methods that do multiple distinct things (parse + validate + persist + notify)

**Fix pattern:** Extract each responsibility into its own class. Show the split.

## O — Open/Closed Principle
Open for extension, closed for modification.

**Violations to flag:**
- `if/else` or `switch` chains on type/status that would require modification to add new types
- Hard-coded behaviour that should be configurable
- Direct instantiation of concrete classes in business logic (use interfaces)

**Fix pattern:** Introduce Strategy, Template Method, or polymorphism. Show the refactoring.

## L — Liskov Substitution Principle
Subtypes must be substitutable for their base types.

**Violations to flag:**
- Subclass overrides a method by throwing `UnsupportedOperationException`
- Subclass weakens preconditions (accepts nulls when parent doesn't)
- Subclass strengthens postconditions (returns more restricted type)
- Square extends Rectangle anti-pattern

**Fix pattern:** Use composition over inheritance, or restructure the hierarchy.

## I — Interface Segregation Principle
Clients should not depend on interfaces they don't use.

**Violations to flag:**
- Interfaces with more than ~5 methods where implementors only use some
- `implements` classes that leave methods empty or throw `UnsupportedOperationException`
- Fat service interfaces used by clients that only call 1–2 methods

**Fix pattern:** Split the fat interface into focused role interfaces.

## D — Dependency Inversion Principle
Depend on abstractions, not concretions.

**Violations to flag:**
- Field or constructor takes a concrete class (`new UserServiceImpl`) instead of an interface (`UserService`)
- `new ConcreteClass()` inside business logic instead of dependency injection
- Static utility method calls deep in business logic that prevent testing
- `@Autowired` on a concrete class field instead of an interface

**Fix pattern:** Introduce interface + constructor injection. Show the change.

## Output format
For each violation:
1. **Principle violated:** (S/O/L/I/D)
2. **Location:** class + method
3. **Problem:** what rule is broken and why it matters
4. **Fix:** before/after code

End with: **SOLID Score** — how many of the 5 principles are cleanly satisfied (e.g., "3/5 — S, I, D pass; O and L need attention").

## Next Steps
- For O violations → run `/java-design-pattern` to find the right pattern
- For D violations → run `/java-refactor` to extract interfaces
- For SRP violations → run `/java-refactor` to split classes