# KKW05501SF02DBean

## Purpose

`KKW05501SF02DBean` is a **domain data transfer object (DTO)** that aggregates the state of every field on a Japanese telecom services management screen (the "KKW05501" screen). It acts as a single, serializable container holding over 50 business entities — each with its own value, enable/disable flag, display state, and update flag — so that JSP views can read and write field data through a uniform key/subkey routing mechanism. In short, it exists to bridge a JSP presentation layer and the server-side business logic without the view needing to know any class structure by name.

## Design

The class follows a **plain data bean / model** pattern within a legacy JavaServer Pages (JSP) MVC architecture. It does not extend a base class, but it implements three interfaces:

- **`X33VDataTypeBeanInterface`** — signals that the bean supports type introspection via `typeModelData()`.
- **`X33VListedBeanInterface`** — signals that the bean can enumerate its fields via `listKoumokuIds()`.
- **`Serializable`** — allows the bean to be transferred across JVM boundaries (e.g., HTTP session replication, RMI).

Each domain concept (e.g., Customer ID, Contract Service Code) is represented by a set of four parallel properties:

| Property | Java Type | Purpose |
|---|---|---|
| `\<field\>_value` | `String` or `Boolean` | The actual data value |
| `\<field\>_enabled` | `Boolean` | Whether the field is editable (`false` = grayed-out) |
| `\<field\>_state` | `String` | UI state hint (e.g., `"readonly"`, `"required"`) |
| `\<field\>_update` | `String` | Marks whether the field was modified on the client |

The `_value` field's Java type depends on the domain concept: `Boolean` is used for selection/check-box fields (e.g., `l_sel_value`), while `String` is used for all text/numeric/code fields. All `_enabled` flags default to `false` (disabled), and all `_value` / `_state` String fields default to `""`.

### The field naming convention

All instance fields are `protected`, prefixed with `l_`, and use Japanese-language semantic naming in their base forms. The four suffixes (`_update`, `_value`, `_enabled`, `_state`) are applied uniformly. For example:

```
l_svc_kei_no_update     // "was this field updated?"
l_svc_kei_no_value      // the actual customer contract number
l_svc_kei_no_enabled    // can the user edit it?
l_svc_kei_no_state      // UI rendering hint
```

The class also carries a single `index` field (`int`) likely used for row-position tracking in tabular views.

### Key architectural note: key-based dynamic dispatch

The three core public methods (`loadModelData`, `storeModelData`, `typeModelData`) do **not** use Java reflection on individual fields. Instead, they use a **string-key dispatch** system: the caller passes a Japanese-language field name (the "key") and a sub-key (`"value"`, `"enable"`, or `"state"`), and the method executes a long `if-else` chain to route to the correct getter or setter. This design allows the JSP layer to operate entirely with string identifiers, decoupling the view from any compile-time Java class reference.

## Key Methods

### Constructor

```java
public KKW05501SF02DBean()
```

Default constructor. It performs no initialization beyond the field-level defaults set in the field declarations. The body is effectively empty.

### `loadModelData(String key, String subkey) → Object`

The **primary getter** for all bean data. Given a Japanese-language field name and a sub-key, it returns the appropriate property value:

- **Parameters:**
  - `key` — The field name in Japanese (e.g., `"お客さまID"` for Customer ID, `"選択"` for Selection). `null` is guarded.
  - `subkey` — One of `"value"`, `"enable"`, or `"state"`. `null` is guarded.
- **Returns:** The property value as `Object` — either `String` or `Boolean`, depending on the field. Returns `null` if `key` or `subkey` is `null`.
- **Behavior:** Executes an `if-else` cascade matching each Japanese key. For each key, it dispatches on `subkey` to call the correct getter (e.g., `getKeyL_svc_kei_no_value()` for `"value"`, `getKeyL_svc_kei_no_enabled()` for `"enable"`, `getKeyL_svc_kei_no_state()` for `"state"`). Returns `null` for unrecognized keys (the `if` chain does not have a final `else` fallback).

### `storeModelData(String gamenId, String key, String subkey, Object in_value) → void`

Overloaded setter that delegates to the three-parameter variant. The `gamenId` (screen ID) parameter is reserved/unused and documented as "備忘" (memo/future use).

### `storeModelData(String key, String subkey, Object in_value) → void`

Three-parameter overload that delegates to the four-parameter variant with `isSetAsString = false`.

### `storeModelData(String key, String subkey, Object in_value, boolean isSetAsString) → void`

The **primary setter** for all bean data. Mirrors the structure of `loadModelData`:

- **Parameters:**
  - `key` — Japanese field name (same set as `loadModelData`).
  - `subkey` — `"value"`, `"enable"`, or `"state"`.
  - `in_value` — The value to set, cast to the expected type at dispatch time (`(String)` or `(Boolean)`).
  - `isSetAsString` — A boolean flag described in comments as: when `true`, forces a `String` value assignment to `Long`-type field properties (though no `Long` fields exist in this bean today; this appears to be forward-compatibility or inherited logic).
- **Behavior:** Same `if-else` dispatch as `loadModelData`, but invokes setters instead of getters. Returns silently if `key` or `subkey` is `null`. Type casts are un-checked (e.g., `(Boolean) in_value`, `(String) in_value`).

### `listKoumokuIds() → ArrayList<String>`

A **static** method that returns a complete list of all field keys (in Japanese) that this bean supports. The list contains exactly 56 entries, one per domain concept. This is used by the framework to enumerate available fields for rendering, validation, or serialization. The list order reflects declaration order in the source file.

Returns an `ArrayList<String>` containing keys such as:
```
"選択", "お客さまID", "契約サービスコード", "契約サービス名称",
"料金コード", "料金コード名称", "利用住所", "契約状態",
"システムID", "契約者タイプコード", "内販外販コード", ...
```

### `typeModelData(String key, String subkey) → Class<?>`

Returns the **Java type** of a given field property. Used by the framework for type-safe marshalling and validation:

- **Parameters:** Same `key`/`subkey` convention as `loadModelData`.
- **Returns:** The `Class` object:
  - `Boolean.class` for `_value` when the field is a selection (e.g., `"選択"`), and for all `_enabled` sub-keys.
  - `String.class` for all other `_value` and `_state` sub-keys.
- **Behavior:** Same `if-else` dispatch pattern. Returns `null` for unrecognized keys or `null` inputs.

### Index getters/setters

```java
public int getIndex()
public void setIndex(int index)
```

Simple accessor for the `index` field. Used for tracking row position when the bean represents a row in a multi-row table on the screen.

### Standard getters and setters (individual fields)

Each of the ~50+ domain fields has a full set of getter/setter pairs. For example, for "Customer ID" (`l_svc_kei_no`):

| Method | Return Type | Description |
|---|---|---|
| `getL_svc_kei_no_value()` | `String` | Gets the customer ID value |
| `setL_svc_kei_no_value(String)` | `void` | Sets the customer ID value |
| `getL_svc_kei_no_enabled()` | `Boolean` | Checks if the field is editable |
| `setL_svc_kei_no_enabled(Boolean)` | `void` | Sets the editability flag |
| `getL_svc_kei_no_state()` | `String` | Gets the UI state hint |
| `setL_svc_kei_no_state(String)` | `void` | Sets the UI state hint |
| `getL_svc_kei_no_update()` | `String` | Checks if the field was updated |
| `setL_svc_kei_no_update(String)` | `void` | Sets the update flag |

Every field in the bean follows this identical 4-property pattern. The field names use descriptive Japanese abbreviations:

- `l_sel_*` — 選択 (Selection / checkbox)
- `l_svc_kei_no_*` — お客さまID (Customer ID)
- `l_svc_kei_cd_*` — 契約サービスコード (Contract Service Code)
- `l_svc_kei_nm_*` — 契約サービス名称 (Contract Service Name)
- `l_pcrs_cd_*` — 料金コード (Cost Code)
- `l_pcrs_nm_*` — 料金コード名称 (Cost Code Name)
- `l_use_place_*` — 利用住所 (Use Place / Dwelling Address)
- `l_svc_kei_stat_*` — 契約状態 (Contract Status)
- `l_sysid_*` — システムID (System ID)
- `l_keisha_type_cd_*` — 契約者タイプコード (Contractor Type Code)
- `l_naihan_gaihan_cd_*` — 内販外販コード (Inside/Outside Sales Code)
- `l_naihan_comp_skbt_cd_*` — 内販企業識別コード (Inside Sales Company ID Code)
- `l_prc_grp_cd_*` — 料金グループコード (Cost Group Code)
- `l_pplan_cd_*` — 料金プランコード (Cost Plan Code)
- `l_pplan_nm_*` — 料金プラン名称 (Cost Plan Name)
- `l_color_*` — 背景色 (Background Color)
- `l_tokusoku_no_*` — -promotion番号 (Promotion Number)
- `l_tokusoku_stat_*` — 促進状態 (Promotion Status)
- `l_seiopsvc_kei_no_*` — 請求オプションサービス契約番号 (Request Option Service Contract Number)
- `l_mskm_dtl_no_*` — 申請明細番号 (Application Details Number)
- `l_seiky_kei_no_*` — 請求先番号 (Invoicing Party Number)
- `l_kakins_no_*` — 課金先番号 (Billing/Posting Party Number)
- `l_last_upd_dtm_*` — 最終更新年月日时分秒 (Last Update Datetime)
- `l_ido_div_*` — 移動区分 (Movement Division)
- `l_svc_kei_kaisen_ucwk_no_*` — サービス契約回線内訳番号 (Service Contract Line Internal Referral Number)
- `l_svc_cd_*` — サービスコード (Service Code)
- `l_svc_kei_stat_cd_*` — サービス契約ステータスコード (Service Contract Status Code)
- `l_seiopsvc_kei_stat_*` — 請求オプションサービス契約ステータス (Request Option Service Contract Status)
- `l_seiopsvc_cd_*` — 請求オプションサービスコード (Request Option Service Code)
- `l_mansion_bukken_cd_*` — マンション物件コード (Mansion Property Code)
- `l_ido_ng_stat_cd_*` — 移動NGステータスコード (Movement NG Status Code)
- `l_yk_cfm_rslt_div_*` — 有効性確認結果区分 (Validity Confirmation Result Division)
- `l_svc_kei_no_param_*` — サービス契約番号パラメータ (Service Contract Number Parameter)
- `l_mskm_no_*` — 申請番号 (Application Number)
- `l_plan_chrg_staymd_*` — プラン課金開始年月日 (Plan Charge Start Date)
- `l_checked_sel_*` — チェックボックス選択値 (Checkbox Selection Value)
- `l_manssbsys_rnki_kijiran_*` — マンション設備システム連携用記事欄 (Mansion Facility System Link Item)
- `l_mans_tushin_equip_cd_*` — マンション通信設備コード (Mansion Communication Device Code)
- `l_kojiak_no_*` — 工事案件番号 (Construction Project Number)
- `l_tk_hoshiki_kei_no_*` — 提供方式契約番号 (Provider Formula Contract Number)
- `l_replica_moto_tk_hsk_kei_no_*` — 複製元提供方式契約番号 (Copy Original Provider Formula Contract Number)
- `l_mansion_id_*` — マンションID (Mansion ID)
- `l_catid_*` — カテゴリID (Category ID)
- `l_kaisen_use_kei_type_cd_*` — 回線使用契約タイプコード (Line Usage Contract Type Code)
- `l_mans_naihan_gaihan_cd_*` — 回線内販外販コード (Line Inside/Outside Sales Code)
- `l_mans_naihan_comp_skbt_cd_*` — 回線内販企業識別コード (Line Inside Sales Company ID Code)
- `l_ownr_kei_no_*` — オーナー契約番号 (Owner Contract Number)
- `l_kisnusekei_bkn_state_nm_*` — 回線使用契約物件都道府県名 (Line Usage Contract Property Prefecture Name)
- `l_kisnusekei_bkn_city_nm_*` — 回線使用契約物件市区町村名 (Line Usage Contract Property City/Town/Village Name)
- `l_kisnusekei_bkn_oaztsu_nm_*` — 回線使用契約物件大字通名称 (Line Usage Contract Property Oaza/Zone Name)
- `l_kisnusekei_bkn_azcho_nm_*` — 回線使用契約物件字丁目名 (Line Usage Contract Property Choume/Block Name)
- `l_kisnusekei_bkn_bnchigo_*` — 回線使用契約物件番地名 (Line Usage Contract Property Land Parcel Number)
- `l_mans_sysid_*` — マンションシステムID (Mansion System ID)
- `l_mans_svc_kei_no_*` — マンションお客さまID (Mansion Customer ID)

## Relationships

### Dependency diagram

```mermaid
flowchart LR
    JSP1["KKW055010PJP.jsp"]
    JSP2["KKW055020PJP.jsp"]
    BEAN["KKW05501SF02DBean"]
    IF1["X33VDataTypeBeanInterface"]
    IF2["X33VListedBeanInterface"]
    JAVAX["Serializable"]
    JSP1 --> BEAN
    JSP2 --> BEAN
    BEAN --> IF1
    BEAN --> IF2
    BEAN --> JAVAX
```

### Upstream consumers (2 classes)

- **`KKW055010PJP.jsp`** — The primary JSP view for screen KKW05501. This page creates an instance of `KKW05501SF02DBean` to render the full property/services management form. It reads field values via both the direct getters and the `loadModelData()` key-based dispatch.
- **`KKW055020PJP.jsp`** — A secondary JSP view (likely a detail or related screen) that also instantiates and operates on the same bean type, suggesting the two screens share the same data model for consistency.

### Downstream dependencies

None. `KKW05501SF02DBean` has no outbound references — it does not call any other classes, use no framework libraries, and import no packages beyond the interfaces it implements and `java.util.ArrayList`. It is a pure data container.

### Interface contract

- **`X33VDataTypeBeanInterface`** — The framework expects `typeModelData()` to be implementable. This bean fulfills it by returning `Class<?>` mappings for every field.
- **`X33VListedBeanInterface`** — The framework expects `listKoumokuIds()` to enumerate all fields. This bean fulfills it with the static 56-entry list.

## Usage Example

The JSP layer typically uses the bean in this pattern:

```java
// In the JSP (KKW055010PJP.jsp)
KKW05501SF02DBean bean = new KKW05501SF02DBean();

// Populate via key-based dispatch (framework-driven)
bean.storeModelData("お客さまID", "value", "CUST-00123");
bean.storeModelData("お客さまID", "enable", true);
bean.storeModelData("選択", "value", Boolean.TRUE);

// Read back via key-based dispatch
Object customerNo = bean.loadModelData("お客さまID", "value");
// customerNo == "CUST-00123"

// Read type information
Class<?> type = bean.typeModelData("選択", "value");
// type == Boolean.class

// Enumerate all field keys
ArrayList<String> fields = KKW05501SF02DBean.listKoumokuIds();
// fields[0] == "選択", fields[1] == "お客さまID", ...
```

Alternatively, direct getters/setters can be used:

```java
bean.setL_svc_kei_no_value("CUST-00123");
bean.setL_svc_kei_no_enabled(true);
String val = bean.getL_svc_kei_no_value();
```

## Notes for Developers

### Field count and maintenance

This bean has **56 domain fields**, each with 4 sub-properties (`_value`, `_enabled`, `_state`, `_update`), plus the `index` field — that's **225+ individual properties** in a single class. Adding a new screen field requires:
1. Adding the four `protected` fields.
2. Adding getter/setter pairs (8 methods).
3. Adding the key to `listKoumokuIds()`.
4. Adding three dispatch branches (value/enable/state) to `loadModelData()`, `storeModelData()`, and `typeModelData()`.

This is **highly mechanical but error-prone** — any omission in one of the three dispatch methods will cause runtime failures that are silent at compile time.

### Thread safety

The class is **not thread-safe**. All fields are `protected` mutable members with no synchronization. It is designed for single-thread use per request (typical JSP bean lifecycle: create, populate, pass to JSP, discard). Do not share instances across threads.

### Serializability

The class implements `Serializable` but defines no `serialVersionUID`. This means a `InvalidClassException` will be thrown if the class structure changes and a serialized instance from an older version is deserialized. Consider adding an explicit `private static final long serialVersionUID`.

### The `isSetAsString` flag

The four-parameter `storeModelData()` accepts an `isSetAsString` parameter. The Japanese comment states it controls whether to set a `String` value for `Long`-type field properties. Currently no `Long` fields exist in this bean, making this parameter effectively unused. It may be legacy code from a parent class or planned future use.

### Null handling

- `loadModelData` and `storeModelData` both guard against `null` keys/subkeys: the former returns `null`, the latter returns silently (no-op).
- `typeModelData` also guards against `null` inputs, returning `null`.
- Unrecognized keys across all three methods produce no error — they simply fall through the `if-else` chain without executing any branch. This is a silent failure mode.

### UI state management

The `_state` and `_enabled` properties form a dual-control system: `_enabled` is the boolean editability flag, while `_state` is a free-form string hint (the JSP likely reads it to add CSS classes or attributes). Both are independently settable. The `_update` flag is a string (not boolean), suggesting it may carry richer state (e.g., `"added"`, `"modified"`, `"deleted"`) rather than a simple dirty-flag.

### Framework coupling

This class is tightly coupled to the X33 framework (evidenced by the interface names `X33VDataTypeBeanInterface` and `X33VListedBeanInterface`). The key-based dispatch pattern using Japanese field names suggests the framework uses metadata-driven rendering — the JSP iterates over `listKoumokuIds()` and dispatches through `loadModelData`/`storeModelData`/`typeModelData` to read/write every field without hard-coded references.