#design-patterns #inheritance #polymorphism #factory
Вопрос:
Я все еще пытаюсь разобраться в шаблонах проектирования и во второй раз сталкиваюсь с той же проблемой, которая, похоже, требует решения по шаблону.
У меня есть система учетных записей с несколькими типами учетных записей. У нас есть типы учетных записей ресторанов, отелей, поставщиков услуг и потребителей. Я уверен, что в будущем будет больше типов бизнес-аккаунтов, и, конечно, есть учетная запись глобального администратора.
Поэтому мне интересно, как реализовать переключение типов учетных записей. например, у каждой учетной записи будет один или несколько профилей, но профиль будет отличаться в зависимости от типа учетной записи. Какие отношения классов я должен использовать здесь, чтобы иметь дело с несколькими типами учетных записей — полиморфизмом или наследованием?
Похоже, что, возможно, должен быть абстрактный базовый класс профиля, который должны расширять другие профили, но я не уверен, как это реализовать (например, объединенная таблица между типами профилей и типами учетных записей?).
Это также похоже на возможность реализовать заводской шаблон, я просто не совсем уверен, как это сделать.
Есть какие-нибудь идеи, пожалуйста?
*
*
Отредактировано, чтобы привести несколько примеров, как было предложено:
Account -> hasMany -> Users
Account -> belongsTo -> AccountType
Account -> hasOne -> Profile
Профиль отличается в зависимости от типа учетной записи, например, в учетной записи типа ресторана будет меню, карта вин и т. Д., В учетной записи типа отеля будут типы номеров, удобства, у учетной записи типа потребителя будут личные вкусы, страна проживания и т. Д.
Вопрос заключался в том, какой шаблон проектирования лучше всего реализовал бы эти отношения.
Надеюсь, это понятнее, спасибо!
Комментарии:
1. попробуйте отредактировать пару примеров, из описания неясно, в чем проблема; похоже, что вы используете термин «учетная запись» для обозначения двух разных вещей
2. Что вы подразумеваете под «Профилем»? Это что-то похожее на «Роль» или на «Имя и адрес»?
Ответ №1:
Я бы предложил агрегировать, а не наследование здесь для взаимосвязи между учетной записью и профилем, но иметь базовый класс учетной записи, который наследуется в несколько типов учетных записей.
Учетная запись содержит объект профиля, который может быть задан в конструкторе каждого полиморфного типа учетной записи.
Вы также можете обернуть создание учетной записи в шаблон фабрики или виртуального конструктора.
Ответ №2:
спасибо за примеры; возможно, вы пытаетесь сделать это сложнее, чем есть на самом деле. Сработает ли следующее?
User <<--> Account
Account <<--> AccountType
Account <--> Profile
Profile <<--> ProfileType
Я сомневаюсь в соотношении учетная запись-профиль 1:1, кажется вероятным, что у учетной записи может быть более одного профиля или что профиль может принадлежать пользователю, а не учетной записи, но я действительно не знаю, что такое профиль/делает в этом контексте