Design an Input ValidatormediumDesign an Input Validator
Design a reusable input-validation system for a registration form. The form applies a list of rules to a string, but it should not need rule-specific logic to do so. Instead, every rule must follow the same contract while keeping its own validation behavior.
The RegistrationForm class is provided. Complete the shared Validator contract and implement the three validator classes it uses:
EmailValidatoraccepts a value when it contains@and reports its name asEmail.LengthValidatorreceivesminLengthwhen it is created, accepts a value when its length is at least that minimum, and reports its name asLength.DigitValidatoraccepts a value when it contains at least one digit from0to9and reports its name asDigit.
Each validator provides an isValid operation for the check and a name operation for reporting. The email rule is intentionally simple for this exercise: any value containing @ passes it.
The provided form supports these operations:
RegistrationForm()creates a form with no rules.int addEmailRule()adds an email rule and returns its zero-based index.int addLengthRule(int minLength)adds a length rule configured withminLengthand returns its zero-based index.int addDigitRule()adds a digit rule and returns its zero-based index.boolean validate(String value)returnstrueonly whenvaluesatisfies every rule. A form with no rules accepts any value.String report(String value)returns"<value> - PASSED"when every rule passes. Otherwise, it returns"<value> - FAILED (<rule>)"using the name of the first rule that fails.int ruleCount()returns the number of rules on the form.
Rules remain in the order they were added, and multiple instances of the same rule type are allowed. For example, a form may contain two length rules with different minimums. The design should also be open to a fourth validator type without requiring changes to validate or report.
Example 1:
Input:
Output:
Explanation: The email and length rules are stored at indices 0 and 1. user@example.com satisfies both rules. invalid-email is long enough, but it does not contain @, so the form reports the first failing rule: Email.
Example 2:
Input:
Output:
Explanation: With no rules, the form accepts anything and reports a pass. After a digit rule is added at index 0, the same value fails because it contains no digit.
Constraints:
0 <= value.length <= 400 <= minLength <= 40valueconsists of printable ASCII characters.- At most
100calls will be made across all methods.
How the design is graded
needs 7/10 to pass- Interface modelling
Full marks when a single validation contract (an interface, or the closest equivalent the language offers) declares both the check and the rule name, and each rule is a separate implementation of it. Lose points heavily when the form stores a rule-kind tag and branches on it in validate or report instead of asking the rule itself.
- Rule independence
Full marks when each rule carries its own configuration, so two length rules with different minimums can sit on the same form without interfering. Lose points when a rule's setting is stored on the form, when rules share mutable state, or when adding a fourth rule type would mean editing validate or report.
- Structure and naming
Full marks for a form that stores rules rather than parallel arrays of kinds and settings, with descriptive names and no dead code. Lose points for printing to stdout, or for a rule's display name appearing anywhere other than the rule itself.
Passing every test is not enough on its own. A submission is accepted only when the design also clears the bar.
| Call | Returns |
|---|---|
| new RegistrationForm() | null |
| addEmailRule() | 0 |
| addLengthRule(8) | 1 |
| report("user@example.com") | "user@example.com - PASSED" |
| report("invalid-email") | "invalid-email - FAILED (Email)" |
| validate("user@example.com") | true |
The email and length rules are added at indices 0 and 1. user@example.com passes both. invalid-email is long enough but lacks @, so Email is the first failing rule.
Run checks these cases. Submit also runs a larger hidden set.