Implement an Email BuildereasyImplement an Email Builder
Imagine the awkward constructor call needed to create an email with a recipient, a subject, several CC and BCC addresses, a body, a priority, and a list of attachments. Most messages use only a few of those options, so a builder gives callers a much more natural way to assemble the email one choice at a time.
Your task is deliberately focused: implement only the EmailBuilder class. The Email product and the EmailComposer test harness are already implemented in the starter code.
The builder must provide this behavior (method names follow each language's starter code):
EmailBuilder(to, subject)stores the two required fields. It also starts with empty CC, BCC, and attachment lists, an empty body, and priority"normal".addCc(address),addBcc(address), andaddAttachment(name)append one item without changing the order of earlier items.setBody(text)andsetPriority(level)replace their current values.- Every configuration method returns the same builder instance so calls can be chained.
build()returns a newEmailcontaining the builder's current state. Building must not reset or otherwise change the builder.
The provided EmailComposer is how the tests drive your builder. It validates the recipient, subject, and priority; forwards optional fields to the active builder; and stores every email returned by build(). Calls made before a draft exists return false, and build() returns "ERROR: no draft" when nothing has been started. You do not need to implement any of that orchestration.
An email renders like this:
Email{to='a@x.com', subject='Hello', cc=[b@x.com, c@x.com], bcc=[], body='Hi there.', priority='normal', attachments=[report.pdf]}
CC recipients, BCC recipients, and attachments appear in insertion order. Because the provided Email copies the builder's lists, an email already built remains unchanged when the same draft receives another address or attachment later.
The examples use EmailComposer operations because it is the public test harness. Your code changes belong only inside EmailBuilder.
Example 1:
Input:
Output:
Explanation: The draft carries only a body, so the two lists and the attachment list render empty and the priority stays at its default. One build moves the count to 1.
Example 2:
Input:
Output:
Explanation: Two calls to cc leave two addresses in the order they arrived, and the same holds for the two attachments. Every optional field set here appears in the rendering.
Constraints
0 <= to.length, subject.length <= 400 <= text.length <= 2000 <= index <= 100- At most
20values are added to any one list on a draft. - At most
100calls in total are made across all methods.
Starter Code
Only the EmailBuilder type is unfinished. No builder template is supplied: define all of its fields, its constructor, and its methods yourself. Every other type is already implemented; do not rewrite it.
How the design is graded
needs 7/10 to pass- Complete initial state
Full marks when the constructor stores to and subject, creates three empty lists, and sets body to empty text and priority to normal. Lose points when collections are left null or state leaks between builders.
- Fluent field updates
Full marks when addCc, addBcc and addAttachment append in insertion order, setBody and setPriority replace their values, and every configuration method returns the same builder. Lose points for sorting, overwriting repeatable fields, or returning a different builder.
- Product creation
Full marks when build returns a new Email created from the current builder state on every call. Lose points when build formats a string itself, mutates or clears the draft, or reuses a previously built Email.
Passing every test is not enough on its own. A submission is accepted only when the design also clears the bar.
| Call | Returns |
|---|---|
| new EmailComposer() | null |
| start("alice@example.com", "Meeting Tomorrow") | true |
| body("Let's meet at 10am in conference room B.") | true |
| build() | "Email{to='alice@example.com', subject='Meeting Tomorrow', cc=[], bcc=[], body='Let's meet at 10am in conference room B.', priority='normal', attachments=[]}" |
| buildCount() | 1 |
The draft carries only a body, so the two lists and the attachment list render empty and the priority stays at its default. One build moves the count to 1.
Run checks these cases. Submit also runs a larger hidden set.