Хм, странно звучит. Фреймворк ведь надо для начала проинициализировать так или иначе. Так что так или иначе изначально будет вызван код фреймворка из пользовательского кода.
То что вы определили своё понятие термина framework ещё не говорит о том, что это истина. Всё же есть официальное определение термина, это не парадигма, чтобы трактовать как-то иначе. Если я курицу назову орлом, орлом от этого она не станет. У вас именно библиотека, фреймворк задаёт архитектуру приложения и это главная отличительная черта от библиотеки. У вас архитектура никак не задана. Архитектура поразумевает не только отображение данных.
Вариантов море
1. RAII, в этом случае конструктор объекта создаст внутренние и close в этом случае адекватен, в рамках управляемого кода, в рамках же того же C++ вместо close будет деструктор.
2. DI, здесь close не будет сам закрывать, а просто дёрнет сервис для закрытия внутреннего объекта.
3. Я частенько в своём коде ипользую некие IGuard объекты, следящие за ресурсами, которые сами знают что и как делать.
Если же вы говорите вообще как close в противопоставление factory.create(), то здесь вы не ресурс уничтожаете, вы говорите, что надо бы вычистить внутренее состояние объекта, а не сам объект и это нормально.
В итоге в C# используем IDisposable для этих целей, по нему же и описание ловим и работаем так
using (var foo = factory.Creat())
{
foo.bar();
}
В C++ используем std::unique_ptr как результат фабрики, само удалиться, тут по хорошему работать только с RAII.
Только пользоваться ей как? Если посмотреть на эргономику мышей, то тут некуда прижать большой палец, мизинец с безымянным тоже будут болтаться непонятно где. Кроме понтов ничего не заметно.
Не считаю использование пиратского ПО в таков варианте плохим. Ибо почему издателям и создателям игр можно делать фигню кидая 80% бюджета на рекламу и обманывая игроков. Последнее время тоже так поступаю, хотя т.к. беру в стиме, есть 2 часа вернуть и это происходит очень часто. Перечислять проблемы не буду, сейчас одни и те же проблемы у всех.
"- С тех пор, как мы ввели налог на воздух, вы стали меньше дышать. Это возмутительно! Следующими будут введены налоги на осадки: за простой дождь- 100 лир, за проливной дождь – 200 лир, за дождь с громом и молнией – 300 лир."
Надеюсь этого будет достаточно, чтобы понять? Ибо складывается впечатление, что наши правители считают, что их работа заключается только в выдумывании новых налогов и поборов.
Я знаю что есть, но что они дадут? Что с такими частотами делать? Уж лучше взять тогда DSO138 или DSO150, стоят они ну совсем мало и по качеству будут даже получше звуках, хотя они и не на много лучше, но нет риска спалить смарт.
Как мне кажется упростит, если разработчик понимает, что же такое state machine. Не так давно пришлось делать парсер довольно сложной xml. Сначала была реализация в лоб, вот спагетти там было много. Проблема была в том, что есть куча типов узлов, которые могут иметь родителей разных типов. В итоге код стал абсолютно нечитабельным. Когда понадобилось добавить новый тип узла, так хотелось застрелиться. Переписал же на конечный автомат и вуаля, всё легко, всё понятно и легко расширяемо.
А чего в статье сплошная субьективщина? Где хотя бы графики? Я конечно понимаю, окраску по графику не понять, но по крайней мере будет не пустословие. И чёт ну я не верю в то, что звук прям ваще бомба, в сравнении к примеру c ATH-M50x и ATH-M40x, может даже и более младшими моделями.
Я так понимаю, с матчастью у вас не очень и с телепатией того хуже. Отвечу к одному посту. Да и что-то порёли у вас сравнения то, на чём сидите с пальцем.
CGI и Server-Based, ну как бы сказать, CGI выполняется на стороне клиента и в случае, если используется старый CGI, а не Fast CGI, то это будет очень тормозно, и тут не спасёт ничего, тут даже PHP с модулем для Apache будет быстрее. Ибо при использовании CGI на каждый запрос создаётся новый процесс, что совсем не быстро.
При чём тут вообще как отдаётся JPEG? Если хотите скорость, отдаёте голые данные для графика, подготовленные, ну сотню точек, берёте D3 и строите на стороне клиента. Для 100MHz железки это будет очень сильным облегчением.
REST API требует меньше ресурсов, т.к. нет оверхеда в виде генерации хтмл и очень сильно экономит трафик, ибо гоняет голые данные. Да HTML составит хакеру проблемы, он потратит целых пару минут своей жизни, чтобы написать регулярку, великая проблема. А авторизация вешается отлично и на REST API.
SPA приложение очень хорошо кэшируются браузерами и не надо каждый раз загружать весь код.
REST API поддерживать на слабых железках куда проще, уж доводилось и не нужно тут бычить, если сами не пробовали, не знаете и т.д. REST API никак не избыточен, избыточен классический UI, повторюсь, ибо придётся работать не только с данными, но еще и с оформлением.
Что такое веб-сервер и веб-сайт в вашем понимании? Мне вот именно приходилось заниматься разработкой сервера приложений своё мультиплексирование делать не стал ибо есть готовые решение, использовал boost::asio, при этом использовалась активно и атомарность. Приходилось делать модуль для nginx (выдача баннеров для баннерной системы), который спокойно обрабатывал сотни тысяч запросов в секунду на гружая проц на пару процентов от силы.
Highload оценивается не нагрузкой на проц и ОЗУ, а кол-вом одновременных подключений и скоростью ответа.
Если бы потратили то время, что потратили обкладывая меня, REST API и пытаясь показать свою крутость и удовлетворить своё ЧСВ, на чтение матчасти, провели бы время с большей пользой.
Так я и предлагаю облегчить используя REST API, именно железка, с высокими требованиями к надёжности оперирует только данными не зная про UI, максимум, так она отдаст статику (код приложения). А вот использовать UI как я понял уже можно и на обычном железе.
Хм, странно звучит. Фреймворк ведь надо для начала проинициализировать так или иначе. Так что так или иначе изначально будет вызван код фреймворка из пользовательского кода.
1. RAII, в этом случае конструктор объекта создаст внутренние и close в этом случае адекватен, в рамках управляемого кода, в рамках же того же C++ вместо close будет деструктор.
2. DI, здесь close не будет сам закрывать, а просто дёрнет сервис для закрытия внутреннего объекта.
3. Я частенько в своём коде ипользую некие IGuard объекты, следящие за ресурсами, которые сами знают что и как делать.
Если же вы говорите вообще как close в противопоставление factory.create(), то здесь вы не ресурс уничтожаете, вы говорите, что надо бы вычистить внутренее состояние объекта, а не сам объект и это нормально.
В итоге в C# используем IDisposable для этих целей, по нему же и описание ловим и работаем так
В C++ используем std::unique_ptr как результат фабрики, само удалиться, тут по хорошему работать только с RAII.
И ничего для закрытия вручную не дёргаем.
Надеюсь этого будет достаточно, чтобы понять? Ибо складывается впечатление, что наши правители считают, что их работа заключается только в выдумывании новых налогов и поборов.
На а дальше тролля кормить я не буду. Если же не так, мне вас жаль, о карьерном росте вам придётся забыть. Хотя если только среди равных.
CGI и Server-Based, ну как бы сказать, CGI выполняется на стороне клиента и в случае, если используется старый CGI, а не Fast CGI, то это будет очень тормозно, и тут не спасёт ничего, тут даже PHP с модулем для Apache будет быстрее. Ибо при использовании CGI на каждый запрос создаётся новый процесс, что совсем не быстро.
При чём тут вообще как отдаётся JPEG? Если хотите скорость, отдаёте голые данные для графика, подготовленные, ну сотню точек, берёте D3 и строите на стороне клиента. Для 100MHz железки это будет очень сильным облегчением.
REST API требует меньше ресурсов, т.к. нет оверхеда в виде генерации хтмл и очень сильно экономит трафик, ибо гоняет голые данные. Да HTML составит хакеру проблемы, он потратит целых пару минут своей жизни, чтобы написать регулярку, великая проблема. А авторизация вешается отлично и на REST API.
SPA приложение очень хорошо кэшируются браузерами и не надо каждый раз загружать весь код.
REST API поддерживать на слабых железках куда проще, уж доводилось и не нужно тут бычить, если сами не пробовали, не знаете и т.д. REST API никак не избыточен, избыточен классический UI, повторюсь, ибо придётся работать не только с данными, но еще и с оформлением.
Что такое веб-сервер и веб-сайт в вашем понимании? Мне вот именно приходилось заниматься разработкой сервера приложений своё мультиплексирование делать не стал ибо есть готовые решение, использовал boost::asio, при этом использовалась активно и атомарность. Приходилось делать модуль для nginx (выдача баннеров для баннерной системы), который спокойно обрабатывал сотни тысяч запросов в секунду на гружая проц на пару процентов от силы.
Highload оценивается не нагрузкой на проц и ОЗУ, а кол-вом одновременных подключений и скоростью ответа.
Если бы потратили то время, что потратили обкладывая меня, REST API и пытаясь показать свою крутость и удовлетворить своё ЧСВ, на чтение матчасти, провели бы время с большей пользой.
Моё предложение и строится на этих допущениях.