Java Solid

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".

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