Improve validation and simplify API usage using Chain of Responsibility and Facade patterns #714

Activity

1. justcla commented on Aug 24, 2026

   

   justcla

   on Aug 24, 2026

   More actions

   I am looking into this.
2. justcla commented on Aug 24, 2026

   

   justcla

   on Aug 24, 2026

   More actions

   I used your description and proposed design to have an agent check the problem and received the following feedback:

   The Facade pattern request is realistic — simplifying access to CronDefinitionBuilder, CronParser, ExecutionTime, and CronDescriptor behind a single class is a plausible real-world improvement.

   However, the Chain of Responsibility requirement is problematic. The existing codebase already has a well-structured two-step validation architecture: CronParser.parse() handles structural/syntactic validation, and Cron.validate() performs semantic validation using ValidationFieldExpressionVisitor and CronConstraint rules. The problem asks the agent to introduce a parallel chain of validators (SyntaxValidator, FieldCountValidator, FieldRangeValidator, SpecialCharacterValidator, FieldCombinationValidator) that would largely duplicate logic already embedded in the parser and the Cron.validate() infrastructure. This feels artificial — a real engineer would be more likely to extend the existing CronConstraint mechanism or refactor the ValidationFieldExpressionVisitor than to create an entirely separate validation chain that reimplements what the parser and validator already do.

   I get that the validators in the design proposal were provided as an example only, and my agent seems to have misunderstood that. But it does raise the point that the existing implementation supports five cron types (CRON4J, QUARTZ, UNIX, SPRING, SPRING53), and these already have their own inbuilt validation logic.

   The CronValidator is a Jakarta Bean Validation ConstraintValidator — its job is to delegate to CronParser for parsing and then call .validate() on the parsed Cron object. Replacing the CronParser call with a chain of hand-rolled validators (e.g. SyntaxValidator, FieldCountValidator, FieldRangeValidator, SpecialCharacterValidator, FieldCombinationValidator) would duplicate validation logic that already exists inside the parsing and validation infrastructure, and would break the existing design where parsing and validation are tightly coupled (the parser itself enforces syntax, field counts, ranges, etc.).

   What are your thoughts about how the Chain of Responsibility validators would work with the existing cron formats?
3. justcla commented on Aug 24, 2026

   

   justcla

   on Aug 24, 2026

   More actions

   Would there be value in separating this issue into two separate issues: one for the Facade, and the other for the Chain of Responsibility?
   Would the implementation of the Facade alone offer value?
4. justcla commented on Aug 24, 2026

   

   justcla

   on Aug 24, 2026

   More actions

   With the facade, how do you see it handling the constructor of the CronDefinitionBuilder, which is currently hard-coded to handle just the five cron-types? Should the Facade include an initialiser method that defines the various parameters and limits of the cron format and maybe refactor those 5 methods out of the existing CronDefintionBuilder class?