ОО Дизайн Проблема с идентификаторами - PullRequest
0 голосов
/ 24 декабря 2009

Скажем, в качестве примера, у меня есть класс Player, который имеет расу через класс Race. Эти расы фиксированы по количеству и загружаются в массив, к которому можно обращаться статически.

Мой вопрос заключается в том, должен ли класс Player иметь индексный идентификационный номер, который затем должен был бы вызвать статическую функцию getRaceByID (int), чтобы получить класс Race для выполнения некоторых внутренних вычислений. Теперь я мог бы обойтись без этого, если бы у меня была ссылка на расу непосредственно в классе Player, но тогда сохранение игрока в файл становится проблематичным. Я только хочу, чтобы ссылка на Гонку была сохранена вместе с данными Игрока. Как ID.

Я хочу не хранить копию данных гонки и вместо этого просто ссылаться на нее. Есть ли что-то, что я должен делать по-другому? Есть ли шаблоны для решения чего-то подобного? Базы данных имеют дело с идентификаторами, но, похоже, не очень хорошо работают при разработке ОО. Любая помощь приветствуется, спасибо.


class Player
{
  Race race;
}

В этом случае мне нужно сравнить эту гонку с гонками в моем статическом массиве, чтобы я мог правильно выписать идентификатор индекса. Другим решением является сохранение идентификатора в самом классе Race, чтобы я мог ссылаться на него непосредственно из класса Race следующим образом:

race.getID();

Или было бы лучше пойти с чем-то вроде этого, чтобы усилить эти отношения:

class Player { int raceID; }</p> <p>Race r = MyFile.getRaceByID(raceID);</p> <p>// can now use race

Ответы [ 3 ]

1 голос
/ 24 декабря 2009

То, что у вас в памяти, не обязательно должно быть тем, что вы храните в базе данных.

Детали будут зависеть от языка, который вы используете, и технологии Object-to-Database.

Если у вас есть

Player {
     Race myRace;
     // etc
}

Это не обязательно означает, что у вас есть копия Расы, в некоторых языках это подразумевает "ссылку" или "указатель" на Расу.

Когда вы приходите хранить в базе данных, было бы нормально хранить только идентификатор расы.

Другими словами, вам не нужно ставить под угрозу дизайн ОО, чтобы достичь желаемого эффекта.

0 голосов
/ 24 декабря 2009

Относительно использования идентификаторов в ОО-дизайне: Современный C ++ Design Александреску имеет отличную главу о объектных фабриках. Если у вас есть большой оператор switch для вашего идентификатора, то вы, вероятно, могли бы извлечь пользу из прочтения этой главы, поскольку она покажет вам ОО способ справиться с подобными вещами. Как написано в книге:

Пример рисования формы [из полиморфизм] часто встречается в книгах C ++, в том числе Классика Бьярна Страуструпа (Страуструп, 1997). Однако большинство вводные книги C ++ останавливаются, когда приходит к загрузке графики из файла, именно потому, что хорошая модель имеющие отдельные объекты рисования ломается .... Простая реализация должен требовать каждого производного от формы объект для сохранения интегрального идентификатора в самом начале. Каждый объект должен иметь свой собственный уникальный идентификатор. затем чтение файла выглядело бы так:

[код с большим переключателем]

.... Единственный проблема [с этим типом кода] в том, что это нарушает самые важные правила Ориентация объекта: [Е.Г.,] Это собирает в один исходный файл знание обо всех формулах занятия в программе ....

0 голосов
/ 24 декабря 2009

Нет причин, по которым ваша концепция на основе идентификаторов не будет работать. Он не нарушает никаких принципов ОО и имеет несколько преимуществ. Я не вижу причин НЕ идти по этому пути, особенно если вы уже определили, что он будет работать хорошо для вас.

Кроме того, если вы хотите избежать разброса static_races[player.race_id] по всему коду, простой функции-обертки будет достаточно для поддержания более "ощущения OO" (псевдокод, поскольку вы не указали язык:

function Race Player::GetRace() {
    return static_races[this.race_id];
}

Простой, но эффективный. Не нужно слишком усложнять вещи.

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...