Обсуждение

> а вот если изложить всю эту философию кондовым канцеляритом, то можно делать на этой философии-фреймворке неплохой сертификационный бизнес Вот этот сертификационный бизнес и губит всю идею. Неужто кто-то эти 2 тысячи страниц ИТИЛя читает? Этот как стандарт "Open" XML документов от Микрософта - никто его не читал и реализовывать не собирается, ибо невозможно такую кучу спецификаций реализовать на практике.

Каковы функции этой "стандартной программы", которую вы назвали фреймворком? Либо я что-то не так понял, либо не точно звучит фраза "Если ваша собственная программа вызывает какие-то стандартные функции -- это библиотека. А если стандартная программа вызывает ваши собственные нестандартные функции -- то эта стандартная программа называется фреймворком." Хотя текст далее дает понять яснее. Обычно фреймворк - это система с набором взаимосвязанных (или не очень) библиотек. То есть это скорее свод правил для взаимодействия этих библиотек и неким стандартом кодирования в нем, чем программа (текст программы). И ведет он себя пассивно, пока приложение, построенное на фреймворке (использующее его библиотеки/апи и т.д.), не вызывает его.

Очень помогло хоть как-то структурировать понятия. Вот только недавно голову сломал, почему COBIT - это framework, а ITIL-нет? Не разобрался, и плюнул, а все дело значит-ся, в позиционировании и мании величия авторов.

Наоборот, приложение делается из вкручивания предметной специфики в специально предоставленное для этого места фреймворка (т.е. это из фреймворка торчат API в ваши коды -- он их вызывает, а не из ваших кодов вызывается фреймворк). И я тут не про программирование пишу. Я написал же, что даже программисты не слишком разбираются в этой проблематике (примерно половина разбирается, а половина не обращала на эти архитектурные тонкости никакого внимания). Мне интересно, как можно объяснить тему непрограмистам, которые даже не знают слово "приложение". Или даже не программистам, которые считают, что слово "приложение" -- устарело, и современные архитектуры не должны работать с "приложениями" (типа людей из проекта STEPS в VPRI, которые об этом говорят явно). Мне интересно, как объяснять про организационные фреймворки непрограммистам. Непрограммистам. Непрограммистам.

А вы почитайте 2000 страниц ITIL -- там, правда, очень водянисто и бесструктурно, но много интересных вещей изложено. Другое дело, что понять их почти нельзя, если у вас нет некоторого опыта работы в организационной области (опыт программистский тут в зачет абсолютно не идет, ITIL -- он про организацию, а не про собственно IT).

Да, я понял, что для непрограммистов :) Тут я могу себе представить человека, пользующегося ресурсами какой-то системы. Меня именно в программистском плане интересует. Не могли бы вы объяснить чуть подробнее? По тому, что вы сейчас описали, мне представилась работа виндоус (вся ОС), когда по событиям вызываются части приложения. Но я имел ввиду теже веб приложения, которые на входе имеют некоторые данные запроса пользователя и больше ничего. Обычные фреймворки, хотя бы тот же официальный Zend Framework для PHP, ничего сами не вызывают, именно приложения вытягивают нужный функционал из них. Поэтому я и сказал, что это просто набор правил (а кто кого дергает не имеет особого значения). Разве не так?

Пытаться соотнести теорию с конкретными примерами (Zend Framework и т.п.) думается — не очень хорошая затея, т.к. упомянутые примеры — суть названия продуктов, а не результат скорпулёзного воплощения теории, и могуть функционировать иначе, нежели описанные понятия. SOb Zemlja

скруп

> Мне интересно, как объяснять про организационные фреймворки непрограммистам. Непрограммистам. Непрограммистам. 1) Простой пример. Статические детерминированные framework. Вот симфонический оркестр. Каждый музыкант и инструмент в его руках уникален и неповторим. Но всю неповторимость своего исполнения заданной партитуры музыкант проявляет, подчиняясь дирижёрской палочке.Только дирижёр "слышит" весь оркестр в целом. И только он знает, с чего начнётся и чем закончится музыкальное произведение. 2) Пример из области creative culture. Среда динамических недетерминированных frameworks. Вот симфонический оркестр. Вот музыканты и их инструменты, которые уникальны и неповторимы. Музыканты следуют "взмахам" дирижёрской палочки. А вот дирижёр, который знает что должен играть его симфонический оркестр в данный момент. А вот еще неопределенное количество симфонических оркестров, каждый из которых исполняет своё произведение. А вот музыканты, которые свободно переходят из одного оркестра в другой, чтобы исполнить ту или иную партитуру, отражающую их уникальность. Симфонические оркестры появляются и исчезают, доиграв свои произведения. А вот несколько композиторов, которые пишут фрагменты произведений то для одного, то для другого симфонического оркестра. Они отдают эти фрагменты произведений очередному дирижёру, который, как мы помним исполняет эти произведения с помощью музыкантов симфонического оркестра. Каждый из композиторов следит за настроением зрительного зала и в зависимости от реакции публики сочиняет очередной кусок произведения для определённого оркестра. (и это только начало!)

Когда вы пишете свою программу и впихиваете туда gd для обработки изображений, это "использование библиотеки". Когда вы пишете плагин для фотошопа -- это использование "фреймворка" :)

Да, это правильный заход. Тут еще можно вспомнить мою любимую тему: отличие партитурной ("композиторской") музыки ("видео-культуры") и джазовой (чистого "аудио") -- http://ailev.livejournal.com/517723.html или пункт 6 в http://ailev.livejournal.com/519176.html, где я про то же самое говорю как "кооперацию" музыкантов и их "коллаборацию". Музыкальная метафора, правда, тоже не всем может быть понятна, но уж точно в большей степени, чем программистское объяснение.

Очень точно. Хотя понятны причины сомнений в объясняющей силе такого подхода: написание любого приложения (включая фотошоп) -- это написание плагина к операционной системе ;) Зависит от взгляда: для кого-то и плагин -- программа. А для автора ОС и приложение -- плагин. :)

Так уже ближе, спасибо. Потому что по описанию в процитированном тексте (и по моим представлениям ранее) получается, что приложение имеет один постоянный статус, а на самом деле этот статус навешивается для объяснения текущего взгляда на приложение.

Ну а как же без примеров? Тут как бы есть слово Framework - оно одно и используется в двух разных контекстах. Вопрос состоит в том: 1) скрываются ли за этим словом разные сущности (например, вообще слова из разных областей, не имеющие ничего общего). /убедиться в этом забыть 2) сущность одна, но на неё навешаны дополнительные условия (нюансы), что отличает её от такой же но с другими нюансами. /тогда надо выделить общее (что и выяснилось ниже) 3) кто-то неправильно понимает смысл этого слова вообще. /надо дать определения и узнать точно