AlgoMaster Logo
AlgoMasterDesign Profile Serviceeasy

Design Profile Service

easy

A legacy profile service has gradually taken on three jobs: validating profiles, storing them, and deciding how they should be displayed. The happy path looks reasonable, but its responsibilities leak into one another. Merely checking a profile stores it, and switching the display format erases every saved profile.

Refactor the starter code so each concern has a clear home while preserving the public ProfileService API:

  • ProfileService() creates a service with no profiles, displaying in short style.
  • boolean isValid(String name, int age) returns whether the pair is acceptable: the name must not be empty and the age must be between 0 and 150 inclusive. It stores nothing.
  • boolean save(String name, int age) stores the profile and returns true, or returns false and stores nothing when the pair is not acceptable. Saving a name already stored replaces its age.
  • int count() returns how many profiles are stored.
  • boolean setFormat(String style) sets the display style to "short" or "long" and returns true. Anything else changes nothing and returns false.
  • String format(String name) returns the stored profile as its name under short, or "<name> (age <age>)" under long. An unknown name gives "NOT FOUND".

The two independence rules matter just as much as the return values: checking a profile must not store it, and changing the display style must not alter the stored profiles.

ProfileService is the only type the tests instantiate, but it should become a coordinator rather than the place where every decision is made. Introduce separate collaborators for validation, storage, and formatting.

Example 1:

Input:

Output:

Explanation: Asking whether a profile is valid stores nothing, and saving the same profile afterwards is what adds it.

Example 2:

Input:

Output:

Explanation: Switching the display style changes how a profile reads without touching what is stored.

Constraints:
  • 0 <= name.length <= 40
  • -1000 <= age <= 1000
  • style is a lowercase word.
  • At most 100 calls will be made across all methods.

How the design is graded

needs 7/10 to pass
  • Separated concerns

    Full marks when validation, storage and formatting are three separate types the service coordinates, each doing one job. Lose points heavily when one class holds the rules, the data and the display format together, or when the service performs all three inline.

  • Concerns do not leak

    Full marks when isValid stores nothing, setFormat leaves stored profiles untouched, and save refuses invalid input by asking the validator rather than repeating its rules. Lose points when checking a profile records it, when changing the format clears or alters storage, or when the validation rules appear in more than one place.

  • Structure and naming

    Full marks when an unrecognised style is refused, formatting an unknown profile is handled deliberately, and the count comes from the store rather than a separate tally. Lose points for printing to stdout or for a stored profile being formatted at the moment it is saved.

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

Hints

Loading...
CallReturns
new ProfileService()null
isValid("ada", 30)true
count()0
save("ada", 30)true
count()1
format("ada")"ada"

Asking whether a profile is valid stores nothing, and saving the same profile afterwards is what adds it.

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