Як зробити тип даних для чогось, що представляє собою або дві інші речі

Фон

Ось актуальна проблема, над якою я працюю: я хочу, щоб представити карти в картковій грі Magic: The Gathering . Більшість карт у грі - це картки звичайного вигляду, але деякі з них розділені на дві частини, кожна зі своєю назвою. Кожна половина цих двоскладових карт трактується як сама картка. Тож для наочності я буду використовувати Cardлише для позначення того, що є або звичайною карткою, або половиною картки з двох частин (іншими словами, щось із лише одним ім’ям).

Отже, у нас є базовий тип, Card. Мета цих об'єктів насправді просто утримувати властивості картки. Вони насправді нічого не роблять самі.

interface Card {
    String name();
    String text();
    // etc
}

Є два підкласи Card, які я дзвоню PartialCard(половина картки з двох частин) та WholeCard(звичайна картка). PartialCardмає два додаткові методи: PartialCard otherPart()і boolean isFirstPart().

Представники

Якщо у мене є колода, вона повинна складатися з WholeCards, а не Cards, як a Cardможе бути PartialCard, і це не мало б сенсу. Тому я хочу об'єкт, який представляє "фізичну карту", тобто те, що може представляти одну WholeCardчи дві PartialCardс. Я орієнтовно називаю цей тип Representativeі Cardмав би метод getRepresentative(). A Representativeне надає майже ніякої прямої інформації на картці (картках), яку вона представляє, вона вказувала б лише на неї / них. Тепер моя блискуча / божевільна / німа ідея (ви вирішите) полягає в тому, що WholeCard успадковує і те, Card і іншеRepresentative . Адже це картки, які представляють себе! WholeCards могли реалізувати getRepresentativeяк return this;.

Що стосується PartialCards, вони не представляють себе, але у них є зовнішній, Representativeякий не є Card, але надає методи доступу до двох PartialCards.

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

Необхідність типового лиття

Оскільки PartialCards і WholeCardsобидва Cards, і зазвичай немає вагомих причин відокремлювати їх, я зазвичай просто працюю Collection<Card>. Тому іноді мені потрібно буде робити це PartialCard, щоб отримати доступ до їх додаткових методів. Зараз я використовую описану тут систему, тому що я дійсно не люблю явні касти. І як Card, Representativeбуло б потрібно бути відлиті або до WholeCardабо Composite, щоб отримати доступ до фактичної CardS , які вони представляють.

Тож просто для підсумків:

• Тип бази Representative
• Тип бази Card
• Тип WholeCard extends Card, Representative(доступ не потрібен, він представляє себе)
• Введіть PartialCard extends Card(надає доступ до іншої частини)
• Тип Composite extends Representative(надає доступ до обох частин)

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

Мені здається, вам слід мати такий клас

class PhysicalCard {
    List<LogicalCard> getLogicalCards();
}

Код, який стосується фізичної картки, може стосуватися класу фізичної картки, і код, який стосується логічної карти, може вирішувати це.

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

Не має значення, чи вважаєте ви фізичну та логічну карту тим самим. Не припускайте, що лише тому, що вони є одним фізичним об'єктом, вони повинні бути тим самим об'єктом у вашому коді. Важливим є те, чи прийняття цієї моделі полегшує кодер для читання та запису. Справа в тому, що прийняття простішої моделі, коли кожна фізична карта трактується як колекція логічної картки послідовно, 100% часу, призведе до більш простого коду.

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

Я б запропонував одну з двох альтернатив:

Варіант 1. Поставтеся до неї як до однієї картки, позначеної як Половина A // Половина B , як і на сайті MTG, перелічено Wear // Tear . Але дозвольте своїй Cardорганізації містити N кожного атрибута: ім’я, яке можна відтворити, вартість мани, тип, рідкість, текст, ефекти тощо.

interface Card {
  List<String> Names();
  List<ManaCost> Costs();
  List<CardTypes> Types();
  /* etc. */
}

Варіант 2. Не всі, що відрізняються від варіанту 1, моделюють його після фізичної реальності. У вас є Cardорганізація, яка представляє фізичну карту . Тоді його мета - утримувати N Playable речей. Цей Playable«s кожен може мати унікальне ім'я, вартість мани, список ефектів, список здібностей і т.д .. А ваш" фізичний " Cardможе мати свій власний ідентифікатор (або ім'я) , який представляє собою з'єднання кожного Playable» s ім'я, так само, як Здається, база даних MTG.

interface Card {
  String Name();
  List<Playable> Playables();
}

interface Playable {
  String Name();
  ManaCost Cost();
  CardType Type();
  /* etc. */
}

Я думаю, що будь-який із цих варіантів досить близький до фізичної реальності. І я думаю, що це буде корисно всім, хто дивиться на ваш код. (Як і ваше власне «я» через 6 місяців.)

Мета цих об'єктів насправді просто утримувати властивості картки. Вони насправді нічого не роблять самі.

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

Адже це картки, які представляють себе!

ІМХО, це звучить трохи дивно і навіть трохи дивно. Об'єкт типу "Картка" повинен представляти карту. Період.

Я нічого не знаю про Magic: The collection , але я думаю, ви хочете використовувати свої карти аналогічним чином, незалежно від їх фактичної структури: ви хочете відобразити рядкове представлення, ви хочете обчислити значення атаки тощо.

Для проблеми, яку ви описуєте, я рекомендував би шаблон дизайну композиту , незважаючи на те, що цей DP зазвичай представлений для вирішення більш загальної проблеми:

1. Створіть Cardінтерфейс, як ви вже робили.
2. Створіть ConcreteCard, що реалізує Cardта визначає просту карту обличчя. Не соромтеся ставити поведінку звичайної картки до цього класу.
3. Створіть CompositeCard, що реалізує Cardта має два додаткові (і апріорі приватні) Card. Давайте називатимемо їх leftCardі rightCard.

Елегантність підходу полягає в тому, що CompositeCardмістить дві картки, які самі по собі можуть бути або ConcreteCard, або CompositeCard. У вашій грі leftCardі rightCard, ймовірно, систематично будуть ConcreteCard, але дизайн шаблону дозволяє безкоштовно проектувати композиції вищого рівня. Ваша маніпуляція з картою не враховуватиме реальний тип ваших карток, і тому вам не потрібні такі речі, як кастинг до підкласу.

CompositeCardВи Card, звичайно, повинні реалізувати методи, зазначені в , і робити це, беручи до уваги той факт, що така карта зроблена з двох карт (плюс, якщо ви хочете, щось специфічне для самої CompositeCardкарти. Наприклад, ви можете захотіти наступна реалізація:

public class CompositeCard implements Card
{ 
   private final Card leftCard, rightCard;
   private final double factor;

   @Override // Defined in Card
   public double attack(Player p){
      return factor * (leftCard.attack(p) + rightCard.attack(p));
   }

   @Override // idem
   public String name()
   {
       return leftCard.name() + " combined with " + rightCard.name();
   }

   ...
}

Роблячи це, ви можете використовувати CompositeCardсаме так, як і для будь-якого Card, а специфічна поведінка прихована завдяки поліморфізму.

Якщо ви впевнені, що а CompositeCardзавжди матиме два звичайних Cards, ви можете зберегти цю ідею та просто використовувати ConcreateCardяк тип для leftCardта rightCard.

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

Можливо, Card і Playable мають ефект.

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

Почнемо з тієї вищої абстракції, Cardінтерфейсу:

public interface Card {
    public void accept(CardVisitor visitor);
}

Можливо, є трохи більше поведінки на Cardінтерфейсі, але більшість власників ресурсів переходять до нового класу CardProperties:

public class CardProperties {
    // property methods, constructors, etc.

    String name();
    String text();
    // ...
}

Тепер у нас може бути SimpleCardпредставлення цілої картки з єдиним набором властивостей:

public class SimpleCard implements Card {
    private CardProperties properties;

    // Constructors, ...

    @Override
    public void accept(CardVisitor visitor) {
        visitor.visit(properties);
    }
}

Ми бачимо , як CardPropertiesі ще, щоб бути написано CardVisitorпочинає вписуватися в Давайте зробимо. , CompoundCardЩоб уявити карту з двома особами:

public class CompoundCard implements Card {
    private CardProperties firstFaceProperties;
    private CardProperties secondFaceProperties;

    // Constructors, ...

    public void accept(CardVisitor visitor) {
        visitor.visit(firstFaceProperties, secondFaceProperties);
    }
}

CardVisitorПочинає з'являтися. Спробуємо зараз записати цей інтерфейс:

public interface CardVisitor {
    public void visit(CardProperties properties);
    public void visit(CardProperties firstFaceProperties, CardProperties secondFaceProperties);
}

(Це перша версія інтерфейсу на даний момент. Ми можемо вдосконалити, про які піде мова пізніше.)

Зараз ми розформували всі частини. Нам просто потрібно їх скласти:

List<Card> cards = new LinkedList<>();
cards.add(new SimpleCard(new CardProperties(/* ... */)));
cards.add(new CompoundCard(new CardProperties(/* ... */), new CardProperties(/* ... */)));

 for(Card card : cards) {
     card.accept(new CardVisitor() {
         @Override
         public void visit(CardProperties properties) {
             // Do something for simple cards with a single face
         }

         public void visit(CardProperties firstFaceProperties, CardProperties secondFaceProperties) {
             // Do something else for compound cards with two faces
         }
     });
 }

Виконання виконуватиме відправлення до правильної версії #visitметоду за допомогою поліморфізму, а не намагається його порушити.

Замість того, щоб використовувати анонімний клас, ви навіть можете просунути CardVisitorвнутрішній клас або навіть повний клас, якщо поведінка багаторазово використовувати або якщо ви хочете можливість міняти поведінку під час виконання.

Ми можемо використовувати класи, як зараз, але є деякі вдосконалення CardVisitorінтерфейсу. Наприклад, може настати час, коли Cards може мати три-чотири або п’ять граней. Замість того, щоб додавати нові методи для реалізації, ми могли просто мати другий метод take and array замість двох параметрів. Це має сенс, якщо багатогранні картки трактуються по-різному, але кількість облич вище однієї обробляється однаково.

Ми також могли б перетворити CardVisitorна абстрактний клас замість інтерфейсу та мати порожні реалізації для всіх методів. Це дозволяє нам реалізовувати лише ті поведінки, які нас цікавлять (можливо, нас цікавлять лише одноосібники Card). Ми також можемо додавати нові методи, не змушуючи кожен існуючий клас реалізовувати ці методи або не вдаватися до компіляції.