# Com / Optage / Testdata / Targets

## Overview

This module is a test-data package under `com.optage.testdata` that provides stub target classes used during testing and static analysis. It defines placeholder classes for email and SMS rules, along with a reflection target helper. These classes serve as minimal, compilable fixtures so that higher-level utilities (like `JBSbatCheckUtil.invoke`) and the `run` module have concrete types to reference, instantiate, or inspect via reflection without pulling in real business logic.

## Key Classes

### [EmailRule](src/main/java/com/optage/testdata/targets/EmailRule.java)

A stub class representing an email rule target. It declares a `check()` method with no implementation, acting as a marker type rather than a functional rule. This class appears to be intended as a test-data placeholder that the `JBSbatCheckUtil.invoke()` utility expects when the `"e-mail"` rule is supplied.

- **Purpose:** Provides a concrete class the test infrastructure can reference when working with email-related rule checks.
- **Key method:** `check()` — a no-op method. In production code this would likely perform validation or evaluation logic for an email rule.
- **Design note:** Because the body is empty, this class exists primarily as a type fixture for reflection and integration tests.

### [SmsRule](src/main/java/com/optage/testdata/targets/SmsRule.java)

A stub class mirroring `EmailRule` for SMS rules. Like its counterpart, it declares an empty `check()` method and serves as a placeholder type for test data.

- **Purpose:** Provides a concrete class the test infrastructure can reference when working with SMS-related rule checks.
- **Key method:** `check()` — a no-op method. Would hold SMS validation logic in a real implementation.
- **Design note:** Structured identically to `EmailRule` for symmetry, enabling the test harness to treat both rule types uniformly.

### [ReflectTarget](src/main/java/com/optage/testdata/targets/ReflectTarget.java)

A simple class used as a reflection target within the test-data suite. Its `hello()` method prints `"hello"` to stdout. Unlike the rule stubs, this class has non-trivial behavior and is actively consumed by the `run` module.

- **Purpose:** Serves as a callable target for reflection-based invocation and testing. The `run` module uses this class directly.
- **Key method:** `hello()` — prints the string `"hello"` to standard output. This is the only method and the only non-empty body in the entire package.
- **Relationship to other modules:** The `run` module imports and uses `ReflectTarget`, making this the primary class in the package that has a real consumer outside the test-data layer.

## How It Works

The package follows a **stub-for-testing** pattern. Here is a typical flow through the code:

1. Higher-level test utilities or frameworks (such as `JBSbatCheckUtil.invoke`) receive rule type names as strings — for example, `"e-mail"` or `"sms"`.
2. These utilities may use reflection to locate and instantiate the corresponding rule class (e.g., `EmailRule` or `SmsRule`).
3. Once instantiated, the utility calls the `check()` method on the rule object. In this test-data stub, `check()` does nothing, but in a production scenario it would contain the actual rule-evaluation logic.
4. Separately, the `run` module directly invokes `ReflectTarget.hello()`, demonstrating that `ReflectTarget` is the actively exercised class in the test-data suite.

This separation — rule stubs on one side, a callable target on the other — lets the test suite exercise both reflection-based rule dispatch and direct invocation paths.

## Data Model

This package does not define any data model classes (no entities, DTOs, or value objects). The three classes are all behavioral stubs with no fields or serialization concerns.

## Dependencies and Integration

### Inbound dependencies (who uses this module)

- The **`run`** module uses `ReflectTarget` directly. This is the only known consumer of this package outside its own module boundary.

### Outbound dependencies

- No package-level dependencies are declared. The classes themselves do not import any external libraries. They rely only on standard JDK types (`java.lang.Object`, `System.out`).

### Relationship to sibling modules

The `targets` package sits alongside two other test-data packages within `com.optage.testdata`:

- **`reflection`** — contains reflection invocation utilities (`DispatchFrameworkInvoke`, `ReflectionForNameConstant`, etc.) that likely use `ReflectTarget` and the rule stubs as test fixtures.
- **`util`** — provides `JBSbatCheckUtil`, a utility whose `invoke()` method appears to dispatch to rule checks for `"e-mail"` and `"sms"`.

```mermaid
flowchart LR
    RT["ReflectTarget"]
    ER["EmailRule"]
    SR["SmsRule"]
    JBSJ["JBSbatCheckUtil"]
    RUN["run module"]
    RT -->|"invoked via"| JBSJ
    RT -->|"used by"| RUN
    ER -->|"stub for"| JBSJ
    SR -->|"stub for"| JBSJ
    JBSJ -. "receives 'e-mail'" .- ER
    JBSJ -. "receives 'sms'" .- SR
```

## Notes for Developers

- **Empty method bodies:** Both `EmailRule.check()` and `SmsRule.check()` are empty stubs. If you are implementing or extending rule logic, these are the methods to populate.
- **Test-data, not production:** This package lives under `com.optage.testdata`, signaling it is intended for testing and analysis harnesses. Do not assume these classes contain production-ready logic.
- **`ReflectTarget` is the active class:** Of the three classes, only `ReflectTarget` has actual behavior and a real consumer (`run`). The rule stubs (`EmailRule`, `SmsRule`) exist primarily as type placeholders.
- **Reflection-based dispatch:** The presence of `JBSbatCheckUtil.invoke()` accepting a `String[]` of rule names suggests the broader system resolves rule classes by string name. When extending this package with new rule types, ensure they follow the same convention (a public no-arg constructor and a `check()` method).