TCP/IP и в африке tcp/ip. Там дело в тонких настройках таймаутов, стратегий и т.п. В винде по умолчанию настройки выставлены в некий «универсальный» режим. Ковырнув реестр, их можно изменить так, чтобы минимизировать латентность (пинг). Если интересно, гуглите «уменьшить пинг в wow».
Просто надо разделять типы кода. Библиотеки отдельно, с максимальной гибкостью, универсальностью и расширяемостью, по всем канонам ООП и повторным использованием. С конечными классами предметной области все наоборот — надо решать конкретную задачу и забыть про «повторное использование». Вы никогда не будете повторно использовать вашего орка в другом проекте, прямо вот чтобы взять целиком готовый класс и куда-то его воткнуть без изменений. В любом случае будет глубокий рефакторинг. Сидеть и гадать, какие части возможно изменятся в будущем, а какие удастся перенести в будущий проект без изменений — это извините bullshit
Понимаете, наш «орк» — это сложная сущность, и ничего вы с этим не сделаете. Он должен «уметь» отрисовываться, управляться, участвовать в боях и далее по списку. Вы, конечно, можете искусственно «распилить» большой класс на много мелких — с помощью указателей или вложенных объектов, вы также можете «размазать» большие методы по куче вспомогательных классов и шаблонов, если вы боитесь длинных файлов. Но проблема в том, что у любой декомпозиции есть предел, когда дальнейшее уменьшение размеров классов или процедур приводит к усложнению кода, а не к его упрощению. И этот орк — как раз тот случай, когда любое дальнейшее его упрощение — кроме наследования, будет приводит к существенному усложнению кода. Потому что отдельные «интерфейсы» уже не независимы, они должны знать друг о друге. Отрисовка модели меняется по мере прохождения квестов, действия AI сильно зависит от статов и так далее. Если вы вынесете статы в один объект, AI в другой, а 3D модель в третий, вы никаких бонусов кроме дополнительного геморроя не получите.
Я не знаю почему, но те, кто пишут книги по ООП, очень сильно бояться больших классов и методов. Ну, когда работаешь только с простыми, в общем-то, вещами типа стандартных контейнеров или элементов UI, это оправдано. Заставить бы их написать и отладить модель какого-нибудь Навье-Стокса методом Маккормака в криволинейных координатах — глядишь может глаза бы и открылись.
Все имхо разумеется, просто надоело вправлять ООПухоли мозга
Ололо, я хочу посмотреть на реализацию упомянутого выше орка на чистых стратегиях, без наследования. И рядышком на реализацию эльфа. И еще на реализацию квестовой бутылки рома. Хотя бы просто заголовки классов. Сколько у вас будет параметров в шаблонах? 50? 100?
Книги Александреску, Майерса и т.п. — не детективы, их нельзя читать «по диагонали». Тут надо думать над каждым прочитанным словом. В вашем «современном проектировании» есть маленький абзац про то, что шаблоны (стратегии) и виртуальные функции (множественное наследование) не заменяют друг друга, а дополняют. Да-да, есть большая пересекающая область задач, которые можно решить обоими механизмами, но есть и уникальные вещи. Вы не можете выполнить статическое связывание (стратегии) в ситуации, когда вы не знаете, с каким конкретно объектом будете работать. В данной статье — как раз та самая ситуация.
PS. Пример Александреску про doom как-то не видел, поделитесь линком если можно
Да ну?
Представьте, что вы делаете игру про эльфов с орками.
Скажем, объект «орк» должен наследоваться от следующих классов:
1. графический объект, умеющий себя рисовать
2. игровой объект, хранящий «статы» типа силы, ловкости и т.п. и участвующий в обсчете механики
3. сохраняемый объект (для сейвов)
4. Объект, управляемый AI
5. -и/или- объект, управляемый игроком
6. Объект, служащий целью для ударов, заклинаний, разговоров и т.п.
7. Объект, участвующий в квестах (с ним надо поговорить, или убить, или что-то дать, ...)
Все эти 7 классов пересекаются, но ни один из них не вложен в другой класс. И? «Ну не должен наследоваться»?
одному мне хочется иметь всю историю в одном месте?
PS. Скайп не отправляет сообщения в оффлайн, ибо полный р2р. Поднимать централизованные сервера ради мелкой фишки видимо не хотят.
Блин, предыдущий комент рано отправился.
Так вот, сказать «усложнение в несколько раз» нельзя. Если считать по количеству вентилей, то схемы консервативной логики в среднем проще, чем аналогичные традиционные.
Но при этом сам вентиль Фредкина устроен намного сложнее вентиля И-НЕ. Но самое главное, конечно, необхомость использования индуктивностей.
Не, там всё не так.
Сейчас компы работают на базе транзисторов в ключевом режиме. Более 90% тепла выделяется в операции переключения транзисторов между открытым и закрытым состоянием (между 0 и 1). Остальное — это разные паразитные потери. Сами транзисторы, пока их не переключают, потребляют совсем крошечный процент мощности.
Консервативная логика реализуется на колебательных LRC контурах и транзисторах в ключевом режиме. Частоты подобраны так, чтобы колебательные контуры были в резонансе, поэтому реактивное сопротивление схемы почти ноль, активное — копеечное. Переключения транзисторов практически не происходит, поэтому остаются только те самые паразитные 10%.
Проблема только в том, что в отличие от сопротивлений и конденсаторов, в кремнии нельзя сделать катушки (L).
Вы ничего не поняли.
1. Промежуточные результаты, если все инструкции обратимы, хранить не нужно — они пойдут в дело на следующих шагах алгоритма.
2. В реальных алгоритмах да, появляются ненужные побочные результаты. Но они появляются не на каждом шаге, а только в конце алгоритма (те сливы, которые появляются на внутренних шагах, эффективно убиваются инвертной схемой). Вот конечные сливы придется или загонять в память, или рассеивать в пространстве. Но количество этих сливов есть O(N). А требуемое количество вентилей — O(2N). Вот именно это «оно нам даст».
Ну при веб-разработке все достаточно гибко. Условно говоря, есть четыре компетенции: «программист», «дизайнер», «писатель» и «менеджер». При этом талантливому человеку вполне под силу достойно владеть двумя-тремя из них без ущерба для качества. В вебе нет каких-то сверхсложных задач, это вам не физика, где надо 20 лет биться над одной темой, чтобы разобраться что к чему.
сэкономить можно только а) на нормо-часах и б) на стоимости часа. А как там часы распределены между людьми это не столь важно.
Стоимость часа тут и так не запредельная. По часам можно спорить, скажем, верстальщика из статьи явно надо увольнять, но про 60% речь точно не идет.
Я знаю, что правильно «моль», но в тексте почему-то грамм. Ну, если я не ошибаюсь в арифметике, в одном грамме кремния примерно 0.21*1023 атомов, что вполне укладывается в выражение «порядка 1023»… вот только не помню, сколько у одного атома там степеней свободы.
Ну как бы вам сказать, это перевод, а не мое исследование. В оригинале «the two quantities can be identified, the conversion factor being given by relation 1 bit = k ln 2» = «эти две величины (информационную и термодинамическую температуру) можно отождествить, с учетом множителя 1 бит = k ln 2» (вторая страница, последняя строка). И дальше эта фраза много раз повторяется в разных вариантах.
И ничего я не перепутал. Это вы что-то путаете, по крайней мере фразу «электромагнитная энтропия» изобрели вы и сделали это только что, яндекс по крайней мере о таком ничего не слышал.
Не рекомендуется кем и почему? Пруф в студию!
Я не знаю почему, но те, кто пишут книги по ООП, очень сильно бояться больших классов и методов. Ну, когда работаешь только с простыми, в общем-то, вещами типа стандартных контейнеров или элементов UI, это оправдано. Заставить бы их написать и отладить модель какого-нибудь Навье-Стокса методом Маккормака в криволинейных координатах — глядишь может глаза бы и открылись.
Все имхо разумеется, просто надоело вправлять ООПухоли мозга
Книги Александреску, Майерса и т.п. — не детективы, их нельзя читать «по диагонали». Тут надо думать над каждым прочитанным словом. В вашем «современном проектировании» есть маленький абзац про то, что шаблоны (стратегии) и виртуальные функции (множественное наследование) не заменяют друг друга, а дополняют. Да-да, есть большая пересекающая область задач, которые можно решить обоими механизмами, но есть и уникальные вещи. Вы не можете выполнить статическое связывание (стратегии) в ситуации, когда вы не знаете, с каким конкретно объектом будете работать. В данной статье — как раз та самая ситуация.
PS. Пример Александреску про doom как-то не видел, поделитесь линком если можно
Представьте, что вы делаете игру про эльфов с орками.
Скажем, объект «орк» должен наследоваться от следующих классов:
1. графический объект, умеющий себя рисовать
2. игровой объект, хранящий «статы» типа силы, ловкости и т.п. и участвующий в обсчете механики
3. сохраняемый объект (для сейвов)
4. Объект, управляемый AI
5. -и/или- объект, управляемый игроком
6. Объект, служащий целью для ударов, заклинаний, разговоров и т.п.
7. Объект, участвующий в квестах (с ним надо поговорить, или убить, или что-то дать, ...)
Все эти 7 классов пересекаются, но ни один из них не вложен в другой класс. И? «Ну не должен наследоваться»?
PS. Скайп не отправляет сообщения в оффлайн, ибо полный р2р. Поднимать централизованные сервера ради мелкой фишки видимо не хотят.
Так вот, сказать «усложнение в несколько раз» нельзя. Если считать по количеству вентилей, то схемы консервативной логики в среднем проще, чем аналогичные традиционные.
Но при этом сам вентиль Фредкина устроен намного сложнее вентиля И-НЕ. Но самое главное, конечно, необхомость использования индуктивностей.
Сейчас компы работают на базе транзисторов в ключевом режиме. Более 90% тепла выделяется в операции переключения транзисторов между открытым и закрытым состоянием (между 0 и 1). Остальное — это разные паразитные потери. Сами транзисторы, пока их не переключают, потребляют совсем крошечный процент мощности.
Консервативная логика реализуется на колебательных LRC контурах и транзисторах в ключевом режиме. Частоты подобраны так, чтобы колебательные контуры были в резонансе, поэтому реактивное сопротивление схемы почти ноль, активное — копеечное. Переключения транзисторов практически не происходит, поэтому остаются только те самые паразитные 10%.
Проблема только в том, что в отличие от сопротивлений и конденсаторов, в кремнии нельзя сделать катушки (L).
1. Промежуточные результаты, если все инструкции обратимы, хранить не нужно — они пойдут в дело на следующих шагах алгоритма.
2. В реальных алгоритмах да, появляются ненужные побочные результаты. Но они появляются не на каждом шаге, а только в конце алгоритма (те сливы, которые появляются на внутренних шагах, эффективно убиваются инвертной схемой). Вот конечные сливы придется или загонять в память, или рассеивать в пространстве. Но количество этих сливов есть O(N). А требуемое количество вентилей — O(2N). Вот именно это «оно нам даст».
ссылка на «где-то в компьютерре» есть в статье)
Стоимость часа тут и так не запредельная. По часам можно спорить, скажем, верстальщика из статьи явно надо увольнять, но про 60% речь точно не идет.
И ничего я не перепутал. Это вы что-то путаете, по крайней мере фразу «электромагнитная энтропия» изобрели вы и сделали это только что, яндекс по крайней мере о таком ничего не слышал.