注：ここでコーディングのヘルプは必要ありませんProgrammers。理由があります。Javaの（単なる）理解ではなく、プログラムの計画/作成スキルを向上させたい。

ここでこのLARPゲームのスキルに基づいて、任意のカテゴリシステムを持つツリーを作成する方法を見つけようとしています。私の以前の試みは、スキルがカテゴリーでもあったかどうかについては愚かでした。それをコーディングしようとするのは面倒でした。自分のツリーを描くと、自分の「葉」だけがスキルであることに気付き、他のカテゴリにはカテゴリとしてラベルを付けました。

私が望んでいるのは、モデルとビューを分離しようとするツリーを作成し、任意の親に任意のタイプの子ノードを（編集/レンダリングの別の方法で）追加できるようにする方法です。

NBここにあるものはすべて、財産のように思える場合でも、スキルとして購入されます。エンドユーザーは、これを購買スキル（紙のATMで行う）と見なすため、同じページにすべて表示する必要があります。

ツリーの説明：ツリーは、ハードコードされた最高レベルのカテゴリ（武器、物理的および精神的、医療など）のセットで「生まれ」ます。このことから、ユーザーはスキルを追加できる必要があります。最終的に、彼らは「片手剣専門化」スキル（アイテムではない）を追加したいと考えています。そのためにはWeapons、選択One-handedした状態で「追加」をクリックし、その子に表示されるコンボボックスノードから選択し、もう一度追加をクリックして、表示されるその子ノードのテキストフィールドに名前を入力します。次に、もう一度追加をクリックして、そのリーフの「レベル」または「ティア」を追加/指定します。最初に習熟し、次に専門化（例えば）。

もちろん、別のスキルを購入する場合は、リーフへの完全に異なるルートです。武器の例で行ったように、ツリーの同じレベルにコンボボックスは必要なく、その背後にある他のロジックも必要になる場合があります。これは、プログラミングは言うまでもなく、頭を悩ませている問題です。一連のクラスを作成し、それらをどの順序でアタッチするかを指定せずに、すべてを適合させる方法。

この種のツリーをコードで記述するのに適したシステムは何ですか？私が見た他のすべてのJTreeの例には、予測可能なパターンがありますが、私の場合はそうではありません。これをすべて「リテラル」でコーディングする必要はありません。どのタイプ（コンボボックス、テキストフィールドなど）の子ノードの長いリストをどの親で許可する必要があります。抽象クラスを使用する必要がありますか？インターフェース？

上にリストされていない、異なる動作をする他のスキルを追加するときに、この種のオブジェクトのクラスターを拡張可能にするにはどうすればよいですか

使用する適切なシステムがない場合、この種のことを行う方法を決定するための適切なプロセスはありますか？

私の頭の中の歯車が回っています：

私はいつもする必要があります：

• 親を確認する
• 親に基づいてオプションを提供する

私はこの共通性のskillために、スキルとカテゴリの一般的なメソッドを定義/概説する何らかの抽象/インターフェイスクラスが必要だと考え始めています。（できれば）ルールとオプションをデータベースに入れて、そこから読み込めます。問題は、抽象メソッドまたはインターフェイスメソッドと、それを実装する方法との間の問題です。

単純な可変JTreeの例

コード（上記のイメージを作成するためにJava 7でコンパイルおよびテストされています）：

import java.awt.*;
import javax.swing.*;
import javax.swing.tree.*;

public class SimpleTree extends JFrame {
    public static void main(String[] args) {
        new SimpleTree();
    }

    public SimpleTree() {
        super("Mutable Varied JTree");
        Container content = getContentPane();
        N root = new N("Root");

        N weapons = new N("Weapons").add(
            new N("One-handed").add(
                new N("Sword").add("Proficiency", "Specialization"), 
                new N("Mace").add("Proficiency")),
            new N("Bow").add("Proficiency"));
        root.add(weapons);

        N phys = new N("Physical & Mental").add(
            new N("Life"),
            new N("Strength").add(
                "Double", "Triple", "Quadruple"));

        root.add(phys);
        N med = new N("Medical");
        med.add(new N("Bind Wounds"));
        med.add(new N("Set Broken Bones"));
        root.add(med);

        JTree tree = new JTree(root);
        content.add(new JScrollPane(tree), BorderLayout.CENTER);
        setSize(275, 300);
        setVisible(true);
    }

    private class N extends DefaultMutableTreeNode {
        public N(String s) { super(s); }
        public N add(String... strs) {
            for (String s : strs) {
                super.add(new N(s));
            }
            return this;
        }
        public N add(N... ns) {
            for (N n : ns) {
                super.add(n);
            }
            return this;
        }
    }
}

このJTreeチュートリアルへの特別な感謝

更新：可能な解決策の議論

動的ツリーの作成に関するチュートリアルがありますフレームの下部にあるボタンを使用してノードを追加/削除/クリアます。

コンボボックスなどの場合、適切なスイングクラスのオブジェクトを取得し、java.swing.tree.MutableTreeNodeを実装するJComboBoxのようなオブジェクトにする必要があります。Java Swingチュートリアルには、コントロールのリストがあります。

ユーザーが追加したいノードの種類を選択したり、ノードを編集したりできるようにするには、ユーザーインターフェイス要素を作成する必要があります。コンボボックスを追加する場合、ボックスで使用できる選択肢を定義できる必要があります。

データを保存するには、基礎となるデータモデルが必要です。すべてのJavaオブジェクトに組み込まれているデフォルトのシリアル化スキームを使用できますが、これはプロトタイピング専用です。プログラムコードを変更すると破損します。JDBCまたはJPAでデータベースを使用するか、JSONやXMLなどをストレージ形式として使用して、独自のシリアル化ルーチンを作成する（またはシリアル化を処理するライブラリを使用する）必要があります。

更新：プロジェクト概要で提案されたソリューション

最も簡単な解決策は、データベースを忘れて、最初にデータのXML式を考え出し、次にXMLファイルを編集し、特別なコンボボックスなどのないJTreeとして結果を表示することです。これが、チブゼ・オパタが彼の答えで示唆していたことだと思います。このツリーの部分的なXML表現は次のようになります。

<folder name="Physical &amp; Mental">
    <int name="Life">12</int>
    <drop-down name="Strength">
        <option name="Single" />
        <option name="Double" />
        <option name="Triple" />
        <option name="Quadruple" />
    </drop-down>
</folder>
<folder name="Medical">
    <text name="Bind Wounds" />
    <text name="Set Broken Bones" />
</folder>

潜在的なマイルストーンは次のとおりです。

• XMLまたはJSONデータ形式を作成し、その形式のファイルを読み取り、コンボボックスなしでフォルダーとファイルのみを含むJTreeとして表示するプログラムを作成します。
• JTreeディスプレイにスイングコントロールを追加する
• プログラムを展開して同じファイルを作成します
• ユーザーがGUIを使用してノードを追加および編集できるように、ユーザーインターフェイスを作成します。

各マイルストーンの終わりにプログラムが機能するたびに、必ずプログラムのバックアップを保存してください。これには、別のマシンにインストールされたソース管理システムが理想的です。コードの共有を気にせず、ソース管理を備えたサーバーをセットアップしたくない場合は、github、sourceforge、またはその他のパブリックソース管理を使用できます。

これらのソリューションはいずれも多くの作業であり、初心者プロジェクトよりも確実に大きくなります。LARPをプレイするよりもJava SwingとXMLまたはJSONの学習に多くの時間を費やすことになることを意味します。そのため、最初に既存のツールで対処するオプションを検討しました。しかし、何でも学ぶための最良の方法は、あなたが学ぶ意欲が最も高い方法です。したがって、これはあなたにとって完璧なプロジェクトかもしれません。

それがお役に立てば幸いです。

JTreeはあなたが解決しようとしている問題の正しい表現だとは思いません。私はあなたのウェブサイトを見ました、そして私はもののリストを見ます。これは素晴らしいスタートですが、基礎となるデータ設計があるかもしれないと思いますが、私は見ていません。

人生と強さは、私にとってキャラクターの属性のように見えます。Double、Triple、およびQuadrupleは、Strength属性の値のように見えます。それから、武器と医療に分けられたスキルを見ます。武器は所有物（購入、発見、またはドロップできるもの）であると考えており、特定の武器でスキルを発揮できるのはスキルだと思います。しかし、私がそれを見る方法、武器や薬にはスキルがありません、キャラクターにはあります。実際、キャラクターはデータ設計の中心人物であると強く疑っています。

これまでの設計で際立っていた3つのデータオブジェクトを次に示します。

Character:
    Life (a value: e.g. 12)
    Strength (a value: e.g. double, triple, quadruple)
    Skills (list or set of weapon-skills, healing-skills)
    Possessions (list of weapons, armor and other possessions)
    WornArmor (maybe only wear one you possess at a time?)
    WieldedWeapon (one or two of your posessions)

Skill:
    Skill-Type (healing, manufacture, or weapon)
    RelevantWeapon (for this skill)

Weapon:
    IsOneHanded (boolean)
    IsBow (boolean)

キャラクターは武器とスキルを持つことができますが、本当に良い攻撃をするには、使用している武器に固有のスキルが必要です。いずれにせよ、ここには1対多の関係があります（1人のキャラクターは多くのスキルを持つことができます）。しかし、私はまだ木を見ていません。

紙のパッドを取り、最初のページでキャラクターをページの中央に置き、その周りの5〜10個の最も重要なゲームワールドオブジェクトをリストします。ツリーやテキストフィールド、コンボボックスを考えずに、単にデータが別のオブジェクトの属性（キャラクターの分離不可能な部分であるLifeとStrengthなど）であり、オブジェクト間の最も重要な関係が何かを把握します。オブジェクト間に線を引いて関係を表現します。次に、どの関係が1：1で、1：多で、多く：多であるかを判断し、それらにラベルを付けます。「has-a」や「is-a」などの関係もあります。

WeaponSkill vs. HealingSkill vs. ManufactureSkillに別々の表現が必要であると決めるかもしれません。または、それらが非常に似ていると判断して、スキルのタイプを決定するフィールドを持つ1つのスキルテーブル（上記の例では）に属するようにすることもできます。

これまでの試みに満足していないことを示す良い兆候です。それは、1つを選ぶ前に多くの可能性を検討する意思があることを意味します。検討するスケッチが多いほど、最終的なデザインは良くなります。最終的には、最良のものがデータ図になります。それがかなりうまく落ち着いたら、「コンボボックス」または「テキストフィールド」について考えることに戻ることができますが、UIの決定は最後に任せます。

JTreeを見るのではなく、データ構造、データベース設計、そしておそらくデータモデリングのトピックを調べることをお勧めします。 EDIT->または、David Kaczynskiが提案したエンティティリレーションシップマッピング図！<-EDIT データの設計が正しい場合、JavaとUIはそこから明らかに自然に流れます。しかし、あなたがそれを間違えた場合、Java-kung-fuやUI-beautyがそれを修正することはありません。

幸運を！

オブジェクトモデルに焦点を当てます。

あなたが望む柔軟性のために、おそらくあなたのクラスを知識（おそらくこの場合「定義」がより良い言葉である）層とトランザクション層に分離したいと思うでしょう。「レイヤー」とは、あなたの頭の中で論理的に分離することを意味します。ナレッジレイヤーにはツリーのレイアウト方法の定義が含まれ、そのデータはゲームデザイナーから取得され、データレイヤーは特定のキャラクターの特定の選択肢を格納します。

数学的にクリーンなモデルではなく、クールなゲームを作成しようとしているため、知識レベルは少なくとも少し面倒です。

あなたがこれまでに持っているものを整理しようとすると、SkillDefinitionクラスにはSkillDefinition型のParentプロパティがあると思います。また、いくつかのケースをカバーするために、SkillDefinitionのサブクラス（データベースのDEF_SkillTypeテーブルのエントリになる場合があります）もあります。

「武器」、「物理的および精神的」、および「医療」には、タイトル（および子供のスキル）しかありません。

「One Handed」、「Strength」、および「Bind Wounds」には、コンボボックス（DEF_Skillへの外部キーを持つデータベース上のDEF_SkillChoiceテーブルのようなもの）が関連付けられているようです。Sword and Bowはユーザー定義の文字列のようです（したがって、知識レベルでは関連付けられたテーブルはありませんが、データはトランザクションレイヤーに格納されます）。

「Life」には整数が関連付けられているようです。整数の増分方法には暗黙の動作があるため、整数を使用する将来の特性とこのクラスを共有できない場合があります。いずれにせよ、現在は独自のクラスが必要です。

「剣」、「弓」、「強さ」、「バインドの傷」はすべて、ツリー内の下位レベルに関連する進歩的なスキルのレベルを持っているようです。「剣」と「弓」の場合、これらのレベルは実際に親のスキルに関連付けられています。有効な値の順序付きコレクション（DEF_Skillへの外部キーを持つDEF_SkillLevelテーブル。知識レベルでは、モデリングしているルールが完全に明確ではありません。すべての武器について、「武器」レコードへの外部キーを持つ「習熟度」および「専門化」レコードを持つDEF_SkillLevelテーブルがあります。

これは知識レベルで知っていることをカバーしています。トランザクションレベル（おそらく「キャラクターレベル」のほうが適切な名前でしょうか？）は、適切な知識レベルを指しているだけです。したがって、あなたの例では、スキルのコレクションを持つスキルオブジェクトを持つキャラクターオブジェクトがあります-彼が実際に持っているものだけです。

そのため、キャラクターは「親」が「剣」スキルであり、タイプがSkill_Levelである「技能」スキルを持ちます。データベースでは、TRANS_SkillDefinitionレコードには、トランザクション「剣」スキルレコードと「Proficiency」という名前の知識レベルDEF_SkillLevelレコードへの外部キーがあります。

技能スキルには、Skill_UserNamedタイプの「剣」スキルの親オブジェクトがあります。データベースでは、「剣」（ユーザーの名前）に特別なものは何も定義されていないため、知識レベルへの外部キーはありません。ただし、親トランザクションレコードへの外部キーもあるため、より多くの情報を利用できます。

「剣」スキルオブジェクトの親オブジェクトは「片手」です。これは、ユーザーが「片手」カテゴリに「剣」を入れることを選択したためです。これはタイプSkillCategoryのオブジェクトです。データベースには、レコード「片手」のDEF_SkillChoiceテーブルへの外部キーがあり、このスキルのすべての追加データは知識レベルで保存されるため、トランザクションの親はありません。

新しいキャラクターの初期ツリーを構築する際には、知識レベルのみを照会する必要があります。キャラクターに対して行われた選択を入力するには、トランザクションレベルが必要です。

オブジェクトモデルをツリーに変換して戻すには、コードが必要です。明確にする必要があります。あなたがする必要があること-知識層の各タイプには、そのタイプに適したデータを取得する関連するコントロールセットがツリー上にあります。

後でSkillCategoryレコードの各選択肢にクラスが必要になる場合があります（「Specialization」に動作が関連付けられている場合、コードはどこかに行かなければなりません）が、このツリーにはまだ必要ありません。それと。知識レベルの情報を使用して適切なオブジェクトを構築するファクトリが必要になります。

結局のところ、プログラムのクラス階層であろうと、「内部世界」（GUI、DB接続、データバインドビジネスロジックなど）に接続するさまざまなモジュールから構築されたプログラム自体であろうと、常に階層構造の管理に終わります。 。しかし、これは哲学です。あなたの場合、どのように機能するのでしょうか？

このツリーにはノードがあり、各アイテムは「オブジェクトインスタンス」です。一方、それらの動作（配置できる場所、許可された子ノードのリストなど）は、「クラス」などの一部のセットで一般的です。はい、これはプログラムコードのようなものです。Javaのリフレクションについて十分に理解している場合は、POJOクラスと継承階層を使用して、IoCコンテナまたはファクトリメカニズムを使用して実際のインスタンスを構築し、このコンポーネントを構築することもできます。しかし、あなたはそれを望んでいないと思います、なぜならそれは重い言語のハッキングなので、...

最初に、アイテムの動作を記述する「クラス」オブジェクトを作成します。クラス識別子、「フィールド」名、許可されるタイプとアイテムの数などが含まれます。例：「ルート」クラスは「プレーヤーのプロパティ」で、「物理/精神」、「医療」、「武器」フィールドがあります。このタイプは「最終」です。現時点では、異なるプレーヤータイプは必要ありません。ヒント：後で、同じツールを使用して「人間以外のモンスター」を処理できます... :-)

「医療」フィールドは

• 「シングルトン」：プレーヤーは複数の「医療」情報を持つことはできません
• 子タイプは固定されており、ここでは「Medical」タイプのオブジェクトのみを使用できます
• 必須：プレーヤーを作成するときは、「医療」フィールドが必要です

反対：武器メンバーは必須ではありません。最初の武器がプレイヤーに追加されたときに作成する必要があります。つまり、「オブジェクト」（現在のプレーヤー）を「編集」し、新しいアイテムの追加を許可する場合、インスタンスの実際のプロパティ（現在は「武器」を含まない） "）、ただしクラス定義のすべてのフィールドを表示し、初めて使用するときに新しいフィールド（子ノード）を遅延作成します。これにより、拡張可能な環境が作成されます。後で、複数のプレーヤー... er ...参照を含む「フレンド」フィールドを追加できます（後述）。

プロセスを実際の「クラス」に従ってください。武器の種類（剣、短剣、弓など）を分離し、何らかの方法で弾薬を処理する方がよいようです（おそらくプレイヤーは弓を持っていないが、矢を集めることができるが、特定の武器は弾薬を必要とし、減少させます、それらのいくつかは見つけることができます、他のものは失われます...）「武器」クラスの下で：それは調査するのが簡単であり、またあなたのプレイヤーがそのアイテムのみを運ぶか、それを使用できるかを示します（スキルを持っています）。一方、ゲームを開発するときに、この構造を後で変更することは確かです。

ゲームの開始時に初期化するグローバルに利用可能な「クラスストア」を作成し、誰かが名前を参照したときにクラス定義を提供します。この場合、クラスdefオブジェクトは不変でなければなりません。

「オブジェクト」は簡単です。それらは、クラス定義への参照とフィールドへの汎用アクセスを含む同じルートクラスから派生できます。おそらくHashMapを使用して、フィールド名で識別されるそれらの子を含めることができます。覚えておいてください。これらのフィールドには、単一のオブジェクトが含まれているものと、オブジェクトのセットが含まれているものがあります。これらのインスタンスはもちろん変更可能です。

インターフェースについて説明します。まず、JTreeチュートリアルを確認する必要があります...必要があります。各「オブジェクト」はDefaultMutableTreeNodeで表すことができ、ノードの「userObject」はオブジェクトでなければなりません（そのノードのtoString（）はノードのラベルとして表示されますが、カスタムセルフォーマッタを作成できます）。ノードを開くたびに、オブジェクトのフィールドを参照し、親の下に子ノードを作成します（動的に実行する場合）-JTreeを表示するときにツリー全体を参照してTreeNode構造を構築します（ヒント： TreeNodeパラメーターを持つJTreeコンストラクターです）。

ツリーでノードを選択すると、Objectインスタンスが得られます。クラスごとに、適切なエディターパネル、またはクラス定義によって生成された一般的なものを表示できます（フィールドのあるタブパネル、フィールド宣言による実際のフィールドのエディター：適切なタイプの子を作成するボタンofでは、使用可能なクラスの1つを選択できます;武器のプロパティなど、そのインスタンスのエディターフィールド）。構造を変更した後、ツリー自体を更新する必要があります-TreeModelとそのfire ... change関数は友達です。

いい感じ？または複雑すぎますか？まあ、これは話のほんの一部です。私は話していません

• クラス定義階層/または分類。同じフィールドへの異なるクラスの追加（異なる種類の剣など）をサポートする場合、それらのいずれかを使用する方が適切です。カテゴリ化の長所：クラスには複数のカテゴリがあり、固定の継承ツリーではなく、スキルの向上にXPを費やしたときにプレイヤーの「すべてのスキル」を収集したい場合に適しています... :-)
• 永続性のサポート：プロパティやJSONファイルなどのように、オブジェクト階層を外部に保存する汎用ソリューションを作成する必要があります。脳を良好な状態に保ちたい場合は、人間が読める形式を使用し、バイナリシリアル化は使用しないでください。
• インスタンスストレージ：ゲームの「世界」を1か所に保管する方が良いことにすぐに気付くでしょう。特定の剣はプレイヤーのプロパティではなく、ゲーム内の世界のエンティティです（プレイヤーはそれを失う可能性があり、誰かが見つけることができるなど）。したがって、ツリー内のこれらの「オブジェクト」の多くは実際にエンティティの参照（一方、プレーヤーの健康状態などは、実際には属性のみです）。2つのタイプを分離し、参照を解決できるインスタンス用のグローバルストレージを用意する必要があります。これにより、ゲームの状態をシリアル化するときにも節約でき、複数のエンティティが同じ他のエンティティを参照します（同じ寺院への複数のプレイヤーの「場所」など）。
• （そして、本当の脳研ぎ器に言及する：クラスストレージとインスタンスストレージの類似性;型宣言は、プログラムコンポーネント、アクティブウィンドウ、ユーザーセッションなどと同じ方法でオブジェクトインスタンス自体になることができるという事実。これは土地です。私のようなマニアの

とにかく、このウォームアップセッションの何かを使用できることを願っています。

長い答えはしませんが、以前はこのような状況に直面していましたが、率直に言って、既存のデータ構造を使用することをあきらめました。XMLノードに似た新しい親と子を受け入れることができる独自のオブジェクトを作成しました。

ただし、あなたの場合、Xmlクラスを使用すると役立つと思います。その後、クラスがスキルかどうかを示すことができる各ノードのプロパティを設定し、コンボボックスなどで使用するノードの親と子を簡単に取得できます。

また、テキスト/文字列がたくさんあるという考えから逃げるべきではないことを付け加えたいと思います。ゲームには通常AIが関係し、AIには通常多くのテキストが関係します。