Какой класс дизайна лучше?

Какой дизайн класса лучше и почему?

public class User
{
    public String UserName;
    public String Password;
    public String FirstName;
    public String LastName;
}

public class Employee : User
{
    public String EmployeeId;
    public String EmployeeCode;
    public String DepartmentId;
}

public class Member : User
{
    public String MemberId;
    public String JoinDate;
    public String ExpiryDate;
}

ИЛИ

public class User
{
    public String UserId;
    public String UserName;
    public String Password;
    public String FirstName;
    public String LastName;
}

public class Employee
{
    public User UserInfo;
    public String EmployeeId;
    public String EmployeeCode;
    public String DepartmentId;
}

public class Member
{
    public User UserInfo;
    public String MemberId;
    public String JoinDate;
    public String ExpiryDate;
}

ОТВЕТЫ

Ответ 1

На вопрос просто ответят, узнав, что наследование моделирует отношение "IS-A", а членство моделирует отношение "HAS-A".

  • Сотрудник IS Пользователь
  • Сотрудник HAS A userinfo

Какой из них правильный? Это ваш ответ.

Ответ 2

Мне не нравится ни один. Что происходит, когда кто-то является членом и сотрудником?

Ответ 3

Задайте себе следующее:

  • Вы хотите смоделировать Employee IS User? Если это так, выберите наследование.
  • Вы хотите, чтобы модель Employee имела информацию о пользователе? Если да, используйте композицию.
  • Существуют ли виртуальные функции между Пользователем (info) и Работником? Если это так, используйте наследование.
  • Может ли сотрудник иметь несколько экземпляров User (info)? Если да, используйте композицию.
  • Имеет ли смысл назначать объект Employee объекту User (info)? Если это так, используйте наследование.

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

Ответ 4

Я не думаю, что композиция всегда лучше, чем наследование (как правило, обычно). Если Employee и Member действительно являются Пользователями, и они являются взаимоисключающими, то первый дизайн лучше. Рассмотрим сценарий, в котором вам нужно получить доступ к UserName сотрудника. Используя вторую конструкцию, вы должны:

myEmployee.UserInfo.UserName

что плохо (закон Деметры), поэтому вы бы реорганизовали:

myEmployee.UserName

который требует небольшого метода для Employee делегировать объект User. Все это избегается первой конструкцией.

Ответ 5

Хороший вопрос, хотя во избежание отвлекаться по поводу правильного и неправильного я бы подумал о том, чтобы просить плюсы и минусы каждого подхода - я думаю, что вы имели в виду, что лучше или хуже, и почему. Во всяком случае....

Первый подход aka Наследование

Плюсы:

  • Разрешает полиморфное поведение.
  • Изначально простой и удобный.

Минусы:

  • Может стать сложным или неуклюжим с течением времени, если добавлено больше поведения и отношений.

Второй подход aka Состав

Плюсы:

  • Хорошо подходит для не-oop-сценариев, таких как реляционные таблицы, структурированное программирование и т.д.
  • Является простым (если не обязательно удобным) постепенным расширением отношений и поведения.

Минусы:

  • Нет полиморфизма, поэтому менее удобно использовать связанную информацию и поведение.

Списки, подобные этим + упомянутые вопросы Jon Limjap, помогут вам принять решения и начать работу - тогда вы можете найти ответы на правильные ответы;-)

Ответ 6

Вы также можете думать о Employee как о роли пользователя (человека). Роль пользователя может измениться во времени (пользователь может стать безработным), или Пользователь может иметь несколько ролей одновременно.

Наследование намного лучше, если существует реальное "отношение, например Apple - Fruit. Но будьте очень осторожны: Circle - Ellipse не является реальным" является "отношением, потому что cirlce имеет меньше" свободы ", чем эллипс (круг является состоянием эллипса) - см.: Проблема эллипса круга.

Ответ 7

Реальные вопросы:

  • Каковы бизнес-правила и пользовательские истории за пользователем?
  • Каковы бизнес-правила и пользовательские истории за сотрудником?
  • Каковы бизнес-правила и пользовательские истории за членом?

Это могут быть три совершенно несвязанных объекта или нет, и это определит, будет ли работать ваш первый или второй дизайн, или если другой совершенно другой дизайн в порядке.

Ответ 8

Ни один из них не является хорошим. Слишком много изменчивого состояния. Вы не сможете создать экземпляр класса, который находится в недопустимом или частично инициализированном состоянии.

Тем не менее, второй лучше, потому что он способствует составу над наследованием.

Ответ 9

Утверждение вашего требования/спецификации может помочь прийти к "лучшему дизайну".
На данный момент ваш вопрос слишком "интерпретируется для читателя".

Ответ 10

Вот сценарий, о котором вы должны подумать:

Композиция (второй пример) предпочтительнее, если один и тот же Пользователь может быть как Сотрудником, так и Участником. Зачем? Потому что для двух экземпляров (Employee и Member), которые представляют одного и того же пользователя, если данные пользователя изменяются, вам не нужно обновлять их в двух местах. Только экземпляр пользователя содержит всю информацию о пользователе, и только он должен быть обновлен. Поскольку классы Employee и Member содержат один и тот же экземпляр пользователя, они автоматически содержат обновленную информацию.

Ответ 11

Еще три варианта:

  • Если класс User содержит дополнительную информацию как для сотрудников, так и для членов, причем неиспользованные поля пусты (ID конкретного User будет указывать, был ли пользователь сотрудником, членом, или что-то еще).

  • Есть класс User, который содержит ссылку на ISupplementalInfo, где ISupplementalInfo наследуется ISupplementalEmployeeInfo, ISupplementalMemberInfo и т.д. Код, применимый ко всем пользователям, может работать с User объекты класса и код, который имел ссылку User, могли получить доступ к дополнительной информации пользователя, но этот подход не позволит изменить User, если в будущем потребуются различные комбинации дополнительной информации.

  • Как указано выше, но класс User содержит некоторую коллекцию ISupplementalInfo. Преимущество такого подхода состояло в том, чтобы облегчить добавление свойств пользователю во время выполнения (например, поскольку a Member получил наем). При использовании предыдущего подхода нужно было бы определить разные классы для разных комбинаций свойств; превращение "члена" в "участника + клиента" потребует от другого кода превращения "служащего" в "сотрудника + клиента". Недостатком последнего подхода является то, что он будет затруднять защиту от избыточных или несогласованных атрибутов (использование чего-то типа Dictionary<Type, ISupplementalInfo> для хранения дополнительной информации могло бы работать, но казалось бы немного "громоздким" ).

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