Refactor Member Signup

Refactor Member Signupeasy

easy

Refactor a MemberSignup workflow that validates an application, stores accepted member names, and records an audit entry for every attempt.

The minimum allowed name length is a policy that can change while the program is running. The starter exposes that change, but registration still uses an old hardcoded value. Fix the behavior and reorganize the code so validation, member storage, and auditing can evolve independently.

MemberSignup() creates an empty signup desk with a minimum name length of 3.
String signUp(String name, String email) checks an application and returns the first matching result:

"NAME_TOO_SHORT" when the name is shorter than the current minimum;
"INVALID_EMAIL" when email does not contain @ with at least one character on each side;
"DUPLICATE" when the name is already registered;
"REGISTERED" after accepting and storing the member.

boolean setMinimumNameLength(int minimum) changes the minimum when it is from 1 through 10. Any other value changes nothing and returns false.
int memberCount() returns the number of registered names.
String[] auditTrail() returns one entry for every registration attempt, in order, as "<name>: <result>".

Changing the minimum affects future attempts only. It does not remove existing members or rewrite the audit trail.

Example 1:

Input:

Output:

Explanation: bo fails the first rule, so email validation is not reached. Both attempts still receive audit entries.

Example 2:

Input:

Output:

Explanation: After the policy changes to five characters, every future registration must use that value.

Constraints

0 <= name.length <= 20
0 <= email.length <= 40
1 <= minimum <= 10 for valid updates.
At most 30 members are registered.
At most 100 calls are made across all methods.

Starter Code

The legacy implementation mixes three jobs and contains a stale validation rule. The setter updates minimumNameLength, but signUp still checks against 3.

How the design is graded

needs 7/10 to pass

Separate owners
Full marks when validation policy, registered-member state, and audit entries have separate focused owners, while MemberSignup coordinates them. Lose points when the public class still implements all three jobs.
One validation policy
Full marks when the current minimum name length is read from the same policy used by registration, so changing it affects every future attempt. Lose points for hardcoded or duplicated length and email rules.
Workflow behavior
Full marks when checks follow the required order, every attempt is audited exactly once, failed attempts do not add members, and invalid policy updates preserve the current minimum. Lose points for exposing mutable collections or printing the audit trail.

Passing every test is not enough on its own. A submission is accepted only when the design also clears the bar.

Hints

Call	Returns
new MemberSignup()	null
signUp("ana", "ana@example.com")	"REGISTERED"
signUp("bo", "invalid")	"NAME_TOO_SHORT"
memberCount()	1
auditTrail()	["ana: REGISTERED","bo: NAME_TOO_SHORT"]

Validation stops at the first failure, and both the accepted and rejected attempts are audited.

Run checks these cases. Submit also runs a larger hidden set.