What this prompt does
This prompt asks the AI to recommend and implement the right design pattern for [use_case] in a Java [java_version] Spring Boot application, because the wrong pattern is as costly as none. It explains why the chosen pattern fits and what alternatives were weighed, implements it with modern Java features (records, sealed interfaces, pattern matching), integrates it with Spring DI and lifecycle, shows it handling [edge_case], includes unit tests with [test_framework], provides a UML class diagram, gives a before/after comparison, explains the SOLID principles satisfied, and notes when NOT to use the pattern. You supply additional [context] to ground the recommendation.
The structure works because pattern choice is easy to get wrong, and this prompt forces alternatives to be considered, the design to be justified, and the over-engineering risk to be named explicitly. Tying the implementation to your real [use_case] and [edge_case] keeps it from being a textbook example with no bearing on your code. The before/after comparison is the part that earns its place: seeing the code without the pattern next to the code with it makes it obvious whether the added structure actually reduces complexity or just relocates it.
When to use it
- You have a
[use_case](such as handling several payment types with different rules) and are unsure which pattern fits. - You want alternatives weighed and a justified recommendation, not just one pattern asserted.
- You want modern Java idioms (records, sealed interfaces, pattern matching) rather than dated boilerplate.
- You need the pattern to integrate cleanly with Spring dependency injection and lifecycle.
- You want an honest note on when the pattern would be over-engineering.
- You want tests and a before/after comparison to judge whether the pattern earns its complexity.
Example output
Expect a recommendation with reasoning and rejected alternatives, an implementation using modern Java features, Spring integration, a demonstration of [edge_case], unit tests with [test_framework], a UML diagram in ASCII or Mermaid, a before/after code comparison, the SOLID principles it satisfies, and a clear over-engineering caveat. It reads as a decision document plus working code, not just a snippet.
Pro tips
- Describe
[use_case]concretely, including the variation that motivates a pattern (different validation per payment type), so the recommendation is grounded. - Set
[edge_case]to the extension you actually expect (adding a new type without touching existing code) to test the pattern's flexibility. - Match
[java_version]to your runtime, since records, sealed interfaces, and pattern matching availability differ by version. - Provide real
[context](traffic, constraints) so the AI weighs performance and complexity appropriately. - Take the over-engineering note seriously; if the before/after shows little gain, a simpler approach may be better.
- Iterate by asking it to compare the recommended pattern against a specific alternative you had in mind.
