![]() |
|
|
|||||
Честно говоря, на мой взгляд, решать проблему раздутого класса наследованием вообще не верно, ибо оно не для того придумано. Наследование предназначено для полиморфизма и модульности архитектуры, а также для избавления от копипасты кода. Наследование имеет смысл, когда детей больше, чем один. Даже в Чистом коде об этом есть - каждый следующий узел потомков в наследовании должен представлять из себя дерево, то есть разветвляться. Иначе наследование просто не имеет смысла и создавать кучу родителей и потомков на пустом месте - избыточно. Поэтому решать проблему раздутого класса надо, конечно же, через композицию.
__________________
while(live()) { hope(); } |
|
|||||
Нуб нубам
модератор форума
Регистрация: Jan 2006
Адрес: Бердск, НСО
Сообщений: 6,445
|
Цитата:
__________________
Reality.getBounds(this); |
|
|||||
Регистрация: Dec 2014
Адрес: Санкт-Петербург
Сообщений: 479
|
Не, скиллы у неписей учитываются, с этим даже отдельная геймплейная механика связана, где они не все изначально известны и игроку требуется по ходу прояснять их для повышения общей эффективности.
В любом случае, я очень всем признателен за комментарии. Тема началась ни шатко ни валко, но по итогу раскрутилась-таки. Много чего почерпнул. Добавлено через 1 минуту ZergMaster, чистый код - имеется в виду книга Боба Мартина?
__________________
Не сломано - не чини! |
|
|||||
Appleman да. Но это не точно
__________________
while(live()) { hope(); } |
|
|||||
Регистрация: Apr 2018
Сообщений: 42
|
Цитата:
Цитата:
|
|
|||||
Регистрация: Dec 2014
Адрес: Санкт-Петербург
Сообщений: 479
|
Послушайте, други,печальную и поучительную историю об импульсивном программировании. Я наконец добрался до Entity-Component-System, пяток статей прочитал (RedHead90, спасибо за наводку), и так меня этот подход вставил, ну просто не по-детски! По крутизне почти MVC, имхо. И загорелся я если не целиком под него переписать, то хотя бы свою частную проблему с раздутым классом персонажа решить. И рефакторил я хрен знает сколько часов на кураже. Выделил отдельные компоненты, схожие по области и логике, кое-где от них ещё унаследовался для реализации специфики, задвинул в них методы обработки данных. На первый взгляд получилось шикарно. Вполне компактный класс Character, к которому подключаются блоки Personality, Parameters, Skills, Statuses и т.п. И все они ни хрена не инкапсулированы. Надо кому со стороны, например, условие проверить - не вопрос! Обращаемся: character.personality[PropID] и вперёд с песней!
Но вот один момент я, блин, не учёл. А он по ходу самый важный. Почему-то мне было невдомёк, что в "чистом" виде все свойства, забитые в Personality и Sexuality, никому не нужны. Причём совсем. Получая, например, значение интеллекта, нужно ещё посмотреть, не надет ли шутовской колпак (WearManager), и не контужен ли наш герой (StatusManager). Короче, тянуть что-то в обход самого "узлового" Character ни фига не получается. А если через него, то теперь у нас не "одно окно" в форме character[PropID], а ещё бухгалтерия с определением, к какому компоненту обращаться. В общем, сижу-горюю. И обратно к бардаку откатывать неохота, и как это хозяйство без крови организовать не придумывается.
__________________
Не сломано - не чини! |
![]() |
![]() |
Часовой пояс GMT +4, время: 18:02. |
|
« Предыдущая тема | Следующая тема » |
|
|