Если не полиморфизм, как я могу моделировать эти классы

Question

Хорошо, скажите, что я моделирую следующий футбольный клуб: Все люди - люди. Игрок является лицом и, следовательно, расширяет Индивидуум. Участник является лицом и, следовательно, расширяет Индивидуум.

суперкласса:

Individual {name, eyeColour} 

Подклассы:

Player extends Individual {position} 
Member extends Individual {subscription} 

Том является владельцем футбольного клуба:

Individual i = new Individual("Tom", "Blue") 

Боб & Тони являются Игроки:

Player p1 = new Player("Bob", "Green", "Goalkeeper") 
Player p2 = new Player("Tony", "Blue", "Striker") 

Стив является членом:

Member m = new Member("Steve", "Brown", 5.00) 

Частные лица, игроки и члены все сохранялось в той же рода (Individual) в хранилище данных GAE с использованием объективизации.

 
    name eyeColour position  subscription ^d 
    Tom  Blue  [missing]  [missing]  Individual 
    Bob  Green  Goalkeeper  [missing]  Player 
    Tony Blue  Striker   [missing]  Player 
    Steve Brown  [missing]  5.00   Member 

Что делать, если, например, Боб решает стать членом, а также игроком? Я хочу сохранить подписку. Я не могу рассказать Бобу индивидуальному персонажу, а затем опуститься до члена. Java не позволяет этого. Я не могу создать нового пользователя и скопировать все свойства объекта игрока Боба и сохранить его с тем же идентификатором - я потеряю его свойство Position. Мне нужен Боб, чтобы быть как членом, так и игроком в datstore, но НЕ в форме объекта (я не после многократного наследования) Я все еще хочу получить (Player.class, «Bob») и иметь объект Player или получить (Member.class, «Bob») и иметь объект Member. Мне не нужен объект, у которого одновременно есть свойства позиции и подписки.

Я также хочу, чтобы избежать этого является хранилищу:

 
    name eyeColour position subscription ^d 
    Tom  Blue  [missing] [missing] Individual 
    Bob  Green  Goalkeeper [missing] Player 
    Bob  Green  [missing] 10.00  Member 
    Tony Blue  Striker  [missing] Player 
    Steve Brown  [missing] 5.00  Member 

потому что Боб теперь имеет дублирование данных по имени и eyeColour, которые могли бы привести к inconsistancy данных.

Любые идеи о том, как смоделировать это?

Также, если Том станет игроком, или Стив станет участником?

Answer 1

Individual {name, eyeColour} 
MemberRole {individual, position} 
PlayerRole {individual, subscription} 

Понятно, что наследование не подходит для вашей задачи. Например, кто-то может играть в двух разных командах или быть членом двух разных клубов (и ваша оригинальная структура не позволит иметь более одного футбольного клуба вообще).

Что представляют собой люди, и какими ролями они являются, - это разные вещи. Например, вы бы не захотели, чтобы какая-то глобальная БД хранила ваше имя, ваши точки переполнения, ваше семейное положение и ваше занятие в той же таблице Individual.

Если Боб решает стать членом, сам Боб не изменится; его роли. Боб решил стать членом, все еще такой же добрый старый Боб, просто он теперь сможет сделать то, что ему было запрещено раньше.

PS: Вы используете термин подписка в своем ответе. Вот что ваш Игрок is - a Подписки. Subscription s, очевидно, не является некоторым определенным подмножеством Individual s, Subscription - это совершенно другое сущность. Конечно, он должен знать о том, к чему относится Individual, но он не является самим Individual.

Answer 2

В самом начале я хотел бы видеть все как Individual, но вы хотите сделать определенные лицо либо Player или Member или both. Вам понадобится смоделировать этот сценарий, используя Interfaces. Поскольку я не в Java, я предложил бы делать что-то похожее на этот код:

interface IPlayable {void MakePlayable (string position)}; 
interface IMembership {void AddMembership (double subscription)}; 

class Individual implements IPlayable, IMembership{name, eyeColour, IPlayable.MakePlayable(string position), IMembership.AddMembership(double subscription)}; 

//Usage to make Tom a Player 
Individual tom = new Individual("Tom", "Blue"); 
tom.MakePlayable("GoalKeeper"); 

//Usage to make Steve a Member 
Individual steve = new Individual("Steve", "Brown"); 
steve.AddMembership(5.00); 

//Usage to make Jim both a Player and a Member 
Individual jim = new Individual("Jim", "Black"); 
jim.MakePlayable("Forward"); 
jim.AddMembership(4.00); 

Другое, чем реализация множественного сценария интерфейса, используя интерфейс также необходим здесь, потому что с помощью класса член будет иначе сделайте человека постоянным членом какого-либо клуба, используя Интерфейс IMembership вы можете добавить метод RemoveMembership(), который поможет удалить членство в Individual, если требуется в будущем.

Answer 3

Попробуйте это ...

Individual быть SuperClass.

Участник и Участник как Интерфейсы.

Предположим, что Боб как игрок, а также как участник.

Теперь ..

Боб является индивидуальным (т.е. проходит индивидуальный)

Боб реализует игрок и члены Интерфейсов (т.е. роль Боба пьесы игрока и член оба)

Answer 4

См. Entity Relationships in JDO в документации GAE:

Вы можете моделировать отношения между постоянными объектами, используя поля типа . Соотношение между постоянными объектами может быть , описанное как принадлежащее, где один из объектов не может существовать без другого , или не зарегистрированного, где оба объекта могут существовать независимо от их отношения друг с другом. Реализация App Engine интерфейса JDO может моделировать как собственные, так и незанятые отношения один к одному и отношения «один ко многим», как однонаправленные, так и двунаправленные.

Я бы сказал, что у вас есть две «принадлежащие» отношения.Player и Member как «собственный» Individual.

Answer 5

public class Individual { 
    Role role; 
    int position;  //empty for MEMBER,filled for PLAYER_MEMBER and PLAYER 
    int subscription; //empty for PLAYER,filled for PLAYER_MEMBER and MEMBER } 

public enum Role { MEMBER,PLAYER,PLAYER_MEMBER; } 

Поэтому, когда переключатель сделан, вы просто меняете роль и заполняете недостающее поле. Проверка должна быть выполнена.

Answer 6

Сделайте класс Indiviual (имя, eyecolor) и создайте интерфейсы Владельца, Игрока и Участника. У вас будут уникальные личности, и вы продолжаете добавлять к ним функциональность. Следовательно, у вас будет таблица, как вы хотите, и в последнем столбце будут перечислены различные реализации.

Использование интерфейсов намного лучше, чем реализация множественного наследования, а java делает это. Итак, лучше всего использовать это