https://github.com/alertedcoffee/hahtesttask
https://github.com/alertedcoffee/hahtesttask
java oop-principles
Last synced: 12 months ago
JSON representation
- Host: GitHub
- URL: https://github.com/alertedcoffee/hahtesttask
- Owner: AlertedCoffee
- Created: 2023-10-05T11:24:50.000Z (over 2 years ago)
- Default Branch: master
- Last Pushed: 2023-10-06T14:46:12.000Z (over 2 years ago)
- Last Synced: 2025-03-05T23:28:59.186Z (about 1 year ago)
- Topics: java, oop-principles
- Language: Java
- Homepage:
- Size: 23.4 KB
- Stars: 0
- Watchers: 1
- Forks: 0
- Open Issues: 0
-
Metadata Files:
- Readme: README.md
Awesome Lists containing this project
README
# # HaHTestTask
tg: [@MatveyOzolin](https://t.me/MatveyOzolin)
Для реализации проекта по [заданию Heads x Hands](https://docs.google.com/document/d/1lfpe1JDCuGMQ3cFyn5oNk2PqRO94z6IqCq6yoTaUsYo/edit) я решил использовать паттерн проектирования Стратегия, это позволяет оставить код закрытым для изменений, но открытым для расширения.
Таким образом, создан класс Actor с основными параметрами здоровья, параметры Атаки и Урона были вынесены в абстрактный класс AttackBehavior, а параметр Защиты в TakeDamageBehavior (см. диаграмму классов).
Диаграмма классов
В объектах Actor хранится ссылка на определенную реализацию Атаки и Защиты, что позволяет менять их на этапе выполнения и хранить типовые параметры, как в приведенных примерах в виде SimpleAttack, SimpleProtection и т.д. Вызывая у Actor PerfomAttack, вызывается определенная реализация attackBehavior.Attack(), так и с PerfomTakeDamage (это метод, посредством которого персонаж получает урон). Эта архитектура так же позволяет при расширении переопределять принципы получения модификатора атаки и вычисления урона (например при каких-то необычных видах оружия). Таким же образом работает и с получением урона.
(Можно было бы завернуть все в декораторы, но это уже лишнее, на мой взгляд)
Класс Player расширяет Actor возможностью лечиться с ограниченным количеством раз.
В задании не было ничего сказано про Display методы, потому в классах наследниках местами встречаются не совсем уместные системауты, которые нужно было бы вынести в отдельные методы, вызывающие реализацию какого-нибудь интерфейса, чтобы “визуальная” составляющая объектов не находилась в классе.