Но наборы свойств со временем становятся очень большими, начинают пересекаться нетривиальным образом.
Внести изменения в глубине иерархии становится проблематично, приходится думать заранее о «внедрении зависимостей», разрабатывать и использовать сложные инструменты рефакторинга.
Возможно ли всего этого избежать?
Тут вы ставите правильный вопрос. Действительно, если у нас что-то сложное, то может мы ошиблись на каком-то шаге и придумали нежизнеспособный механизм? Вы предлагаете сделать шаг по улучшению этого механизма.
С моей точки зрения естественное затруднение здесь в головах, а именно в желании сделать доступным все методы «через одну точку». Это желание пихать разные обязанности в один объект приводит к трудностям, которые вы описали. Это же желание погубит и описанный вами метод, хотя он, безусловно, может иметь какие-то преимущества в читаемости. Я считаю тут нужно сделать не один шаг, а два, а именно отказаться от наследования в пользу композиции. Разбивать объект на подсистемы. Тогда пересечение между разнотипными интерфейсами в рамках одного объекта просто исчезнет как явление.
Все эти навыки тренируются, это не что-то запредельное; о чём и говорит автор оригинального комментария. Просто многие люди не знают своих возможностей и считают, что «это не для них». Результирующий workflow это комбинация нескольких компромиссных параметров, в том числе ленности и необходимости выполнять работу. Нужно знать и любить свои инструменты и вовремя проводить улучшения, когда упираешься в предел их возможностей.
Тут не только TF2. Это безумная смесь TF2 и дотки, а также намешаны все остальные механики, какие можно придумать. Хороший дизайн. Огромный запас пафоса персонажей (как и во всех играх Близзард). Я думаю, их запас пафоса в сотни раз превышает их запас хп.
Ещё не совсем понятно, можно ли использовать одного и того же персонажа в противоположных командах или нет (и можно ли использовать по несколько игроков одного класса в команде). Если нельзя, то сравнение с TF2 слабеет, потому что TF2 базируется на девятке архетипичных боевых ролей, которые можно менять в течение раунда, увеличивать количество игроков конкретного класса и брать контр-классы.
За TF2 обидно, конечно, но он сам скатился, без чужой помощи. Если кто-то ещё покормится в этой нише, то пусть кормятся. TF2 не вернуть, так пусть хоть другие развиваются.
Почему вы использовали наименование Function#part вместо partial? Это ваше личное предпочтение, или для соответствия чему-то? В библиотеках обычно используется полный вариант.
И тут возникает проблема — fn(foo.bar.baz.bind(foo.bar)). Мы вынуждены писать foo.bar 2 раза, это явное нарушение принципа DRY.
Нарушение, действительно. Но с другой стороны, такое сложное обращение говорит о нарушении «закона Деметры». Проблема сложных биндов существует, но она не так остра, потому что решить её можно введя адекватные абстракции.
Справедливости ради стоит отметить, что отличия всё же есть. Здесь я бы хотел высказаться, что лучше начинать с mobile. Как правило, мобильный вариант проще десктопного. Если двигаться от мобильного к десктопному, то получается наращивание фич. Т.е., интерфейс, по достижении некоторых необходимых размеров/наличия требуемых API, начинает приобретать дополнительные черты. Мне этот подход видится очень естественным.
Если же мы двигаемся от десктопа, то для создания мобильной версии мы чаще, напротив, мыслим в терминах выпиливания. При этом все условия для брейкпоинтов больше похоже на хаки, которые подпиливают существующие элементы так, чтобы они себя адекватно в ограниченных условиях.
Единственная причина почему стоит начинать с десктопной версии заключается в том, что десктопная версия уже существует. Это часто случается, когда компания-разработчик решает дополнить своё приложение возможностью работы на мобильных девайсах.
mobile first же делает код более ясным на всех уровнях, от html-кода layout-а, до прикладной логики на JS.
Тут вы ставите правильный вопрос. Действительно, если у нас что-то сложное, то может мы ошиблись на каком-то шаге и придумали нежизнеспособный механизм? Вы предлагаете сделать шаг по улучшению этого механизма.
С моей точки зрения естественное затруднение здесь в головах, а именно в желании сделать доступным все методы «через одну точку». Это желание пихать разные обязанности в один объект приводит к трудностям, которые вы описали. Это же желание погубит и описанный вами метод, хотя он, безусловно, может иметь какие-то преимущества в читаемости. Я считаю тут нужно сделать не один шаг, а два, а именно отказаться от наследования в пользу композиции. Разбивать объект на подсистемы. Тогда пересечение между разнотипными интерфейсами в рамках одного объекта просто исчезнет как явление.
Получаем инфу с помощью dtrace. Визуализируем полученное с помощью stackvis.
А вообще очень надеюсь на подобные возможности в node-inspector (в Chrome DevTools уже можно строить такие профили).
Ещё не совсем понятно, можно ли использовать одного и того же персонажа в противоположных командах или нет (и можно ли использовать по несколько игроков одного класса в команде). Если нельзя, то сравнение с TF2 слабеет, потому что TF2 базируется на девятке архетипичных боевых ролей, которые можно менять в течение раунда, увеличивать количество игроков конкретного класса и брать контр-классы.
За TF2 обидно, конечно, но он сам скатился, без чужой помощи. Если кто-то ещё покормится в этой нише, то пусть кормятся. TF2 не вернуть, так пусть хоть другие развиваются.
Если же мы двигаемся от десктопа, то для создания мобильной версии мы чаще, напротив, мыслим в терминах выпиливания. При этом все условия для брейкпоинтов больше похоже на хаки, которые подпиливают существующие элементы так, чтобы они себя адекватно в ограниченных условиях.
Единственная причина почему стоит начинать с десктопной версии заключается в том, что десктопная версия уже существует. Это часто случается, когда компания-разработчик решает дополнить своё приложение возможностью работы на мобильных девайсах.
mobile first же делает код более ясным на всех уровнях, от html-кода layout-а, до прикладной логики на JS.