Checkpoint 3: Data and Object Model

Design a small Java model that stores multiple domain values and makes invalid state difficult to create.

Required system

Your program must include:

• a justified array or collection choice;
• at least one domain type implemented as a class or record;
• a constructor or compact constructor that enforces an invariant;
• at least one behavior derived from object state;
• multiple instances stored and processed through the chosen structure.

Examples include sensor readings, match results, assignment attempts, inventory items, or other school-appropriate records.

Evidence package

Data-structure decision

State the operations your program requires and compare your chosen structure with at least one realistic alternative.

Object/value model

For each custom type, explain:

• what concept it represents;
• whether identity or value semantics matter more;
• what state belongs inside;
• what behavior belongs inside;
• what state does not belong there.

Invariant

State one rule that must remain true for every valid instance and show where construction or public behavior enforces it.

Valid and invalid cases

Create at least:

• one lower-bound valid case;
• one upper or other meaningful boundary case;
• one ordinary valid case;
• one invalid construction or transition that the model rejects.

Collection processing

Process multiple instances with one generalized algorithm. Do not duplicate the same calculation for item1, item2, item3.

Reference/value evidence

Show either:

• a reference-aliasing example for a class and explain shared mutation; or
• two equal record values and explain value equality versus reference identity.

Mastery standard

The model should communicate the problem more clearly than loose variables would. A submission with many classes but no clear responsibilities, invariants, or data-structure justification is not stronger than a smaller coherent design.