Зверніть увагу: я не хочу тут довідки з кодування, я знаходжуся з Programmersпричини. Я хочу вдосконалити свої навички планування / написання програми, а не (лише) розуміння Java .

Я намагаюся зрозуміти, як зробити дерево, яке має довільну систему категорій, виходячи з навичок, перелічених для цієї гри LARP тут . У моїй попередній спробі було зрозуміло, чи є вміння також категорією. Спроба зашифрувати це було безладно. Намалювавши своє дерево, я помітив, що лише мої «листя» - це навички, і я позначив інших категоріями.

Мені слідкувати - це спосіб створити дерево, яке намагається відокремити модель і перегляд, і додати довільний тип дочірнього вузла (з окремим способом редагування / надання) до довільного батьків.

NB Тут все купується як навик, навіть там, де це здається властивістю. Кінцеві користувачі сприйматимуть це як навички купівлі (що вони роблять на паперовому атмісі), тому вони повинні бути представлені як такі, все на одній сторінці.

Пояснення дерева: Дерево "народжується" з набором жорстко кодованих категорій найвищого рівня ( Зброя, Фізична та Психічна, Медична тощо). Від цього користувачеві потрібно мати можливість додати навичку. Зрештою, вони хочуть додати, наприклад, навичку "Спеціалізація мечів однією рукою" ( не предмет). Для цього слід в ідеалі натиснути «додати» із 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

Оновлення: обговорення можливих рішень

Є підручник із створення динамічного дерева , використовуючи кнопки в нижній частині кадру, щоб додати / Видалити / Очистити вузли.

Для комбінованих коробок та іншого ви хочете взяти об’єкти відповідного класу гойдалок, щоб вони були чимось на зразок JComboBox, який реалізує java.swing.tree.MutableTreeNode. У навчальному посібнику Java Swing є список елементів керування .

Вам все-таки потрібно створити елемент інтерфейсу користувача, щоб люди могли вибрати, який тип вузла вони хочуть додати, та редагувати вузол. Якщо вони додадуть комбіновану скриньку, вони повинні мати змогу визначити, які варіанти вікна зробить доступним.

Для збереження даних вам потрібна основна модель даних. Ви можете використовувати схему серіалізації за замовчуванням, вбудовану у всі об’єкти Java, але вона призначена лише для прототипування - вона порушиться, якщо ви коли-небудь змінити код програми. Вам потрібно буде або використовувати базу даних або з JDBC, або з JPA, або вам потрібно буде написати власні процедури серіалізації (або використовувати бібліотеку, яка обробляє серіалізацію для вас), використовуючи щось як JSON або XML як формат зберігання.

Оновлення: пропоноване рішення з оглядом проекту

Найпростішим рішенням може бути забуття про бази даних та спочатку придумати XML-вираз даних, а потім відредагувати XML-файл і просто відобразити результати у вигляді JTree без спеціальних комбо-скринь або нічого іншого. Я думаю, що саме це запропонував Chibueze Opata у своїй відповіді. Часткове представлення 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 без будь-яких комбінованих коробок, лише папок та файлів.
• Додайте елементи управління swing на дисплей JTree
• Розгорніть програму, щоб написати той самий файл
• Створіть інтерфейс користувача, щоб користувач міг додавати та редагувати вузли за допомогою GUI

Не забудьте зберегти резервну копію програми щоразу, коли вона працює в кінці кожного етапу. Для цього ідеально підійде система управління джерелами, встановлена ​​на іншій машині. Ви можете використовувати github, sourceforge або інший публічний контроль над джерелами, якщо ви не проти поділитися кодом і не хочете налаштувати сервер із контролем джерела на ньому.

Будь-яке з цих рішень - це багато роботи, і, безумовно, більше, ніж проект для початківців. Це означає, що ви будете витрачати набагато більше часу на вивчення Java Swing та XML або JSON, ніж на гру свого LARP, тому я вперше вивчив варіанти створення дій із наявними інструментами. Але найкращий спосіб навчитися чомусь - це спосіб, до якого ти найбільше мотивований. Тож це може бути ідеальним проектом для вас.

Я сподіваюся, що це допомагає.

Я не думаю, що JTree - це правильне представлення проблеми, яку ви намагаєтеся вирішити. Я переглянув ваш веб-сайт і бачу списки речей. Це чудовий початок, але я думаю, що у вас може бути базовий дизайн даних, але я не бачу.

Життя і Сила виглядають як атрибути характеру для мене. Подвійні, потрійні та чотиримісні виглядають як значення для атрибуту Strength. Потім я бачу навички, поділені на Збройна та Медична. Я вважаю зброю як власність (яку можна придбати, знайти або відкинути), і я припускаю, що майстерність - це те, що дозволяє вам бути ефективними з даною зброєю. Але те, як я на це дивлюся, зброя та медицина не мають навичок, характер. Насправді я сильно підозрюю, що Персонаж є центральною фігурою у вашому дизайні даних.

Ось три об’єкти даних, які мені виділяються з вашого дизайну:

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)

Тепер персонаж може мати зброю та навички, але для дійсно доброї атаки їм потрібна навичка, специфічна для зброї, яку вони використовують. У будь-якому випадку тут є стосунки один до багатьох (один персонаж може мати багато навичок). Але я ще не бачу дерев.

Візьміть килимок з паперу і на першій сторінці поставте персонажа на середину сторінки та перерахуйте навколо нього 5–10 найважливіших об’єктів світу ігор. З’ясуйте, які дані є лише атрибутом іншого об’єкта (наприклад, що Життя та Сила є невіддільними частинами персонажа) та які найважливіші стосунки між об'єктами, не замислюючись про дерева, текстові поля чи комбо-поля. Накресліть лінії між об’єктами, щоб зобразити відносини. Тоді з’ясуйте, які стосунки 1: 1, які - 1: багато, а які - багато: багато та позначте їх. Можуть існувати відносини "має-є" і "є-є" та інші види.

Ви можете вирішити, що вам потрібні окремі представлення для WeaponSkill vs. HealingSkill vs. ManufactureSkill. Або ви можете вирішити, що вони настільки схожі, що вони належать до однієї таблиці вмінь (у моєму прикладі вище) із полем, яке визначає, для якого типу навичок це.

Це хороший знак того, що ви не задоволені своїми спробами поки що - це означає, що ви готові розглянути багато можливостей, перш ніж вибрати одну. Чим більше ескізів ви вважаєте, тим кращим буде ваш остаточний дизайн. Врешті-решт найкращим стане Ваша діаграма даних. Коли це досить добре вирішено, ви можете повернутися до роздумів про "комбо-поля" або "текстові поля", але я б залишив рішення інтерфейсу до кінця.

Замість того, щоб подивитися на JTrees, я б запропонував вам вивчити теми структур даних, дизайну баз даних та, можливо, моделювання даних. EDIT-> Або ще краще діаграми відображення взаємозв'язків між сутністю, як запропонував Девід Качинський! <-EDIT Якщо ви правильно зрозуміли дизайн даних, то Java та інтерфейс користувача будуть випливати з нього очевидно і природно. Але якщо ви помилитесь, то жодна кількість Java-кунг-фу чи UI-beauty не виправить це.

Удачі!

Я збираюся зосередитись на об'єктній моделі.

Я думаю, що для потрібної вам гнучкості ви, мабуть, хочете розділити свої класи на рівень знань (можливо, «визначення» - краще слово в даному випадку) і рівень транзакції. Під «шаром» я дійсно маю на увазі розділення їх логічно в голові. Шар знань містить ваше визначення того, як викласти дерево, а дані в ньому надходять від конструктора ігор, і рівень даних зберігає певний вибір для конкретного персонажа.

Ваш рівень знань буде хоча б трохи безладним, адже ви намагаєтеся зробити круту гру, а не математично чисту модель.

Намагаючись організувати те, що у вас є, досі, я думаю, що у вас клас SkillDefinition має батьківське властивість типу SkillDefinition. У вас також є підкласи SkillDefinition (які можуть стати записами в таблиці DEF_SkillType в базі даних), щоб охопити кілька випадків.

"Зброя", "Фізична та психічна" та "Медична", схоже, не мають нічого, крім назви (та навичок дитини).

"Одноручні", "Сила" та "Зав'язують рани", схоже, мають пов'язане поле для комбінації (що означає щось на зразок таблиці DEF_SkillChoice в базі даних із зовнішнім ключем до DEF_Skill). Sword and Bow, здається, є визначеною користувачем рядком (тому жодна пов'язана таблиця на рівні знань, але дані зберігатимуться на рівні транзакції).

Здається, "Life" має ціле число, пов'язане з ним. Можливо, він не зможе поділити цей клас з будь-якими майбутніми характеристиками, які використовують ціле число, оскільки мається на увазі поведінка щодо збільшення цілого числа. У будь-якому випадку, йому зараз потрібен власний клас.

"Меч", "Лук", "Сила" та "Зав'яжіть рани", схоже, мають пов'язані рівні прогресивної майстерності під ними на дереві. У випадку з "Мечем" та "Луком" ці рівні справді пов'язані з навичками батьків. Я думаю, що вам потрібен клас ProgressiveSkillDefinition з упорядкованою колекцією правових значень (таблиця DEF_SkillLevel із зовнішнім ключем до DEF_Skill. На рівні знань не зовсім зрозуміло, які правила ви моделюєте. Якщо завжди знаходяться "майстерність" та "спеціалізація". для всіх видів зброї у вас може бути таблиця DEF_SkillLevel із записами "кваліфікація" та "спеціалізація" із зовнішніми ключами до запису "зброя".

Це охоплює те, що ви знаєте на рівні знань. Рівень транзакцій (можливо, "рівень символів" було б кращим ім'ям?) Просто вказує на відповідний рівень знань. Отже, у вашому прикладі ви мали б об’єкт «Характер» з об’єктом «Навички», який має набір навичок - лише тих, які він насправді має.

Отже, персонаж мав би навичку "майстерність", батьком якої є навичка "меч", а тип якого - Skill_Level. У базі даних запис TRANS_SkillDefinition має зовнішній ключ до транзакційного запису навичок "меч" та запис рівня знань DEF_SkillLevel з назвою "Професійність".

Навик майстерності матиме батьківський об'єкт вміння "меч" типу Skill_UserNamed. У базі даних це не буде зовнішнім ключем до рівня знань, тому що для "меч" немає нічого особливого (це ім'я користувача). Однак він також має зовнішній ключ до батьківського запису транзакцій, тому більше інформації доступно через нього.

Об'єкт вміння "меч" має батьківський об'єкт "однією рукою", оскільки користувач вирішив поставити "меч" у категорію "одні руки". Це об’єкт типу SkillCategory. У базі даних він має зовнішній ключ до таблиці DEF_SkillChoice для запису "однією рукою", і жоден батько транзакцій, оскільки всі додаткові дані для цього вміння зберігаються на рівні знань.

При побудові початкового дерева для нового персонажа потрібно запитувати лише рівень знань. Для заповнення вибору, зробленого для персонажа, потрібен трансакційний рівень.

Вам знадобиться код для перекладу об'єктної моделі на дерево та назад. Маю бути зрозумілим, я сподіваюся, що вам потрібно зробити - кожен тип на рівні знань матиме відповідний набір елементів управління на дереві, який отримує дані, відповідні цьому типу.

Пізніше ви можете захотіти заняття для кожного вибору в записах SkillCategory (якщо "Спеціалізація" пов'язана з нею поведінкою, код повинен кудись піти), але для цього дерева вам це ще не потрібно, і ця конструкція буде сумісною З цим. Вам просто доведеться мати фабрику, яка використовує інформацію про рівень знань для побудови потрібного об’єкта.

Зрештою, ми завжди закінчуємось керуванням ієрархічними структурами - будь то ієрархія класів програми, або сама програма, побудована з різних модулів, що з'єднують вас із «внутрішнім світом» (GUI, з'єднання БД, бізнес-логіка, пов'язана з даними тощо). . Але це філософія, як вона повинна працювати у вашому випадку?

У вас є вузли в цьому дереві, кожен елемент - це "екземпляр об'єкта"; тоді як їх поведінка (куди ви можете розмістити їх, список дозволених дочірніх вузлів тощо) є загальним для деяких наборів, як-от "класи". Так, це подібно до програмного коду. Якщо ви досить добре знаєте відображення Java, ви можете навіть використовувати класи POJO та ієрархію успадкування для створення цього компонента, використовуючи контейнер IoC або фабричний механізм для створення фактичних екземплярів. Але я думаю, ви цього не хочете, тому що це зловживання важка мова, тому ...

Спочатку створіть об’єкт "класу", який описуватиме поведінку елементів. Він містить ідентифікатор класу, назви "полів" та дозволені типи та кількість елементів тощо. Приклад: клас "root" - це "Властивості гравця", поля "Physical / Mental", "Medical", "Weapons". Цей тип "остаточний": зараз ви не хочете мати різні типи гравців. Підказка: згодом ви можете це зробити, використовуючи ті самі інструменти для обробки "чужих чудовиськ" ... :-)

«Медичне» поле - це

• "одиночний": гравець не може мати кілька "медичних" даних
• дочірній тип фіксований, тут може використовуватися лише об’єкт типу "Медичний"
• обов'язково: коли ви створюєте гравця, він повинен мати поле "Медичне"

Навпаки: учасник зброї не потрібен, він повинен бути створений, коли до гравця додається перша зброя. Це означає: коли ви "редагуєте" свій "об'єкт" (тепер програвач) і хочете дозволити додавання до нього нового елемента, не слід обмежувати вибір фактичними властивостями екземпляра (який зараз не містить "Зброя" "), але покажіть усі поля визначення класу та лінько створіть нове поле (дочірній вузол) при першому використанні. Це створить розширювальне середовище. Пізніше ви можете додати поле "Друзі" з кількома посиланнями на програвач ... е ... посилання (див. Пізніше).

Слідкуйте за процесом із власне "класами". Це допоможе вам вдосконалити свої ідеї, як-от: здається, краще розділити види зброї (мечі, кинджали, луки, ...), якось поводитися з патронами (знаючи, що, можливо, у гравця НЕ є лук, але він може збирати стріли, але використовуючи для певної зброї потрібні боєприпаси та декремент, деякі з них можна знайти, інші втратити ...) під класом "Зброя": простіше обстеження, а також показати, чи гравець несе лише цей предмет чи може також ним користуватися ( має навички). З іншого боку: ви неодмінно згодом будете змінювати цю структуру, розвиваючи свою гру.

Створіть глобально доступний "клас магазину", який ви ініціалізуєте, коли ваша гра починається, і обслуговуйте визначення класів, коли хтось посилається на своє ім'я. У цьому випадку об’єкти класу def повинні бути незмінними.

"Об'єкти" простіші: вони можуть бути отримані з того самого кореневого класу, який містить посилання на визначення класу та загальний доступ до полів. Можливо, використовуйте HashMap, щоб містити цих дітей, ідентифікованих за назвою поля. Пам'ятайте: деякі з цих полів містять один об'єкт, інші - набір об'єктів. Звичайно, ці випадки є змінними.

Тепер про інтерфейс. По-перше, ви повинні перевірити підручник JTree ... , і тепер це має бути очевидним. Кожен "об'єкт" може бути представлений DefaultMutableTreeNode, "userObject" вузла має бути вашим об'єктом (я думаю, що toString () цього вузла відображається як мітка вузла, але ви можете створити власний форматник комірок). Щоразу, коли ви відкриваєте вузол, ви переглядаєте поля об’єкта та створюєте дочірні вузли під батьківським (якщо ви хочете це робити динамічно) - або переглядаєте все дерево та будуєте структуру TreeNode під час відображення JTree (підказка: там - конвектор JTree з параметром TreeNode).

Коли ви вибираєте вузол у дереві, у вас є екземпляр Object. За його класом ви можете відобразити належну панель редактора або загальну, породжену визначенням класу (наприклад: панелі вкладок із полями, редактори фактичного поля за допомогою декларації поля: кнопка, яка створює дочір належного типу дозволяє вибрати один із доступних класів і поля редактора для цього примірника, наприклад властивості зброї). Після зміни структури ви повинні оновити саме дерево - TreeModel та його пожежу ... змінити функції - ваші друзі.

Виглядає добре? Або занадто складний? Ну, це невелика частка історії. Я не говорив про це

• ієрархія / класифікація визначення класу. Ви краще скористайтеся одним із них, коли ви будете підтримувати додавання різних класів до одного поля (наприклад, різних видів мечів). Професіонал для категоризації: клас може мати кілька категорій, а не фіксоване дерево спадкування, хороший матеріал, коли ви хочете зібрати "всі навички" гравця, витрачаючи XP на вдосконалення навичок ... :-)
• підтримка наполегливості: вам потрібно створити загальне рішення для зберігання ієрархії об'єктів зовні, як у файлах властивостей або JSON. Використовуйте читаний для людини формат, НЕ бінарної серіалізації, якщо ви хочете підтримувати свій мозок у хорошій формі.
• примірник пам’яті: незабаром ви зрозумієте, що «світ» вашої гри краще зберігати в одному місці. Певний меч НЕ є власністю вашого гравця, а сутністю у вашій грі (гравець може його втратити, хтось може його знайти тощо), тому багато з цих "об'єктів" у вашому дереві насправді ПОСИЛАННЯ для сутностей (в той час як інші, як і здоров'я гравця, справді лише атрибути). Вам доведеться розділити два типи, мати глобальну пам’ять для примірників, які можуть вирішувати посилання. Це також заощадить вас при серіалізації ігрового стану, і кілька об'єктів звертаються до тієї ж іншої сутності (як-от "Місце розташування" декількох гравців в одному храмі).
• (і згадати про реальну шліфувальну систему мозку: схожість зберігання класів та сховища екземплярів; той факт, що декларація типу може бути об’єктом самих себе так само, як компоненти програми, активні вікна, сеанси користувача тощо. Це земля таких маніяків, як я.)

У будь-якому випадку, я сподіваюся, що ви можете використати щось із цієї розминки.

Я не збираюся давати вам довгу відповідь, але я стикався з такою ситуацією раніше і, відверто кажучи, я відмовився від спроби використовувати будь-яку існуючу структуру даних. Я просто створив власний об’єкт, який міг приймати нових батьків та дітей, схожих на XML-вузол.

Однак у вашому випадку я думаю, що використання класу Xml допоможе. Тоді ви можете мати властивості для кожного вузла, який може сказати вам, чи є класним вмінням, і ви можете легко отримати батьків та дітей будь-якого вузла, який ви хочете використовувати у комбінованому вікні чи іншим способом.

Крім того, я хотів би додати, що ви не повинні бігати від думки про те, щоб мати багато текстів / рядків. Ігри зазвичай включають AI, а AI, як правило, включає багато текстів.