Моделирование классов: иерархия или атрибут?

Question

У меня есть эти два объекта: Титулярный и знакомый (Семейный/родственник/родственник).

Знакомый [0 .. *] < ------> [1] Титулярные

Эти 2 класса имеет Общин атрибуты человека (имя, фамилия, дата рождения ....), и они 2 вид Партнерская

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

Человек также должен существовать сам по себе (не может быть абстрактным), и не все Лица являются аффилированными лицами НО! Мне также нужен способ установить/обработать поведение сообщества для Titular и Familiar.

Person [1] < ------> [0 .. *] титулярный

Person [1] < ------> [0 .. *] Знакомый

титулярный [1] < ------> [0 .. *] Знакомый

Так сомнение:

public class Titular extend Person 
public class Familiar extend Person { 

или

public class Titular implement Affiliate { 
    private Person person; 

public class Familiar implement Affiliate { 
    private Titular t; 
    private Person person; 

или (третья мысль)

public class Person { 
public abstract class Affiliate { 
    protected Person person; 
public class Titular extends Affiliate { 

Answer 1

После нескольких тестов я принял решение для Состав над наследованием. В качестве одного из тега «JPA», это решение должно быть отображено/аннотированный

..и ни один из возможных аннотаций костюмов

@Inheritance(strategy = InheritanceType.JOINED/SINGLE_TABLE/TABLE_PER_CLASS) 

Если титулярный и Знакомые простирается от лица, ОРМ требуется Столбец «DTYPE» в Лице, который бесполезен для меня, потому что не имеет значения, сколько Titular или Familiar Person может/станет в его жизни, это просто ОДИН реестр Личности.

А быть аффилированным лицом является «концепция» или поведение, которое мне нужно для выполнения некоторых полиморфных задач, у него нет никакого стойкого атрибута (FOR NOW!), Я сделаю его интерфейс.

@Entity 
public class Persona { 
    @Id 
    @GeneratedValue(strategy = GenerationType.IDENTITY) 
    private Integer id; 


@Entity 
public class Titular implements Afiliado { 
    @Id 
    @GeneratedValue(strategy = GenerationType.IDENTITY) 
    private Integer id; 
    @JoinColumn(nullable = false) 
    @ManyToOne(optional = false) 
    private Persona persona; 

@Entity 
public class Familiar implements Afiliado { 
    @Id 
    @GeneratedValue(strategy = GenerationType.IDENTITY) 
    private Integer id; 
    @JoinColumn(nullable = false) 
    @ManyToOne(optional = false) 
    private Persona persona; 
    @ManyToOne 
    private Titular titular; 

public interface Afiliado { 
    public String getNumero(); 
    //trick but necessary 
    public Persona getPersona(); 

    //another default Java 8 implementations.. 
} 

Answer 2

Изложенные в многословным, мы хотим следующее поведение (Если я вас правильно понял):

Titular является Person, который поддерживает функциональность Affiliate.

Familiar является Person, который поддерживает функциональные возможности Affiliate и связан с Titular.

Если мы читаем это 2 строки достаточного количества раз, один из возможных вариантов решения, которое кажется разумным является:

public class Titular extends Person implements Affiliate { 

public class Familiar extends Person implements Affiliate { 
    private Titular t; 

Answer 3

Как я понимаю, все Филиалы являются лицом, слишком (или у вас есть исключения к этому?) ! Таким образом, право иерархии:

Person --- Affiliate --- Titular 
         \- Familiar 

Теперь, когда к наследованию или иметь указатель ... что называется наследование композиции, в/с, и есть веские аргументы в пользу обоих. Основными причинами выбора состава являются:

1. Возможные или необязательные отношения: скажем, владелец автомобиля может измениться или автомобиль не может иметь владельца. Кошка не может перестать быть животным и быть чем-то другим.
2. Различные общедоступные API: при работе с композицией вы можете вручную переадресовывать любой API, который вы хотите выставить из своего внутреннего указателя, скрывать или изменять вещи из «родителя», как вы это сделаете.

В общем, вы найдете, что наследование имеет больше смысла, когда ClassA IS-A ClassB, поэтому вы не ожидаете, что это изменится, и вы бы не хотели, чтобы оба класса представляли другой API. Вы увидите эту рекомендацию повсюду, и она кажется подходящей для вашего примера, как перчатка.