Какой паттерн применить в данной ситуации? Все хорошего дня! Условия задачи следующие.
Есть класс представляющий человека. Его реализация в данном контексте не важна абсолютно. Человеку могут быть присвоены те или иные награды. Соответственно, награда - отдельный класс, скорее всего он будет абстрактным, и наследоваться в потомков (каждый потомок под определенный тип награды).
Проблема в следующем. Все пять порождающих паттернов которые мы можем лицезреть в банде четырех - работают касательно свойств типа isCallable, isDrawable и т.д., то есть по сути дела мы, объявляя такого рода свойства, говорим какой интерфейс реализован у данного класса. Даже если т.с. с гуманитарной точки зрения посмотреть - "подвижный"="может двигаться", "съедобный"="можно съесть" и т.д.... В моем случае с наградами сей эпитет неуместен - потому что получается что-то типа "зеленый" = "?", "высокий" = "?" и т.д. Если более конкретно - в классе наград есть такие свойства как "когда получена", "кем выдана", "тип награды", "удостоверяющий документ", "номер удостоверяющего документа" и т.п., и такого типа поля варьируются в зависимости от типа награды (какие-то должны быть включены в класс какие-то нет). Насколько уместно применение абстрактной фабрики, строителя или прототипа (и если да, то что именно использовать?), нужны ли здесь паттерны и целесообразно ли здесь вообще использование ООП?
Какой паттерн применить в данной ситуации? Все хорошего дня! Условия задачи следующие.
Есть класс представляющий человека. Его реализация в данном контексте не важна абсолютно. Человеку могут быть присвоены те или иные награды. Соответственно, награда - отдельный класс, скорее всего он будет абстрактным, и наследоваться в потомков (каждый потомок под определенный тип награды).
Проблема в следующем. Все пять порождающих паттернов которые мы можем лицезреть в банде четырех - работают касательно свойств типа isCallable, isDrawable и т.д., то есть по сути дела мы, объявляя такого рода свойства, говорим какой интерфейс реализован у данного класса. Даже если т.с. с гуманитарной точки зрения посмотреть - "подвижный"="может двигаться", "съедобный"="можно съесть" и т.д.... В моем случае с наградами сей эпитет неуместен - потому что получается что-то типа "зеленый" = "?", "высокий" = "?" и т.д. Если более конкретно - в классе наград есть такие свойства как "когда получена", "кем выдана", "тип награды", "удостоверяющий документ", "номер удостоверяющего документа" и т.п., и такого типа поля варьируются в зависимости от типа награды (какие-то должны быть включены в класс какие-то нет). Насколько уместно применение абстрактной фабрики, строителя или прототипа (и если да, то что именно использовать?), нужны ли здесь паттерны и целесообразно ли здесь вообще использование ООП?
Есть класс представляющий человека. Его реализация в данном контексте не важна абсолютно. Человеку могут быть присвоены те или иные награды. Соответственно, награда - отдельный класс, скорее всего он будет абстрактным, и наследоваться в потомков (каждый потомок под определенный тип награды).
Проблема в следующем. Все пять порождающих паттернов которые мы можем лицезреть в банде четырех - работают касательно свойств типа isCallable, isDrawable и т.д., то есть по сути дела мы, объявляя такого рода свойства, говорим какой интерфейс реализован у данного класса. Даже если т.с. с гуманитарной точки зрения посмотреть - "подвижный"="может двигаться", "съедобный"="можно съесть" и т.д.... В моем случае с наградами сей эпитет неуместен - потому что получается что-то типа "зеленый" = "?", "высокий" = "?" и т.д. Если более конкретно - в классе наград есть такие свойства как "когда получена", "кем выдана", "тип награды", "удостоверяющий документ", "номер удостоверяющего документа" и т.п., и такого типа поля варьируются в зависимости от типа награды (какие-то должны быть включены в класс какие-то нет). Насколько уместно применение абстрактной фабрики, строителя или прототипа (и если да, то что именно использовать?), нужны ли здесь паттерны и целесообразно ли здесь вообще использование ООП?
Не можешь разобраться в этой теме?
Обратись за помощью к экспертам
Гарантированные бесплатные доработки в течение 1 года
Быстрое выполнение от 2 часов
Проверка работы на плагиат
Поможем написать учебную работу
В данной ситуации наиболее уместным будет использование паттерна Строитель (Builder). Паттерн Строитель позволяет создавать объекты с различными свойствами, не зависящими от конкретных классов объектов.
Вы можете создать класс-строитель, который будет иметь методы для установки различных свойств награды в зависимости от их типа. Например, методы setAwardDate(), setIssuer(), setDocumentType() и т.д.
Затем, в зависимости от типа награды, вы будете использовать соответствующий строитель для создания объекта награды с необходимыми свойствами.
Таким образом, использование паттерна Строитель позволит вам создать объекты наград с различными свойствами, в зависимости от их типа, без необходимости добавления множества условий и проверок внутри класса награды.
ООП здесь также целесообразно использовать, так как вы можете создать иерархию классов наград, где каждый класс будет отвечать за определенный тип награды, а также использовать полиморфизм для удобной работы с ними.