java-solid

Name: java-solid
Author: ducpm2303

17stars0forks

How to install java-solid?

ducpm2303/claude-java-plugins/java-solid

$npx -y skills add ducpm2303/claude-java-plugins --skill java-solid

Installs into the current project.

Summary

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

Files · 1

View on GitHub

SKILL.md

1	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.
2
3	## S — Single Responsibility Principle
4	A class should have one reason to change.
5
6	Violations to flag:
7	- Classes named `Manager`, `Helper`, `*Utils` with more than 3 unrelated methods
8	- Service classes that also contain validation logic, email sending, AND database calls
9	- Classes with more than ~200 lines (often a signal of multiple responsibilities)
10	- Methods that do multiple distinct things (parse + validate + persist + notify)
11
12	Fix pattern: Extract each responsibility into its own class. Show the split.
13
14	## O — Open/Closed Principle
15	Open for extension, closed for modification.
16
17	Violations to flag:
18	- `if/else` or `switch` chains on type/status that would require modification to add new types
19	- Hard-coded behaviour that should be configurable
20	- Direct instantiation of concrete classes in business logic (use interfaces)
21
22	Fix pattern: Introduce Strategy, Template Method, or polymorphism. Show the refactoring.
23
24	## L — Liskov Substitution Principle
25	Subtypes must be substitutable for their base types.
26
27	Violations to flag:
28	- Subclass overrides a method by throwing `UnsupportedOperationException`
29	- Subclass weakens preconditions (accepts nulls when parent doesn't)
30	- Subclass strengthens postconditions (returns more restricted type)
31	- Square extends Rectangle anti-pattern
32
33	Fix pattern: Use composition over inheritance, or restructure the hierarchy.
34
35	## I — Interface Segregation Principle
36	Clients should not depend on interfaces they don't use.
37
38	Violations to flag:
39	- Interfaces with more than ~5 methods where implementors only use some
40	- `implements` classes that leave methods empty or throw `UnsupportedOperationException`
41	- Fat service interfaces used by clients that only call 1–2 methods
42
43	Fix pattern: Split the fat interface into focused role interfaces.
44
45	## D — Dependency Inversion Principle
46	Depend on abstractions, not concretions.
47
48	Violations to flag:
49	- Field or constructor takes a concrete class (`new UserServiceImpl`) instead of an interface (`UserService`)
50	- `new ConcreteClass()` inside business logic instead of dependency injection
51	- Static utility method calls deep in business logic that prevent testing
52	- `@Autowired` on a concrete class field instead of an interface
53
54	Fix pattern: Introduce interface + constructor injection. Show the change.
55
56	## Output format
57	For each violation:
58	1. Principle violated: (S/O/L/I/D)
59	2. Location: class + method
60	3. Problem: what rule is broken and why it matters
61	4. Fix: before/after code
62
63	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").
64
65	## Next Steps
66	- For O violations → run `/java-design-pattern` to find the right pattern
67	- For D violations → run `/java-refactor` to extract interfaces
68	- For SRP violations → run `/java-refactor` to split classes

People who liked this also viewed

6 picks

Type

java-solid

17stars0forks

View on GitHub

How to install java-solid?

ducpm2303/claude-java-plugins/java-solid

$npx -y skills add ducpm2303/claude-java-plugins --skill java-solid

Installs into the current project.

Summary

Files · 1

View on GitHub

SKILL.md

1	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.
2
3	## S — Single Responsibility Principle
4	A class should have one reason to change.
5
6	Violations to flag:
7	- Classes named `Manager`, `Helper`, `*Utils` with more than 3 unrelated methods
8	- Service classes that also contain validation logic, email sending, AND database calls
9	- Classes with more than ~200 lines (often a signal of multiple responsibilities)
10	- Methods that do multiple distinct things (parse + validate + persist + notify)
11
12	Fix pattern: Extract each responsibility into its own class. Show the split.
13
14	## O — Open/Closed Principle
15	Open for extension, closed for modification.
16
17	Violations to flag:
18	- `if/else` or `switch` chains on type/status that would require modification to add new types
19	- Hard-coded behaviour that should be configurable
20	- Direct instantiation of concrete classes in business logic (use interfaces)
21
22	Fix pattern: Introduce Strategy, Template Method, or polymorphism. Show the refactoring.
23
24	## L — Liskov Substitution Principle
25	Subtypes must be substitutable for their base types.
26
27	Violations to flag:
28	- Subclass overrides a method by throwing `UnsupportedOperationException`
29	- Subclass weakens preconditions (accepts nulls when parent doesn't)
30	- Subclass strengthens postconditions (returns more restricted type)
31	- Square extends Rectangle anti-pattern
32
33	Fix pattern: Use composition over inheritance, or restructure the hierarchy.
34
35	## I — Interface Segregation Principle
36	Clients should not depend on interfaces they don't use.
37
38	Violations to flag:
39	- Interfaces with more than ~5 methods where implementors only use some
40	- `implements` classes that leave methods empty or throw `UnsupportedOperationException`
41	- Fat service interfaces used by clients that only call 1–2 methods
42
43	Fix pattern: Split the fat interface into focused role interfaces.
44
45	## D — Dependency Inversion Principle
46	Depend on abstractions, not concretions.
47
48	Violations to flag:
49	- Field or constructor takes a concrete class (`new UserServiceImpl`) instead of an interface (`UserService`)
50	- `new ConcreteClass()` inside business logic instead of dependency injection
51	- Static utility method calls deep in business logic that prevent testing
52	- `@Autowired` on a concrete class field instead of an interface
53
54	Fix pattern: Introduce interface + constructor injection. Show the change.
55
56	## Output format
57	For each violation:
58	1. Principle violated: (S/O/L/I/D)
59	2. Location: class + method
60	3. Problem: what rule is broken and why it matters
61	4. Fix: before/after code
62
63	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").
64
65	## Next Steps
66	- For O violations → run `/java-design-pattern` to find the right pattern
67	- For D violations → run `/java-refactor` to extract interfaces
68	- For SRP violations → run `/java-refactor` to split classes

People who liked this also viewed

6 picks

Type