alexprey, набрали джуниоров и отправили говнокодить низкоприоритетный проект, назначив в сопровождение пару миддлов-кураторов из основной ветки, если это так важно.
Преимущество адаптеров, врапперов и фасадов перед матодами расширения в том, что в один враппер можно собрать сразу несколько перекликающихся дополнительных методов, плюс там можно хранить дополнительные поля, недостающие исходному классу - методы расширения не дают второго в принципе, а первое дают условно - можно в один класс собирать все методы расширения для одного класса, но это не позволит, например, провернуть трюк с наследованием от враппера и переопределением какого-нибудь дополнительного метода.
Что касается необходимости обновлять врапперы и фасады при добавлении новых методов в базовый класс, то это не совсем так - в фасад, а уж тем более в адаптер методы из базового класса добавляются по мере необходимости их использования в том коде, который работает с фасадом - зачастую задача адаптера скрыть частично или полностью контракт чужого класса, подменив его собственным. А в случае с врапперами так и вовсе нет необходимости реализовывать во враппере контракт базового класса - достаточно той функциональности, которая требуется, а в остальном с базовым классом можно работать и напрямую, при желании завернув это все в еще один слой, состоящий из адаптера или фасада.
В целом, причины избегать методов расширения совпадают с причинами избегать статических методов как таковых - сильно падает гибкость и расширяемость кода при злоупотреблении статическими методами, да и юниттесты в таких условиях писать это ад. Плюс к этому добавляются проблемы вида "а что если в базовом классе появится метод с тем-же именем и функциональностью, которые есть у существующего метода расширения?", "а как себя ведут методы расширения при наследовании?" и другие.
К сожалению, в отличии от простых статических методов, законно занимающих нишу таких фундаментальных вещей, как математические вычисления, такой ниши для методов расширения я не вижу, не считая работы с массивами, но для этого есть коллекции. С натяжкой можно предположить что с помощью методов расширения можно дополнить операции с векторами, а также упомянуть про возможность переопределить операторы, добавив к своим классам возможность использоваться в качестве операндов, но эти две возможности я нахожу весьма сомнительными. Во-первых векторным операциям место в самих классах векторов. Во-вторых использование математических операторов для пользовательских классов имеет существенный недостаток - далеко не всегда очевидно что автор подразумевал, например, под сложением, а классическая реализация через метод класса позволяет постараться дать более-менее красноречивое имя методу.
На этом все, что касается моего отношения к методам расширения.
Что касается статей - я если и буду что-то писать с нуля, то по чему-нибудь более экзотическому, чем миллион раз обсосанные основы языка Java, которые намного лучше описаны в той-же "Think in Java", чем получится у меня. Например, по программной архитектуре или по работе с Lua, в крайнем случае по каким-нибудь специфичным применениям движка JmonkeyEngine3, да и по Action Script практически не паханое поле.
Автор: Robert C. Martin
Название: Clean Code (полное название отличается в оригинале и переводах, так что оставил только базовую часть названия, которая совпадает)
Категория: Стиль написания кода / Методы разработки
Язык: Java, но применимо к любому языку в той или иной степени.
Порог вхождения: базовые знания любого объектного языка, не обязательно Java. При продвижении вглубь книги требования постепенно растут, а количество кода в примерах увеличивается.
Во многом перекликается с макконнеловским совершенным кодом, упомянутым выше. Представляет собой смесь из жизненных историй автора, связанных с программированием, рекомендаций по написанию хорошего кода, философствования на тему этого самого хорошего кода и огромного количества практических материалов с пояснениями, иллюстрирующих все вышеперечисленное.
Рекомендована к прочтению всем, много раз. Читать "расслаблено лежа на диване" не очень получится ввиду возрастающего количества практических примеров, осмысление которых требует изрядно поработать головой. Прочесть "от корки до корки" также не получится, по крайней мере с первого раза - для осмысления некоторых концепций может потребоваться довольно много времени.
Для ленивых, русский перевод этой книги прилагается в прикрепленном файле.
alexprey, C# вызывает у меня дикий когнитивный диссонанс, как можно было понять из оффтопа в прошлом комментарии. А полезное для сайта я делать пытался, пока время позволяло - переводил статьи по JmonkeyEngine3 и еще вернусь к этому, даже не смотря на полное отсутствие востребованности этой темы.
Что касается методов расширения, расскажу одну маленькую историю из своей жизни: было дело, работал я на C# и выпало мне поддерживать библиотеку, написанную задолго до моего прихода в проект. Так получилось, что эта библиотека понадобилась одной из групп разработчиков на смежном проекте.
И вот, приходят ко мне с вопросом "как пользоваться методом Revitalize для объекта типа LostRequest? Мы его и так и эдак, а ему хоть бы хны - фиолетовый" имена методов и классов, а также пароли и явки взяты произвольно из соображений анонимности. Я то помню что такого метода в нашей библиотеке нет и быть не может, потому в первую очередь спрашиваю не используют ли они какую-то самопальную модификацию, но нет, ничего такого.
Потом вспоминаю про методы расширения и мягко уточняю не пользуются ли они чем-то таким, но и тут все чисто - не писали, не употребляли, не привлекались. В итоге мне пришлось скачать и развернуть у себя их проект, весивший, к слову, пару гигов со всеми необходимыми составляющими. И все только для того, чтобы в другой библиотеке обнаружить этот-самый метод-расширение, расширявший класс из нашей библиотеки.
Мораль - реализация этого расширения через фасад, адаптер, агрегацию или любым другим применимым в данном случае архитектурным паттерном значительно упростила бы жизнь, как минимум, пяти программистам ценой лишних десяти минут работы одного программиста.
Extravert, лично я шел в школу с твердой уверенностью что на ноль делить можно и это доставило мне в свое время немало проблем, не говоря уже об уверенности что если из единицы вычесть два, то получится не ноль, а минус единица.
К чему это я? Наверно к тому, что осваивать программирование, как правило, начинают все-же не в первом классе, а уже более зрелые личности, способные к мыслительной деятельности повыше уровнем чем "добавим пять слонов к девяти бананам". Да и синтаксический сахар вроде методов расширения это явно не первое, чему должен учиться человек, начинающий изучать программирование, а значит и статья на эту тему не обязательно должна быть написана в столь аскетичной манере.
Не говоря уже о том, что конкретно методы расширения есть зло, нарушающее принципы ООП и взрывающее мозг почитателям более-менее грамотной архитектуры приложения, а также поборникам чистоты, читаемости и самодостаточности кода. И да, вот еще что, имена методов с большой буквы - ааааа моооииии глаааазааааа!
P.S. так-то статья составлена достаточно грамотно, ничего личного.
alexprey, есть рацпредложение: если люди сильно хотят подписи на сайте - почему бы их не добавить, но только не к каждому комментарию, а к ресурсам? Естественно, с возможностью выбрать "не добавлять подпись" при создании ресурса.
П4ела, лучше не совмещать слегка похожие вещи, а реализовать две разных системы - одну для скриншотов в 360, а другую - для моделей. Естественно, с динамической подгрузкой и того и другого чтобы не грузить ничего лишнего.
П4ела, что значит только модели? Анимации там тоже есть, если что. Чего еще не хватает для превью? Эффектов разве что, но они слишком сильно под разные движки разнятся чтобы на каком-то одном способе их отображения остановиться, а адаптировать под все часто используемые стандарты это упороться можно.
Вынужден предварительно отозвать свою заявку на участие. Причина - срыв сроков по проекту на работе в реале и, как следствие, отсутствие времени на конкурсную работу. Есть крохотный шанс что до следующих выходных все уже разрешится и мне удастся за два дня превратить набор разрозненных технических демок во что-то играбельное, но нужно быть хроническим оптимистом чтобы ставить на это.
alexprey, к сожалению, подумываю о снятии с конкурса - очень тяжелый месяц на работе выпал. Продолжать разработку буду, но сперва нужно на работе разгрести завал - спать то тоже когда-то надо.
ScorpioT1000, основы винды и линукса даже у меня в универе были, как и сетевые технологии - на специальности "информатика". Но я бы не сказал что полученные там знания офигеть как пригодятся на практике, особенно в геймдеве, а я перечислял более-менее универсальные вещи.
Хотя если где-то дают грамотную работу с сетью вместо унылого теоретического курса по низкоуровневой и зачастую устаревшей реализации сетевого взаимодействия, то я только рад за тех, кому так повезло.
я голосовал как потенциальный участник, но если турнир будет сразу после завершения регистрации, то я скорее всего пролетаю - сейчас небольшой завал на работе плюс игру на конкурс все-же хочу успеть до играбельного состояния довести
Mihahail, обычно и C++ выпускник только думает что знает, а если копнуть, то оказывается что ничерта он не знает. Из того что реально полезного можно вынести: принципы ООП, основы и синтаксис как минимум одного языка, некоторые интересные алгоритмы и если повезет, то еще паттерны проектирования. Остальное самостоятельно или если ну очень повезет.
Некоторым еще более-менее дают работу в многопоточной среде и эффективную работу с бинарными данными. На более узкоспециализированных факультетах еще бывает появляются принципы сжатия и шифрования данных.
Еще бывает везет на хороший курс по базам данных.
Существует лимит то ли на кол-во операций, то ли на время выполнения, то ли и на то и на другое. При превышении лимита поток молча рубится.
В качестве шаманства: попробуй завернуть каждый цикл в отдельную функцию. Врядли это поможет само по себе, но зато потом проще будет переходить к следующему шагу - разнесению на отдельные потоки.
Эльрат, завал на работе он такой - вечно возникает в самый неподходящий момент. По плану у меня уже должна была быть готова базовая генерация мира, нормальный чанк-менеджмент, выгрузка карты на диск, кисти для редактирования мира, один игровой персонаж и физика столкновений. Вот когда будет работать хотя бы это - будут и скриншоты.
Есть мнение, что через какое-то время карты из наград станут доступны обычным способом (крафт и бустеры), а игроки, прошедшие кварталы до того момента, получат ачивку и/или золотую версию наградных карт и/или уникальный стилизованный скин для обратной стороны карт. Естественно, с открытия Наксрамаса до вброса наградных карт в общий пул пройдет не месяц и, наверно, даже не два.
BruceWillisss, найти и скачать софт для записи видео, настроить его, проверить работоспособность и качество записи - раз. Сыграть минимум десяток игр чтобы освоиться с колодой - два. Отыграть от одной до трех и более игр в рамках турнира, в зависимости от кол-ва участников и успешности игры - три.
я бы сыграл, даже неплохая колода еще сохранилась из стартовых карт, но не знаю будет ли у меня время, да и сильно заморачиваться с записью видео не охота.
Ред. prog
» Программирование / Методы расширений
» Программирование / Полезная литература
Название: Clean Code (полное название отличается в оригинале и переводах, так что оставил только базовую часть названия, которая совпадает)
Категория: Стиль написания кода / Методы разработки
Язык: Java, но применимо к любому языку в той или иной степени.
Порог вхождения: базовые знания любого объектного языка, не обязательно Java. При продвижении вглубь книги требования постепенно растут, а количество кода в примерах увеличивается.
Ред. prog
» Программирование / Методы расширений
Ред. prog
» Программирование / Методы расширений
» Администрация XGM / подпись более 3 строк, путаюсь в сообщениях очень =(
» Блог им. AlexPrey'я / XGM Update Log
» Блог им. AlexPrey'я / XGM Update Log
» Game Boom / Game Boom #2: Спасибо, что живой!
» Requested Eternity / Requested Eternity
» XGM Конкурсы / Первый XGM-турнир по Hearthstone: один шаг
» XGM Конкурсы / Первый XGM-турнир по Hearthstone: один шаг
» XGM Конкурсы / Первый XGM-турнир по Hearthstone: один шаг
» Программирование / Программирование
Хотя если где-то дают грамотную работу с сетью вместо унылого теоретического курса по низкоуровневой и зачастую устаревшей реализации сетевого взаимодействия, то я только рад за тех, кому так повезло.
» Game Dev / Нордический обелиск
» XGM Конкурсы / Первый XGM-турнир по Hearthstone: опрос
Ред. prog
» Программирование / Программирование
Некоторым еще более-менее дают работу в многопоточной среде и эффективную работу с бинарными данными. На более узкоспециализированных факультетах еще бывает появляются принципы сжатия и шифрования данных.
Еще бывает везет на хороший курс по базам данных.
» WarCraft 3 / Ограничение действий в циклах
» Requested Eternity / Requested Eternity
» Game Boom / Game Boom #2: Спасибо, что живой!
» Game Boom / Game Boom #2: Спасибо, что живой!
» Hearthstone / Режим приключений в Hearthstone: «Проклятие Наксрамаса»
» XGM Конкурсы / Первый XGM-турнир по Hearthstone
» XGM Конкурсы / Первый XGM-турнир по Hearthstone
Ред. prog
» XGM Конкурсы / Первый XGM-турнир по Hearthstone
» Hearthstone / Наши игроки