Здравствуйте, VladD2, Вы писали:
VD>Кто-нибудь может дать внятное определение термину Framework? VD>Википедевое не предлагать. Оно не внятное.
Набор публичных библиотек, образующих большую систему и призванных облегчить (упростить, ускорить, предоставить готовые проверенные решения) разработку приложений в определенной предметной области или на определенных языках.
Здравствуйте, MozgC, Вы писали:
MC>Набор публичных библиотек, образующих большую систему и призванных облегчить (упростить, ускорить, предоставить готовые проверенные решения) разработку приложений в определенной предметной области или на определенных языках.
А зачем для вполне понятного понятия набор библиотек вводить отдельное понятие?
Да и почему сразу набор? То есть получается складываем две библиотеки в кучу и получаем фрэймворк?
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, lomeo, Вы писали:
VD>>Кто-нибудь может дать внятное определение термину Framework?
L>Набор (связанных) подходов (библиотек, другого reusable кода) для решения (связанных) типовых задач.
Вот возьмем к примеру Qt. Это вроде как считается библиотекой. Но ведь по этому определению — это скорее фрэймворк. Там ведь и дизайнер форм есть. И библиотек куча. И подход явно просвечивает.
Так где же эта грань отделяющая библиотеки или подходы от фрэймворка?
ЗЫ
Это только мне кажется что слово Framework является эдаким цензурным синонимом слова "хреновина"?
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
MC> Набор публичных библиотек, образующих большую систему и призванных облегчить (упростить, ускорить, предоставить готовые проверенные решения) разработку приложений MC> в определенной предметной области или на определенных языках.
Склонен считать, что это не набор библиотек, а именно каркас.
"Набор библиотек" берет на себя решение набора наборов маленьких "типовых задач" (музычку проиграть, картинку нарисовать и пр.)
Каркас же "диктует" "способ организации" разрабатываемого приложения.
И вот как раз редкий каркас будет "облегчать разработку в определенной предметной области".
Он обеспечит разработку определенным образом организованных (внутри) приложений.
Если по простому, то используя библиотеку, Вы делаете вызовы к ней. Используя фреймворк, Вы, по большей части предоставляете ему Ваши "прикладные" колбэки.
Здравствуйте, dorofeevilya, Вы писали:
VD>>Так где же эта грань отделяющая библиотеки или подходы от фрэймворка?
D>Framework — это некоторый шаблон программы с определенными местами, в которые необходимо вставить свой код, чтобы получить требуемое поведение.
Вот это определение совсем из пальца высосана. Под него подходят разве что Визарды в IDE. Плюс оно базируется на не менее не определенном понятии "шблон".
Скажем классический пример фрэймворка — Cybernate. Куда там свой код то вставлять?
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, dorofeevilya, Вы писали:
D>Framework — это некоторый шаблон программы с определенными местами, в которые необходимо вставить свой код, чтобы получить требуемое поведение.
Кстати, можно источник этого определения дать?
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
VD>Так где же эта грань отделяющая библиотеки или подходы от фрэймворка?
[К.О.]
Наличие общего подхода/стиля?
[/К.О.]
Разница в том, как их готовят: библиотеки просто используются в приложении для решения прикладных задач и редко влияют на стиль кода/применяемые паттерны, а фреймворк играет роль эдакого слоя абстракции над языком и влияет весьма заметно.
VD>Это только мне кажется что слово Framework является эдаким цензурным синонимом слова "хреновина"?
Хреновина — это универсальный синоним
Здравствуйте, VladD2, Вы писали:
VD>Здравствуйте, dorofeevilya, Вы писали:
D>>Framework — это некоторый шаблон программы с определенными местами, в которые необходимо вставить свой код, чтобы получить требуемое поведение.
VD>Кстати, можно источник этого определения дать?
Недавно читал в какой-то книге, но сейчас не смог с ходу найти.
Здравствуйте, VladD2, Вы писали:
VD>Здравствуйте, dorofeevilya, Вы писали:
VD>>>Так где же эта грань отделяющая библиотеки или подходы от фрэймворка?
D>>Framework — это некоторый шаблон программы с определенными местами, в которые необходимо вставить свой код, чтобы получить требуемое поведение.
VD>Вот это определение совсем из пальца высосана. Под него подходят разве что Визарды в IDE. Плюс оно базируется на не менее не определенном понятии "шблон".
Я не претендую на строгость определения. Просто попытался передать суть своими словами.
VD>Скажем классический пример фрэймворка — Cybernate. Куда там свой код то вставлять?
Не знаю, что такое Cybernate.
Фреймворки, которые подходят под мое "определение": ASP.NET, WCF, Entity Framework, Nunit, WWF и пр.
Здравствуйте, dorofeevilya, Вы писали:
VD>>Вот это определение совсем из пальца высосана. Под него подходят разве что Визарды в IDE. Плюс оно базируется на не менее не определенном понятии "шблон". D>Я не претендую на строгость определения. Просто попытался передать суть своими словами.
Дело в том, что это совсем не верное определение, противоречащее всем другим данным рядом, но я уже разок его видел. Очень интересен источник.
VD>>Скажем классический пример фрэймворка — Cybernate. Куда там свой код то вставлять? D>Не знаю, что такое Cybernate.
Сори, не правильно написал название. Имелось в виду — Hibernate.
D>Фреймворки, которые подходят под мое "определение": ASP.NET, WCF, Entity Framework, Nunit, WWF и пр.
Ну, и как перечисленные вещи сочетаются с определением "некоторый шаблон программы с определенными местами, в которые необходимо вставить свой код"? Куда в Entity Framework, скажем, вставить свой код? Где в Nunit этот загадочный шаблон? И что это вообще такое?
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, ylem, Вы писали:
MC>> Набор публичных библиотек, образующих большую систему и призванных облегчить (упростить, ускорить, предоставить готовые проверенные решения) разработку приложений MC>> в определенной предметной области или на определенных языках.
Y>Склонен считать, что это не набор библиотек, а именно каркас.
Ага. Ну, и что же такое этот самый загадочный карскас?
Y>"Набор библиотек" берет на себя решение набора наборов маленьких "типовых задач" (музычку проиграть, картинку нарисовать и пр.) Y>Каркас же "диктует" "способ организации" разрабатываемого приложения.
ОК. Возмем к примеру WinForms или MFC. Это что? Каркас/фрэймворк или все же библиотеки? Под размытое определение фрэймворка они подходят идеально. И даже под твое. Они обе определяют "способ организации". Разве нет? Тогда почему их все же называют библиотеками?
Y>Если по простому,
Вот-вот. Очень хотелось бы максимально просто и доходчиво.
Y>то используя библиотеку, Вы делаете вызовы к ней. Используя фреймворк, Вы, по большей части предоставляете ему Ваши "прикладные" колбэки.
Мягко говоря очень натянутое определение. Из него следует, что все функциональные библиотеки автоматом фрэймворки, так как они все основаны на "колбэках" (которые там называются функциями высшего порядка). Взять хотя бы Linq to Objects. Колбэк на колбэке. Но почему-то фрэймворком не считается. А WinForms как замечательно подходит под такое определение? Там все на событиях — колбэках.
В общем, приходится констатировать, что и Вы, Штирлиц, не знаете как размножаются ёжики (с) .
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
VD>Ну, и как перечисленные вещи сочетаются с определением "некоторый шаблон программы с определенными местами, в которые необходимо вставить свой код"? Куда в Entity Framework, скажем, вставить свой код? Где в Nunit этот загадочный шаблон? И что это вообще такое?
Nunit предоставляет собой шаблон программы, которая умеет запускать набор тестов и выводить результаты. Ты пишешь тесты, помечая классы и методы соотв. атрибутами ("вставляешь код в определенные места"), тем самым кастомизируя поведение шаблона под себя.
Здравствуйте, VladD2, Вы писали:
VD>Здравствуйте, dorofeevilya, Вы писали:
VD>>>Вот это определение совсем из пальца высосана. Под него подходят разве что Визарды в IDE. Плюс оно базируется на не менее не определенном понятии "шблон". D>>Я не претендую на строгость определения. Просто попытался передать суть своими словами.
VD>Дело в том, что это совсем не верное определение, противоречащее всем другим данным рядом, но я уже разок его видел. Очень интересен источник.
Как можно утверждать о верности того или другого определения, если сам не знаешь верного?
Не понял, кто такие "все другие данные рядом"?
Если найду источник, отпишусь.
Здравствуйте, VladD2, Вы писали:
VD>Здравствуйте, Skelterer, Вы писали:
S>>чем тебя не устраивает прямое определение?
S>>
framework
S>>1) база, основа; структура
S>>- conceptual framework: концептуальная [понятийная] структура; система понятий ( в базах знаний )
S>>- logical framework: логическая основа
S>>2) каркас; оболочка; конструкция; "скелет"
S>>- MFC application framework: каркас приложений на базе MFC
S>>- application framework: (1) каркас приложений (интегрированная среда, содержащая библиотеки классов и определяющая структуру разрабатываемого приложения); (2) каркас приложения; структура приложения
S>>3) рамки; условия
VD>Хотя бы тем, что это перевод, а не определения.
Ты взял умное иностранное слово и хочешь какое-то определение, которого не существует — около этого слова не стоит значочка "ТМ" или "R". Можешь дать точное определение слова "скелет"? Врядли. Этот термин легитимен абсолютно везде, где он отражает суть и смысл сущности, к которой применяется — будь то постулаты методологии управления или описание структуры программы. Ты хочешь найти красную кошку в зеленой комнате с помощью общества дальтоников? (дальтоников в том смысле, что сколько людей — столько мнений)
Здравствуйте, VladD2, Вы писали:
VD>Кто-нибудь может дать внятное определение термину Framework?
VD>Википедевое не предлагать. Оно не внятное.
Всякие определения хромают. Будет хромать и любое определение фреймворка.
Набор публичных библиотек .. от MozgC — а фортрановский SSP сюда пойдет ? Он ведь тоже образует большую систему и призван чего-то там облегчить...
Набор связанных библиотек от lomeo. А если библиотека одна и ни с чем не связана ? MFC, Qt. Да и что значит связанных ? А если к нему есть что-то от 3dparty ? Они связаны или нет ?
И т.д.
Я могу лишь одно определение дать. Я не знаю, что такое фреймворк. Но когда я увижу некий фреймворк, то я сразу пойму, что это он
Здравствуйте, dorofeevilya, Вы писали:
D>Nunit предоставляет собой шаблон программы, которая умеет запускать набор тестов и выводить результаты.
О как? И где же там шаблон то?
Библиотеку вижу. Утилиты для запуска тестов вижу. Шаблон — не вижу!
D>Ты пишешь тесты, помечая классы и методы соотв. атрибутами ("вставляешь код в определенные места"),
Ага. И никаких шаблонов при этом не использую.
И что самое важное, я совершенно не вижу мест в куда я должен подставлять свой код (как в твоем определении).
Можно хотя бы дать определение этого самого шаблона?
D>тем самым кастомизируя поведение шаблона под себя.
Какого еще шаблона? И что такое это загадочное "кастомизируя"?
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, dorofeevilya, Вы писали:
D>Здравствуйте, VladD2, Вы писали:
VD>>Так где же эта грань отделяющая библиотеки или подходы от фрэймворка?
D>Framework — это некоторый шаблон программы с определенными местами, в которые необходимо вставить свой код, чтобы получить требуемое поведение.
Вопрос в том, чей код выполняет основную работу. Framework сам выполняет полезную (основную) часть работы, которая кастомизируется клиентским кодом. Напр., ASP.NET обрабатывает http-запросы, вызывая ваш кастомный код для выполнения конкретной работы. Библиотека же предоставляет некоторую законченную функциональность, которая может быть использована для реализации основной задачи.
Здравствуйте, dorofeevilya, Вы писали:
D>Как можно утверждать о верности того или другого определения, если сам не знаешь верного?
Ну, утверждать что что-то не врено не зная верного решения очень даже можно. Скажем я не знаю точное значение числа Пи с точностю до 20 знаков, но точно знаю, что число 20 не является числом Пи.
D>Не понял, кто такие "все другие данные рядом"?
Рядом дан ряд определение которые я в общем-то понимаю и разделяю. К ним есть только одна претензия. Они очень расплывчаты. Определение про шаблон с дырками для бубликов местами, в которые необходимо вставить свой код — это определение какого-то текстового шаблона для генерации кода или Визарад в IDE создающего заглушки код (например, новую форму). Но это никак не соответствует тому что обычно называют фрэймворками (тому же NUnit-у).
D>Если найду источник, отпишусь.
Буду очень признателен!
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
VD>О как? И где же там шаблон то?
VD>Библиотеку вижу. Утилиты для запуска тестов вижу. Шаблон — не вижу!
VD>Ага. И никаких шаблонов при этом не использую. VD>И что самое важное, я совершенно не вижу мест в куда я должен подставлять свой код (как в твоем определении).
VD>Можно хотя бы дать определение этого самого шаблона?
VD>Какого еще шаблона? И что такое это загадочное "кастомизируя"?
Я не понимаю, ты хочешь просто строгое определение или действительно не понимаешь, о чем я говорю?
Если первое, то я не готов его составить.
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>Я могу лишь одно определение дать. Я не знаю, что такое фреймворк. Но когда я увижу некий фреймворк, то я сразу пойму, что это он
PD>А если не секрет, зачем эта игра в дефиниции ?
А вот как раз от предыдущего твоего утверждения. Я в общем-то с ним согласен. Я тоже не вижу четкого определения этого термина, но привык к тому, что фрэймворком называют некую хрень вроде Hibernate или NUnit... когда это уже вроде больше чем публичная библиотека, но все же оно не является отдельным приложением.
Так вот в последнее время появилось много трактовок этого термина и использования его не по назначению. Один из примеров этого уже был приведен здесь
Работа у меня такая. Должен я разбираться в чужих писаниях.
Вот вижу я что термин "фрэймворк/каркас" используется не по назначению. Но аргументированно ответить ничего не моугу, так как понимаю, что все имеющиеся на русском определения откровенно говоря сами высосаны из пальца.
Посему хочется как-то (в дискуссии) укрепить собственное понимание этого термина. Потому, как у меня крепнет ощущение, что термин этот используется в качествен заменителя замечательного русского термина "хреноваина" ( матерном варианте).
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Ага. Как в слове алкоголика встречается слова "хрень"/"хреновина". Но называется все это библиотекой. И существовал MFC еще в те времена когда модного слова "фрэймворк" еще не существовало (не употреблялось в компьютерном сленге).
Вот и хочется четких критериев. Что считать фрэймворком, а что библиотекой. Точнее даже так. Что позволяет назвать некую библиотеку фрэймворком.
Вот скажем может ли быть фрэймворк внутри приложения? Или он обязан быть отдельной частью? Или даже обязан быть публично доступным?
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
VD>Вот и хочется четких критериев. Что считать фрэймворком, а что библиотекой. Точнее даже так. Что позволяет назвать некую библиотеку фрэймворком.
Фреймворк фактически представляет из себя комплексное решение задач из какой-то области, это более абстрактная штука, нежели API. В результате с одной стороны, мы больше настраиваем фреймворк, чем работаем непосредственно с примитивами и, с другой, мы ограничены возможностями/стилем фреймворка, что накладывает определённый отпечаток на весь код.
VD>Вот скажем может ли быть фрэймворк внутри приложения? Или он обязан быть отдельной частью? Или даже обязан быть публично доступным?
Может. Ничего не мешает переизобрести hibernate/логгер/постшарп
Здравствуйте, VladD2, Вы писали:
VD>Вот вижу я что термин "фрэймворк/каркас" используется не по назначению. Но аргументированно ответить ничего не моугу, так как понимаю, что все имеющиеся на русском определения откровенно говоря сами высосаны из пальца.
Я бы вот что еще добавил. Не как определение, а просто как размышления.
Фрймворк отличается от просто библиотеки тем, что он горазо жестче предписывает правила написания программ с его применением. Я могу из фортрановского SSP взять линейную алгебру, проигнорировать полностью дифуры и прикрутить эту линейную алгебру к приложению, структуру которого я разработаю сам, вовсе не думая при этом об SSP. То же верно , скажем, для STL. Но если перейти во фреймворк, скажем, WinForms или WPF или MFC, то тут надо с начала принять его правила игры. Можно, конечно, сделать консольное приложение с .net или MFC, но это значит сразу отказаться от 90% возможностей фреймворка. А не отказываться — изволь приложение писать по этим правилам, которые он продиктует, а потом уже можно к нему и что-то иное прикрутить. И это не обязательно о визуальных фреймворках речь идет. Тот же Хибернейт продиктует правила работы с БД не менее жестко.
В общем, вот такое наклевывается определение. Если этот пакет можно безболезненно удалить и чем-то заменить, и при этом концепции не пострадают — это библиотека. Иначе — фреймворк.
VD>Вот и хочется четких критериев. Что считать фрэймворком, а что библиотекой. Точнее даже так. Что позволяет назвать некую библиотеку фрэймворком.
для абстрактных понятий не бывает четких критериев (вот введи, например, четкие критерии при каком соотношении смесь спирт-вода: называется спиртом, водкой, водой. а здесь хотя бы есть четкий способ измерить соотношение)
у абстрактного понятия "фреймворк" есть два противопоставления:
1. фреймворк vs библиотека
2. framework vs законченное приложение
способ измерения для первого противопоставления тебе уже дали: если ближе к каркасу — то framework, если ближе к нашлепке сбоку — то библиотека.
и тот же mfc, asp.net можно рассматривать и как framework, и как библиотеку (в зависимости от контекста)
.net — сложно рассматривать как библиотеку (в очень редких контекстах — это будет библиотека)
stl — тяжело рассматривать как framework (в очень редких контекстах — это будет framework)
способ измерения для второго противопоставления: если шнягу настраивать для конечного использования надо мало — готовое приложение, если много — то framework
Здравствуйте, dorofeevilya, Вы писали:
D>Здравствуйте, VladD2, Вы писали:
VD>>Так где же эта грань отделяющая библиотеки или подходы от фрэймворка?
D>Framework — это некоторый шаблон программы с определенными местами, в которые необходимо вставить свой код, чтобы получить требуемое поведение.
Поддерживаю.
Проследим мысленно работу компьютера от старта до запуска программы и до ее окончания, в виде графа вызовов процедур.
Сначала работает операционная система, потом она вызывает процедуру main(int argc, char** argv){}, та вызывает еще какие-то основные процедуры программы, те вызывают библиотечные процедуры (например, ввод-вывод).
ОС->программа->библиотека
Типичная библиотека графического интерфейса, однако, находится слева от основной программы:
ОС->GUI->программа->библиотека
То есть, GUI играет роль не просто библиотеки, а продолжения операционной системы (или роль специализированной операционной системы).
Вот такие библиотеки, играющие по отношению к программе роль ОС, называют фреймворками, чтобы отличить от обычных библиотек.
Можно сделать вывод, что обычная ОС — это тоже фреймворк.
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>В общем, вот такое наклевывается определение. Если этот пакет можно безболезненно удалить и чем-то заменить, и при этом концепции не пострадают — это библиотека. Иначе — фреймворк.
Это уже ближе к делу.
PD>Но и это определение хромает.
Во-вот. Получается, что если использование библиотеки приводит к дикому связыванию кода, так что оторвать код от фрэймворка уже нельзя, то это был фрэймворк. А если код получается относительно независимым, то — это библиотека. Только тогда уж я бы предпочел библиотеку.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
VD>Кто-нибудь может дать внятное определение термину Framework?
Фреймворк это библиотека которая навязывает приложению архитектуру.
... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, VladD2, Вы писали:
VD>Кто-нибудь может дать внятное определение термину Framework?
Толпа окружала хреновину, на которой мы стояли. Я так толком и не узнал, что такое хреновина, когда Ааз употреблял в разговоре это слово. Однако когда я очутился здесь, я узнал её с первого взгляда. Штука, на которой мы стояли, могла быть только хреновиной.
(с) Асприн Р.Л.
На этот счет есть хорошая статья, в которой, в частности дается следующее определение фреймворку:
A framework can be defined as a set of libraries that say “Don’t call us, we’ll call you.” When you invoke a traditional library, you are still in control: you make the library calls that you want to make, and deal with the consequences. A framework inverts the flow of control: you hand over to it, and wait for it to invoke the various callback functions that you provide. You put your program’s life in its hands. That has consequences: one of the most important ones is that, while your program can use as many libraries as it likes, it can only use—or, rather, be used by—one framework. Frameworks are jealous. They don’t share.
и оно похоже на правду, вот почему: фреймворки бывают не только программерские. Есть еще вот такие: http://www.metasploit.com/framework/download/ или даже вот такие: http://www.microsoft.com/rus/business/Articles/SolutionsInfrastructureMof.mspx — в которых нет ни намека на разработку. Но единственное, что их объединяет, это именно этот самый IoC, выражающийся в метасплоите — в реализации ряда интерфейсов при разработке эксплоитов и нагрузок, и в MoF (методологии управления ИТ-инфраструктурой) — в реализации диктуемых фреймворком наборов входов и выходов всех квадрантов процесса, т.е. контрактов, т.е. тех же самых интерфейсов, но примененных не к предметной области разработки, а к предметной области управления специфичными процессами.
VD>Во-вот. Получается, что если использование библиотеки приводит к дикому связыванию кода, так что оторвать код от фрэймворка уже нельзя, то это был фрэймворк. А если код получается относительно независимым, то — это библиотека. Только тогда уж я бы предпочел библиотеку.
Здравствуйте, WolfHound, Вы писали:
VD>>Кто-нибудь может дать внятное определение термину Framework? WH>Фреймворк это библиотека которая навязывает приложению архитектуру.
Ага, это определение каркаса, кажется, дали GoF. Они рассматривали различие т.н. инструментальных библиотек и каркасов. Здесь краткий пересказ: http://www.rsdn.ru/article/patterns/generic-mvc.xml#EGOAC
Интересно следующее в этом отношении: почему в таком случае .NET Framework, а не .NET Platform?
Вот, к примеру, ASP.NET MVC Framework — правильно, так как данный каркас диктует архитектуру приложения и вызывает пользовательский код из своего кода. А .NET Framework — неправильно, так как код BCL вызывается из пользовательского кода, а не наоборот. К примеру, Sun правильно назвала Java Platform, а не Java Framework. А Microsoft как-то злоупотребляет словом Framework. Хорошо хоть Windows Platform SDK, а не Windows Framework SDK.
Здравствуйте, DarkGray, Вы писали:
DG>для абстрактных понятий не бывает четких критериев (вот введи, например, четкие критерии при каком соотношении смесь спирт-вода: называется спиртом, водкой, водой. а здесь хотя бы есть четкий способ измерить соотношение)
Четкий-не четкий, а ответ дать можно. Водка — это ~ 40%. Спирт от 70 и выше. Остальное смеси. Вода — это 0%.
DG>у абстрактного понятия "фреймворк" есть два противопоставления: DG>1. фреймворк vs библиотека DG>2. framework vs законченное приложение
О последнем вроде бы никто не говорил. Но послушать было бы интересно.
DG>способ измерения для первого противопоставления тебе уже дали: если ближе к каркасу — то framework, если ближе к нашлепке сбоку — то библиотека.
Выделенное повеселило. Определение масла через масленичную субстанцию.
DG> и тот же mfc, asp.net можно рассматривать и как framework, и как библиотеку (в зависимости от контекста)
Вот-вот. И интересен контекст в котором их рассматривают как фрэймворк. Если что "каркас" — это просто русский перевод. Не надо его в определения включать.
DG> .net — сложно рассматривать как библиотеку (в очень редких контекстах — это будет библиотека)
Дык и фрэймворком его сложно назвать. Это скорее рантайм плюс набор универсальных библотек (или фрэймворков).
DG> stl — тяжело рассматривать как framework (в очень редких контекстах — это будет framework)
Сдается мне он ни в каких контекстах не фрэймворк. Да и что это за зависимость от контекста?
DG>способ измерения для второго противопоставления: если шнягу настраивать для конечного использования надо мало — готовое приложение, если много — то framework
Что-то у тебя совсем все размазано получилось.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
DG>> .net — сложно рассматривать как библиотеку (в очень редких контекстах — это будет библиотека) VD>Дык и фрэймворком его сложно назвать. Это скорее рантайм плюс набор универсальных библотек (или фрэймворков).
Вот именно. Это, конечно, офф, но может кто объяснит, почему .NET Framework, а не .NET Platform: Re[2]: Framework
Здравствуйте, Pavel Dvorkin, Вы писали:
VD>>Во-вот. Получается, что если использование библиотеки приводит к дикому связыванию кода, так что оторвать код от фрэймворка уже нельзя, то это был фрэймворк. А если код получается относительно независимым, то — это библиотека. Только тогда уж я бы предпочел библиотеку.
PD>Поздно. Придется вернуться лет на 20 назад
История развивается по спирали.
ЗЫ
Кстати, а причем тут Немерле?! (с)
Я тут заметил, что немерлу не нужны фрэймворки. Они в нем прекрасно выражаются в виде библиотек макросов. И преимущества у такого подхода как раз то же что и у обычных библиотек — возможность достижения низкой связанности.
Так не являются ли фрэймворки костылями для современных технологий?
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
VD> Кстати, а причем тут Немерле?! (с) VD> Я тут заметил, что немерлу не нужны фрэймворки. Они в нем прекрасно выражаются в виде библиотек макросов.
Где бы что ни говорили — все одно сведет на баб (c)
Здравствуйте, hattab, Вы писали:
VD>> Кстати, а причем тут Немерле?! (с) VD>> Я тут заметил, что немерлу не нужны фрэймворки. Они в нем прекрасно выражаются в виде библиотек макросов.
H>Где бы что ни говорили — все одно сведет на баб (c)
Завидно?
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Y>>Я всегда считал, что настоящий Тролль -- родственник Капитана. Его аргументы неопровержимые до очевидности.
VD>Опустим это словоблудие.
Ваше право. Я лишь хотел, убедиться, что Вы не Тролль.
Пока не получилось.
Y>>General MFC Topics http://msdn.microsoft.com/en-us/library/583ya1kc(VS.80).aspx Y>>Слово Framework на странице встречается 7 раз.
VD> Ага. Как в слове алкоголика встречается слова "хрень"/"хреновина". Но называется все это библиотекой.
1. MSDN(Library) и слова алкоголика имеют разную квоту доверия (у меня, во всяком случае)
2. Я привык считать, что когда люди ввязываются в спор "не за выгоды", они это делают, не что бы убедить собеседника в чем-то, а что бы узнать, не ошибаются ли они в чем-то сами (во всяком случае я делаю так).
С Вашей стороны совершенно не конструктивно (с точки зрения выяснить, чем фреймворк от библиотеки отличается) указывать на то, что там еще и слово Library есть.
Очевидно, что Библиотека, в широком смысле, -- это набор средств (в основном в виде кода), который не является продуктом для "конечного пользователя", на который можно возложить решение каких-то задач.
И Очевидно, что задачи эти могут быть как "прикладными", так "системными" -- из области организации разрабатываемого приложения. И, да, очевидно, большая библиотека может содержать пачку фреймворков.
Библиотека в смысле "библиотека vs. фреймворк" -- средства, решающие те или иные задачи, но не обеспечивающие "внутреннюю организацию" приложения.
VD> И существовал MFC еще в те времена когда модного слова "фрэймворк" еще не существовало (не употреблялось в компьютерном сленге).
Мне видится в этом как минимум две причины:
1. Маркетологи поработали
2. "Явление" стало более массовым ("фреймворков" развелось).
VD> Что позволяет назвать некую библиотеку фрэймворком.
Ничего. Если важны слова, то, как я написал выше, библиотека может его содержать.
VD>Вот скажем может ли быть фрэймворк внутри приложения? Или он обязан быть отдельной частью?
Имхо, может быть внутри.
В текущем велосипеде (спец. САПР, много интерактивной графики) он сначала был "внутри", потом стал отдельной сборкой (начал использоваться в другом приложении)
Здравствуйте, VladD2, Вы писали:
VD>Кстати, а причем тут Немерле?! (с) VD>Я тут заметил, что немерлу не нужны фрэймворки. Они в нем прекрасно выражаются в виде библиотек макросов. И преимущества у такого подхода как раз то же что и у обычных библиотек — возможность достижения низкой связанности.
Фреймворки ортогональны способу их реализации (на библиотеках или макросах). Я разделяю это
определения. Не против других, но эти более строгие. В зависимости от того, кто, когда и кого вызывает может получиться библиотека или фреймворк. На самом деле ситуация еще интереснее: фреймворк может быть собран из отличного набора вполне ортогональных библиотек. Например, сервер для веб-сервисов собирается из библиотек работы с сетевыми соединениями, обработки протокола HTTP (парсинг), библиотеки работы с XML, библиотеки разбора SOAP, части бизнес логики. И с точки зрения типичных задач (добавить новый вызов) вся собранная система будет в какой-то степени framework'ом. Другое дело, что при необходимости стек обработки можно будет заменить (ввести свой транспорт и форматы передачи), но это получится "настройка фреймворка" в основном. Более сложные задачи (если вдруг что-то где-то потребуется между слоями приложения таскать) потребуют разработки новой системы связей. Но после этого все равно типичные задачи будут задачами использования фреймворка а не библиотеки. В виде библиотеки оно неудобно получается.
То, что большинство "фреймворков" превращаются в монолиты, это проблема дизайна фреймворков. В данном случае дизайн — это не только код, но и сопутствующая документация по этому самому фреймворку (обучение использованию). На примере веб-сервиса выше было показано, как все может быть реализовано в виде библиотек. Если в документации при этом описано, что есть "стандартные" методы построения стека (и то, что они делают внутри), то можно самим сконструировать новый стек. Если же описано только написание новых методов — то да, это проблемы. С макросами может быть та же история — либо это большой макрос, интегрирующий код в свой (или другой) фреймворк, либо макрос, генерирующий вызовы к стеку библиотек. Правда как при этом настраивать макрос — не понятно. Как видим — ничего крутости макросов не показывает.
Более того, у меня перед глазами есть конкретный пример фреймворка на макросах nemerle со всеми его проблемами расширяемости Это NemerleUnit. Вызов пользовательского кода прошит в framework и NemerleUnit определяет, что и как будет вызываться. Типичная framework'овская проблема в том, что тесты создают сами макры. Это, в частности, не позволяет делать "параметрические" тесты. "Параметрические" тесты — это тесты, которые получают на вход объект и тестируют его. Изначально мне такие тесты были нужны для тестирования интерфейсов. Фактически — некоторый validation для различных реализаций. В принципе, для одного и того же интерфейса могут быть разные комплекты (не ортогональные, а проверяющие некоторые дополнительные гарантии). И реализовав интерфейс я хочу проверить наличие основной фичи и опциональных фичей C и D. Как мне реализовывать эти тесты? Ну в xUnit можно через наследование, но это все же workaround. А в NemerleUnit? Кстати, ссылки на svn не работают с указанной странички, я хотел макру посмотреть, вдруг там из коробки есть то, что мне нужно.
К чему все это — да все к тому же, и макры, и библиотеки могут быть framework'ом. "Библиотека" запуска юнит-тестов в правильном виде состоит из двух частей. "Runners", получающих на вход набор тестов для проведения. И библиотека для генерации наборов тестов. Это всевозможные способы генерации сьютов (из метаданных класса, конструктивным кодом и т.п.). Различные способы генерации тестов (из метаданных классов, настраиваемые способы). Ну и "обвязка по умолчанию", конструирующая тесты из метаданных и передающая их запускалке. С возможностью полностью перекроить эту обвязку. Плюс документация. Фокус в том, что можно это реализовать как на макрах (теми же макрами генерировать тесты для библиотеки), так и в обычном коде (кое где может понадобиться больше кода). Если же runner'ы глубоко глубоко прятать, то придется копаться в коде или писать костыли (например, генераторы, генерирующие требуемые коды для макры NemerleUnit).
VD>Так не являются ли фрэймворки костылями для современных технологий?
Ну... Макры — это фреймворк по расширению компилятора Кстати, компилятор мог быть бы и набором библиотек. Например, расширяемый парсер + отдельный кодогенератор + набор конвертеров между представлениями. Может, конечно, так и есть... Тогда в макрах должно быть можно создавать совсем новые типы узлов AST, новые системы типов и т.п. Например, можно ли CheckedExceptions добавить макрой? С учетом отсутствия карринга (а только с частичным применением) это не слишком усложняет систему типов. Или добавить ко многим объектам новый атрибут — документацию. Поясню, зачем это нужно — есть некоторые идеи генерировать по одному описанию весь спектр "различных" по поведению структур: иммутабельные, реактивные без возможности мутации в API, реактивные с возможностью мутации в API и кучу конвертеров между ними. Ну и в добавок различные протоколы сериализации плюс документацию по формату протокола в wiki . А макры такое смогут?
В случае ортогонального набора библиотек такие изменения на уровне "языка" не слишком сложно было бы сделать. Ну да, написать кучу оберток поверх стандартных структур, вызывая стандартные обработчик после преобразований типов. Либо вообще просто добавлением дополнительных обработчиков (хотя в этом сомневаюсь). Вот и интересно — макры это все же framerwork к компилятору (хотя бы в одном из двух примеров нужно что-то править в "ядре" компилятора) или способ удобного использования библиотек компилятора (тогда оба примера реализуются "на макрах").
P.S. Ну и если бы nemerle был набором библиотек, к нему достаточно легко было бы прикрутить другой backend. Это было бы огромным плюсом. Ну и заодно еще одним свидетельством того, что сама платформа "nemerle" — это больше набор библиотек, чем famework over .Net.
Здравствуйте, VladD2, Вы писали:
VD>Кто-нибудь может дать внятное определение термину Framework?
ИМХО — Фреймворк — прослойка между программным кодом и машиной, вводящая новый синтаксис и семантику, которые более аппаратно-независимые чем машинные, и представляют определенные удобства для программиста в том смысле в каком обычно его представляет высокоуровневое программирование по сравнению с низкоуровневым. В идеале, программист вообще может не знать об особенностях машины, на которой работает, фреймворк должен скрывать эти особенности и их сложность.
Здравствуйте, VladD2, Вы писали:
VD>Кто-нибудь может дать внятное определение термину Framework?
VD>Википедевое не предлагать. Оно не внятное.
Думаю внятнее найти сложнее, тут и про костыли и про форму и про размер и про шаблоны, ну и само собою про точки расширения.
The fixed part of the solution is written using traditional design, coding,
and testing techniques.
Depending on the size and shape of the problem,
this fixed part of the solution might be called a framework, a platform, an
interpreter, or an Application Programming Interface (API).
The fixed part
captures the architectural patterns that make up the domain and exposes extension points that enable it to be used in a variety of solutions.
What makes the approach applicable is the fact that you create the variable part
of the solution by using a special-purpose language—a DSL.
Здравствуйте, VladD2, Вы писали:
VD>Так где же эта грань отделяющая библиотеки или подходы от фрэймворка? VD>Это только мне кажется что слово Framework является эдаким цензурным синонимом слова "хреновина"?
Разница должна быть нечеткая.
По мне так, фреймворк это то, что менее гибкое чем библиотека. Фреймворк может предлагать рантаймовый граф обьектов (передопределенный фреймворком заранее), в который можно вносить небольшие добавки.
Как в свое время был MFC с шаблончиками DocumentView (или как там его), очень негибкий и костлявый инструмент.
И в то же время существовал Delphi — это уже скорее была гибкая библиотека GUI (в сравнении с MFC).
Если сравнивать WinForms и WPF , то WPF ближе к фреймворкам, WinForms ближе к гибким библиотекам.
А в LINQ to Objects колбэки есть, но нету рантаймовых, жестко предопределенных, графов. К тому же он очень универсальный, гибкий инструмент, поэтому называть это фреймворком как то не очень.
Здравствуйте, VladD2, Вы писали:
MC>>Набор публичных библиотек, образующих большую систему и призванных облегчить (упростить, ускорить, предоставить готовые проверенные решения) разработку приложений в определенной предметной области или на определенных языках. VD>А зачем для вполне понятного понятия набор библиотек вводить отдельное понятие? VD>Да и почему сразу набор? То есть получается складываем две библиотеки в кучу и получаем фрэймворк?
Мне всегда казалось, что фреймворк от просто библиотеки отличает то, что фреймворк есть некий универсальный набор библиотек, предназначенный для создания приложений разного рода. Т.е. библиотека для работы с ГУИ — это просто библиотека, а вот свалив в кучу ГУИ, веб и проч. и проч. — получаем фреймворк.
Сам термин, скорее, имеет больше маркетинговое применение, особой пользы в нем нет. Разве что позволяет отличить проблемно-ориентированный набор библиотек, т.е. набор библиотек, ориентированных на решение какой-то конкретной задачи, и набор библиотек, ориентированных на решение разных несвязанных между собой задач.
Здравствуйте, VladD2, Вы писали:
VD>Кто-нибудь может дать внятное определение термину Framework?
1) Гугл предлагает очень много различных вариантов. Очень часто во всех встречаемых мной определениях содержались следующие слова:
облегчающая, решение, типового, набора, задач, определенной, предметной, области
2) Учитывая иностранное происхождение термина, берем словарь и находим перевод, выкинув заведомо неподходящие к ней области варианты, клеим остальное
.......
3) PROFIT!!!!!
кодовая база/основа, облегчающая решение типового набора задач в определенной предметной области
система готового набора средств, облегчающая решение типового набора задач в определенной предметной области
набор готовых средств, облегчающий решение типового набора задач в определенной предметной области
коробка готовых инструментов, облегчающих решение типового набора задач в определенной предметной области
Получается, что в зависимости от контекста, это слово может означать материальное отражение накопленного и структурированного опыта, знаний и инструментов, которые как вы уже наверное догадались
облегчают решение типового набора задач в определенной предметной области
Кстати, компилятор мог быть бы и набором библиотек. Например, расширяемый парсер + отдельный кодогенератор + набор конвертеров между представлениями. Может, конечно, так и есть... Тогда в макрах должно быть можно создавать совсем новые типы узлов AST, новые системы типов и т.п. Например, можно ли CheckedExceptions добавить макрой? С учетом отсутствия карринга (а только с частичным применением) это не слишком усложняет систему типов. Или добавить ко многим объектам новый атрибут — документацию. Поясню, зачем это нужно — есть некоторые идеи генерировать по одному описанию весь спектр "различных" по поведению структур: иммутабельные, реактивные без возможности мутации в API, реактивные с возможностью мутации в API и кучу конвертеров между ними. Ну и в добавок различные протоколы сериализации плюс документацию по формату протокола в wiki 
