Design poker-like hand comparison with custom ranking

Problem

Design an object-oriented solution to compare two players' hands in a card game similar to poker.

You are given two hands (each a fixed number of cards; assume 5 unless you state otherwise). Each hand has a hand type (e.g., three-of-a-kind, pair, full house, etc.). Your design must compare hands, decide a winner (or a tie), and remain extensible so that new hand types and new ruleset orderings can be added without rewriting the comparison engine.

The deliverable is a design plus reference implementation sketch: sketch the class/module breakdown (key classes, interfaces, responsibilities), describe the comparison logic (including tie-break rules and how you represent a hand's "comparison key"), and explain how the extension mechanism in Part 2 fits in.

Constraints & Assumptions

• Hand size: assume 5 cards per hand unless you state otherwise; do not hard-code the size into the core logic.
• Card ranks are totally ordered (e.g., 2..A, with ace high by default). Suits exist and may be referenced if needed.
• A single standard deck: no two cards share the same (rank, suit) identity, but rank collisions across suits are expected (that is what produces pairs, trips, etc.).
• Type precedence is per-ruleset, not global: the same registered types may rank differently in different games.
• The deliverable is a design plus reference implementation sketch, not a hardened production library; favor clarity and extensibility over micro-optimization.

Clarifying Questions to Ask

• Is the hand size always 5, or should the design support other fixed sizes (e.g., 7-card games)?
• Does add_type receive only a matches-style detector, or may I also supply a per-type scoring/tie-break function? (This materially changes the design.)
• Is a single standard deck assumed, or can hands contain duplicate card identities or wild cards / jokers?
• How should ace be treated — strictly high, or should an ace-low straight (the A-2-3-4-5 "wheel") be supported?
• On an exact tie (identical strength), is the result a tie/split, or does the ruleset ever break ties by suit?
• Is evaluation_orders guaranteed to cover every hand a player could hold (i.e., is there always a catch-all type), or must I handle "matches no type"?

Part 1 — Comparison and ranking

Implement the core comparison so that, given two hands, you can return which one is larger or whether they tie.

1. Compare two hands and return which one is larger (or if they tie).
2. If the two hands have different types, the winner is decided by the type ranking (e.g., full house > three-of-a-kind, etc.).
3. If the two hands have the same type, break ties by comparing the relevant card ranks in order.

• Example: for three-of-a-kind, 8883x should beat 7773x because the 8-trip outranks the 7-trip (assume remaining kickers are compared after the trips if needed).

Part 2 — Extension mechanism

Make the type system pluggable so new hand types and new rulesets do not require touching the engine.

1. Implement add_type(type_id: string, matches_function: function) that registers a new hand type and how to detect it.
2. The main evaluate function takes an extra parameter evaluation_orders: array<string> that specifies the type precedence (strongest to weakest) used when comparing hands, allowing different games/rulesets to be expressed as data rather than code.
3. Explain how add_type(...) and evaluation_orders work together to classify a hand and place it in the ranking.