Чем движок отличается от фреймворка
Framework — термин, имеющий размытое значение. Обычно используется в программировании, обозначая «простую концептуальную структуру, используемую для решения сложной, проблемной задачи» . Значение этого термина существенно зависит от контекста его использования.
Conceptual Framework — абстрактная структура, используется в исследованиях для определения возможных способов решения проблемы, или представления идеи.
Software Framework — каркас программной системы (или подсистемы) . Может включать вспомогательные программы, библиотеки кода, язык сценариев и другое ПО, облегчающее разработку и объединение разных компонентов большого программного проекта. Обычно объединение происходит за счёт использования единого API.
Примеры: системы управления контентом (CMS).
Отличается от библиотеки (library) тем, что выполняет код написанный для него, а не исполняется сам. Пример программного каркаса — CMF (Content Management Framework), а пример библиотеки — модуль email.
Также в отличие от библиотеки, которая объединяет в себе набор близкой функциональности, framework содержит в себе большое число разных по тематике библиотек.
Application Framework — каркас приложения (открытая инфраструктура приложения) . Это software framework, который используется, чтобы обеспечивать выполнение стандартной структуры приложения для определённой операционной системы. Каркасы приложения стали популярны с появлением GUI, который имел тенденцию к распространению стандартой структуры для приложений. С их использованием стало гораздо проще создавать средства для автоматического создания GUI, так как структура внутренней реализации кода приложения стала известна заранее. Для обеспечения каркаса обычно используются техники объектно-ориентированного программирования, например части приложения могут наследоваться от базовых классов фреймворка.
Один из первых коммерческих каркасов приложения был MacApp, написанный Apple Computer под Macintosh. Первоначально созданный с помощью расширенной (объектно-ориентированной) версии языка Паскаль, впоследствии он был переписан на C++. Другие популярные каркасы для Macintosh включали Metrowerks Powerplant и MacZoop (все основаны на Carbon)
Также существуют каркасы, которые создают одинаковые приложения для Linux, Macintosh и Windows из одного и того же исходного кода, например widget toolkit, wxWidgets, Qt или FOX toolkit.
Framework — термин, имеющий размытое значение. Обычно используется в программировании, обозначая «простую концептуальную структуру, используемую для решения сложной, проблемной задачи» . Значение этого термина существенно зависит от контекста его использования.
Conceptual Framework — абстрактная структура, используется в исследованиях для определения возможных способов решения проблемы, или представления идеи.
Software Framework — каркас программной системы (или подсистемы) . Может включать вспомогательные программы, библиотеки кода, язык сценариев и другое ПО, облегчающее разработку и объединение разных компонентов большого программного проекта. Обычно объединение происходит за счёт использования единого API.
Примеры: системы управления контентом (CMS).
Отличается от библиотеки (library) тем, что выполняет код написанный для него, а не исполняется сам. Пример программного каркаса — CMF (Content Management Framework), а пример библиотеки — модуль email.
Также в отличие от библиотеки, которая объединяет в себе набор близкой функциональности, framework содержит в себе большое число разных по тематике библиотек.
Application Framework — каркас приложения (открытая инфраструктура приложения) . Это software framework, который используется, чтобы обеспечивать выполнение стандартной структуры приложения для определённой операционной системы. Каркасы приложения стали популярны с появлением GUI, который имел тенденцию к распространению стандартой структуры для приложений. С их использованием стало гораздо проще создавать средства для автоматического создания GUI, так как структура внутренней реализации кода приложения стала известна заранее. Для обеспечения каркаса обычно используются техники объектно-ориентированного программирования, например части приложения могут наследоваться от базовых классов фреймворка.
Один из первых коммерческих каркасов приложения был MacApp, написанный Apple Computer под Macintosh. Первоначально созданный с помощью расширенной (объектно-ориентированной) версии языка Паскаль, впоследствии он был переписан на C++. Другие популярные каркасы для Macintosh включали Metrowerks Powerplant и MacZoop (все основаны на Carbon)
CSS-фреймворк — это библиотека, подразумевающая более
простое, совместимое со стандартами оформление страниц,
с использованием каскадных таблиц стилей. Так же, как и
в различных языках программирования, такой фреймворк —
это набор готовых приёмов, который, в данном случае,
используется для вёрстки веб-страниц.
Фреймворк ближе относится к понятию дизайна архитектуры программы, чем к классам и паттернам.
Классы - это самый низкий уровень программы написанной на объектно-ориентированном языке, на основе классов создаются объекты обладающие состоянием и ПОВЕДЕНИЕМ (методами), которые меняют состояние объекта. например метод Лети - заставляет объект лететь и рассчитывать траекторию полета. Объект летчик, вызывает метод объекта самолет и тот летит. Самолет в свою очередь оповещает летчика о параметрах полета, чтобы летчик на основе этих данных мог принимать решения и дергать иные методы самолета, управляя им. Так можно сказать что обязанности (методы) этих объектов распределены и связаны.
Паттерны проектирования - это описание наиболее оптимальных способов ГРУППИРОВКИ объектов и РАСПРЕДЕЛЕНИЯ между ними обязанностей (МЕТОДОВ) для решения какой-то ОТДЕЛЬНОЙ ЗАДАЧИ, часто возникающей перед программистом, пишущим ЛЮБУЮ программу.
Фреймворк это архитектурное решение состоящее из ГРУППИРОВКИ различных ПАТТЕРНОВ проектирования и иных специфичных РЕШЕНИЙ по распределению обязанностей (оно же поведений, оно же методов) на уровне разработки дизайна архитектуры для целого КЛАССА ПРОГРАММ.
Например одни фреймворки созданы для класса программ, создающих графический интерфейс (JAVAFX) другие для создания веб сайтов (Spring WEB MVC) и так далее. В том же Спринге существует несколько видов этого фреймворка, помогающего писать тот или иной класс программ.
ЛИчно я сравниваю фреймворк с книжкой раскраской. Есть некоторый скелет, очертания фигуры, которые мы уже потом закрашиваем кодом подгоняя под наши вкусы и конкретную ситуацию. Фреймворк может содержать ттак же какие -то готовые реализованные классы, в нашем случае пусть это будут цвета без примесей в стандартном наборе красок из магазина, мы можем закрашивать наш краскас ими, а можем и сами расширить поведение методов фреймворка переопределяя методы его классов и таким образом смешивать и создавать наши собственные цвета.
Фрейморк - это реализация и использование опыта и накопленных знаний о том классе программ для которых он написан, те цвета и ту форму которую для вас разработали и просчитали опытные разработчики вы можете теперь использовать и разрисовывать своими или уже готовыми цветами. Это существенно ускоряет и упрощает процесс разработки, что особенно важно для бизнес приложений, так как бизнес ждать не любит. Однако знание фреймворка демотивирует вас в изучении основ языка, его инструментальных библиотек и паттернов проектирования, ведь за вас уже сделали большую часть работы, все продумали и все спроектировали. Осталось дергать за готовые методы и этого вполне достаточно, чтобы сделать приличное приложение или веб сервис. Это надо иметь в виду и всегда спрашивать себя - а как бы я нарисовал это животное или фигуру если бы я сам создавал книжку раскраску, какой бы набор стандартных цветов создал я, наиболее подходящий для этого класса сущностей?
igo
> фреймворк универсален, движек заточен.
>
> фреймворк тоже по своему заточен.
>
> движек тоже по своему универсален.
-> фреймворк универсален и заточен, движок заточен и универсален. хд
Laynos
движок - это фреймворк + набор тулзов (редактор мира, редактор логики, упаковщик ресурсов. )
bazhenovc
странно:) а я думал наборот
Фреймворк - всего лишь каркас, дающий некоторый начальный функционал.
Пользователю предлагается его расширять до достижения требуемого результата.
От библиотеки имеет некоторые отличия - накладывает некие ограничения на структуру программы.
Движок - комплекс програмных модулей, облегчающий создание конечного продукта вплоть до полного отсутсвия программирования.
Может включать в себя также библиотеки и фреймворки.
Так что практически все то самописное говно, которое мы называем движками, на самом деле библиотеки, или в лучшем случае фреймворки.
Если что, это всего лишь мое мнение, которое может быть спорным.
Laynos
> Движок и фреймворк. Какая разница?
Всё очень просто.
Если тебе что-то нравиться, то это движок, а если не нравиться, то это Фреймворк.
Фремворк - это то , что работает хорошо но медленно.
Движок - это то , что работает плохо , но быстро :)
Движок сам крутит игровой цикл как ему надо, фреймворк предоставляет эту радость тебе.
alexzzzz
полностью согласен
движок от фреймворка отличает наличие мэйнлупа
Фреймворк нужно допиливать, движок уже готов к использованию.
Фреймворк - просто добавь воды :)
И будет Юпи !
alexzzzz
Mephisto std
XNA/Monogame крутят сами цикл. но это фреймворки
ИМХО
Фреймворк - это общее название для любой "структуры программной системы, которая облегчающая разработку и объединение разных компонентов большого программного проекта".
Движок - это специализированное название фреймворка.
По сути движок - это и есть фреймворк.
Мне кажется разница только в том, что
движок не позволяет менять архитектуру своей работы, а значит и всего программного проекта.
Фреймворк же предназначен для облегчения создания этой архитектуры.
ronniko
> Фреймворк - просто добавь воды :)
> И будет Юпи !
Ты опять? Теперь не картинки, теперь тупое видео? И ты еще спрашиваешь почему к тебе так относятся?
Не секрет, что каждый уважающий себя программист обязан иметь свой движок. Но интересное дело: а нужен ли именно движок?
Для начала давайте определимся, что же такое "движок". ИМХО, это средство разработки приложений определенной направленности. То есть, например, движок для стратегий или для FPS. При этом на движке для шутера крайне сложно написать стратегию. Причины, думаю, ясны.
Так вот: так уж ли нужен именно движок? Не лучше ли написать некий фреймворк, который будет предоставлять базовый функционал для написания любых приложений? Например, он должен содержать в себе удобную работу с геометрией, проверку столкновений, надстройки и обертки над графическим API, проигрывание звука, базовый сетевой функционал, и так далее. Но при этом не быть движком. То есть конечный пользователь этого фреймворка (программист) получает удобный набор инструментов и не более. При этом он волен писать что угодно с его использованием.
Или я в чем-то заблуждаюсь, и описанный фреймворк можно считать движком? Есть ли вообще грань между этими двумя понятиями?
Ну, если фреймворк/набор фреймворков, может всё то же, что и движок, то тогда - это. движок. Ну и, наоборот.
Sergio
> Есть ли вообще грань между этими двумя понятиями?
Хороший вопрос я тоже о нём задумывался. В итоге на мой взгляд термин "игровой движок" это синоним "фреймворк для разработки игры".
Фреймворк (англ. framework, Каркас) — в информационных системах структура программной системы; программное обеспечение, облегчающее разработку и объединение разных компонентов большого программного проекта. В отличие от библиотек, которые объединяют набор подпрограмм близкой функциональности, фреймворк содержит в себе большое количество разных по назначению библиотек. Употребляется также слово «каркас», а некоторые авторы используют его в качестве основного, в том числе не базируясь вообще на англоязычном аналоге.[1][2][3] Можно также говорить о каркасном подходе[3] как о подходе к построению программ, где любая конфигурация программы строится из двух частей: первая, постоянная часть — каркас, не меняющийся от конфигурации к конфигурации и несущий в себе гнезда, в которых размещается вторая, переменная часть — сменные модули (или точки расширения).
Когда я свой движок пописывал в своё время я сразу интуитивно так и называл его в документации как "каркасс". По англосаксонски - фреймворк и всего лишь.
=A=L=X=
Ну смотри. На примере рендера, как самой больонй для нас темы :)
Большинство движков имеют свой рендер. Некоторые позволяют что-то там добавить/отключить. Но кардинально изменить рендер (скажем переделать forward на deferred shading) у конечного программиста не получится. Так что движок накладывает ограничения на функционал. Фреймворк же изначально не имеет никаких ограничений, потому что рендер (саму последовательность команд) конечный программист пишет сам.
Sergio
> Фреймворк же изначально не имеет никаких ограничений
Не секрет, что каждый уважающий себя программист обязан иметь свой движок. Но интересное дело: а нужен ли именно движок?
Для начала давайте определимся, что же такое "движок". ИМХО, это средство разработки приложений определенной направленности. То есть, например, движок для стратегий или для FPS. При этом на движке для шутера крайне сложно написать стратегию. Причины, думаю, ясны.
Так вот: так уж ли нужен именно движок? Не лучше ли написать некий фреймворк, который будет предоставлять базовый функционал для написания любых приложений? Например, он должен содержать в себе удобную работу с геометрией, проверку столкновений, надстройки и обертки над графическим API, проигрывание звука, базовый сетевой функционал, и так далее. Но при этом не быть движком. То есть конечный пользователь этого фреймворка (программист) получает удобный набор инструментов и не более. При этом он волен писать что угодно с его использованием.
Или я в чем-то заблуждаюсь, и описанный фреймворк можно считать движком? Есть ли вообще грань между этими двумя понятиями?
Ну, если фреймворк/набор фреймворков, может всё то же, что и движок, то тогда - это. движок. Ну и, наоборот.
Sergio
> Есть ли вообще грань между этими двумя понятиями?
Хороший вопрос я тоже о нём задумывался. В итоге на мой взгляд термин "игровой движок" это синоним "фреймворк для разработки игры".
Фреймворк (англ. framework, Каркас) — в информационных системах структура программной системы; программное обеспечение, облегчающее разработку и объединение разных компонентов большого программного проекта. В отличие от библиотек, которые объединяют набор подпрограмм близкой функциональности, фреймворк содержит в себе большое количество разных по назначению библиотек. Употребляется также слово «каркас», а некоторые авторы используют его в качестве основного, в том числе не базируясь вообще на англоязычном аналоге.[1][2][3] Можно также говорить о каркасном подходе[3] как о подходе к построению программ, где любая конфигурация программы строится из двух частей: первая, постоянная часть — каркас, не меняющийся от конфигурации к конфигурации и несущий в себе гнезда, в которых размещается вторая, переменная часть — сменные модули (или точки расширения).
Когда я свой движок пописывал в своё время я сразу интуитивно так и называл его в документации как "каркасс". По англосаксонски - фреймворк и всего лишь.
=A=L=X=
Ну смотри. На примере рендера, как самой больонй для нас темы :)
Большинство движков имеют свой рендер. Некоторые позволяют что-то там добавить/отключить. Но кардинально изменить рендер (скажем переделать forward на deferred shading) у конечного программиста не получится. Так что движок накладывает ограничения на функционал. Фреймворк же изначально не имеет никаких ограничений, потому что рендер (саму последовательность команд) конечный программист пишет сам.
Sergio
> Фреймворк же изначально не имеет никаких ограничений
Так в чём на самом деле разница между фрэймворком, библиотекой и API? Есть мнение, что всё это близкие понятия, везде есть классы и методы которые можно встроить в клиентский код. И всё же, похоже есть существенные отличия?
Метафорически — библиотека — это часть приложения. Фрэймворк — это скелет, API – внешние части указанного приложения. Фрэймворк, ко всему прочему, в отличии от API использует инверсию управления.
Начнём с API. Это самый простой вариант: возможность для приложения обратиться к коду вне этого приложения. Это набор функциональности для того, чтобы заставить внешнюю для программы сущность сделать свою работу.
Пример из реальной жизни: у вас есть в квартире водопровод, а API — телефон сантехника, который этот водопровод может починить, если надо.
Теперь, библиотека — это готовый к использованию набор кода, который бежит в контексте приложения, и точно так же выполняет свою работу. То есть библиотека становится при подключении частью приложения. Разница между библиотекой и API может быть довольно тонкой: например, WinAPI предоставляет функциональность, которая в общем-то иногда происходит и в рамках процесса. Тем не менее, это считается обращением к внешней для приложения платформе.
Пример из реальной жизни: вы сами не сколачиваете шкаф, а покупаете домой готовый, ставите в свою квартиру и пользуетесь им. Шкаф — ваша подключаемая библиотека.
Ну и фреймворк — его функции, в отличие от библиотеки, не вызываются вами, а наоборот, ваш код вызывается из него. Фреймворк можно представить себе в виде полуфабриката приложения, к которому вы дописываете нужную функциональность сами.
Пример из реальной жизни: вы покупаете почти готовую квартиру, а мебель, обои и шкафы добавляете сами. Квартира — ваш фреймворк, она уже почти готова. Вы не можете так просто переделать число комнат или превратить её в корабль, вместо этого вы только добавляете внутреннюю функциональность: паркетный пол, махровый халат в ванной и кота.
Читайте также: