gof-patterns_skill

This skill helps reviewers identify GoF design pattern opportunities in Jakarta EE and MicroProfile code, improving structure and maintainability.

1

GitHub Stars

1

Bundled Files

2 months ago

Catalog Refreshed

4 months ago

First Indexed

Readme & install

Copy the install command, review bundled files from the catalogue, and read any extended description pulled from the listing source.

Installation

Preview and clipboard use veilstrat where the catalogue uses aiagentskills.

npx veilstrat add skill emvnuel/skill.md --skill gof-patterns

  • SKILL.md9.7 KB

Overview

This skill detects opportunities to apply Gang of Four design patterns in Jakarta EE and MicroProfile applications. It helps reviewers and developers spot structural, creational, and behavioral refactoring candidates. Use it to suggest idiomatic Jakarta EE/MicroProfile replacements that improve modularity, testability, and maintainability.

How this skill works

The analyzer scans code for common smell signals—long constructors, switch/if chains creating objects, duplicated algorithm structure, scattered access-control checks, and complex inter-object wiring. For each detected smell it recommends a specific GoF pattern and shows how to map that pattern to Jakarta EE or MicroProfile features (CDI scopes/qualifiers, Events, Interceptors, REST Client, annotations). It also flags when a pattern would be unnecessary or harmful.

When to use it

  • Code reviews focused on architecture or maintainability
  • Refactoring sessions to reduce conditional logic or class coupling
  • When implementing subsystems that will evolve (pluggable strategies/factories)
  • When addressing memory or instantiation costs in high-load services
  • During MicroProfile integration to use platform features (health, fault tolerance)

Best practices

  • Prefer simple solutions; avoid adding patterns for speculative future needs
  • Map patterns to Jakarta EE primitives (CDI, Events, Interceptors) rather than reinventing infrastructure
  • Favor immutable objects and builders for complex construction
  • Use @ApplicationScoped instead of manual singletons for lifecycle and injection
  • Validate pattern benefits in performance-critical code before introducing indirection

Example use cases

  • Replace switch/new logic with a CDI-backed Factory Method using Instance<T> and qualifiers
  • Refactor controller code that calls many services into a Facade @ApplicationScoped service
  • Convert multiple conditional algorithm branches into Strategy implementations chosen by qualifier or configuration
  • Use CDI Events or a mediator service to decouple many-to-many component interactions
  • Apply Decorator/Interceptor patterns to add cross-cutting concerns (metrics, retries) in MicroProfile

FAQ

No. It provides detection and concrete refactoring recommendations; code changes remain manual or driven by your tooling pipeline.

How do I decide when not to apply a pattern?

Avoid applying patterns for trivial or stable cases, in performance-sensitive paths, or when they reduce clarity for your team. Use the provided "When NOT to Apply" guidance.

Built by
VeilStrat
AI signals for GTM teams
© 2026 VeilStrat. All rights reserved.All systems operational