Сегодня прочитал и просто порадовался:

Цитата:

Барбара Лисков (Barbara Liskov) получила престижную премию Тьюринга за вклад в теорию абстракции данных, которая упрощает создание сложных программ. Продолжение здесь

Кстати ее принцип упоминался в нескольких темах здесь.

Цитата:

В настоящее время Лисков разрабатывает комплекс методик, позволяющих построить устойчивую к появлению ошибок систему, которая продолжит работать в случае, если сбоит один из ее компонентов.

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

Но должна ли система быть устойчивой к чисто логической ошибке, если она заложенна в результате проектирования?
Вот точка зрения почему нет:
вместо того что бы исправить ошибку, мы делаем систему устойчивой к ошибкам, тем самым усложняя систему.
Усложнение ведет к новым ошибкам, система перестает быть ортогональной. Так что нас ждет в будущем?

Кстати, я нашел интересную критику на OOP:
http://www.geocities.com/tablizer/oopbad.htm

Текста много, но читается действительно интересно.
Автор предлагает Table Oriented Programming (TOP):
http://www.geocities.com/tablizer/top.htm

Я только начал знакомиться с этим, по ходу дела:
TOP более совместимо с реляционными базами данных (чем OOP);
TOP является более декларативным программированием в отличие императивного OOP;

Несколько действительно здравых (но, увы, тривиальных и высказанных много раз до того) мыслей разбавлены огромным количеством воды пополам с демагогией.

Допустим:
- менеджер получает помесячную зарплату и бонусы;
- работник получает почасовую зарплату и овертайм;
- агент получает комиссионные;
Где хранить алгоритм зарплаты (подразумеваем LAMP)?

Можно для каждого алгоритма сделать отдельный класс и использовать паттерн Стратегия.

Что бы отделить информацию от PHP кода можно использовать XML. Уже лучше, потому что код стал более декларативный.

Можно использовать БД и хранить алгоритм (SQL код) как данные в таблицах. Зачем?
Если информация о затраченных часах, овертайме и комиссионных храниться в базе, то логично алгоритм держать как можно ближе к данным. Тем более что в MySQL есть Prepared Statements.

Если алгоритм зарплаты можно держать в базе, то аналогично можно поступить и с другими частями программы.
Один из недостатков этого метода в том что программу труднее редактировать.
Код хранится в бинарном виде, а не в простом ASCII текстовом файле.
Ссылок об использовании таблиц очень много. Мне понравилась эта: http://c2.com/cgi/wiki?CodeAvoidance

Цитата:

Если информация о затраченных часах, овертайме и комиссионных храниться в базе, то логично алгоритм держать как можно ближе к данным.

Здесь нет логического перехода.

Простой пример: компания X объединяется с компанией Y и вводит общий расчет зарплат. При этом каждая из них имеет свою базу сотрудников (зачастую -- совместно используемую HR и бухгалтерией). Если алгоритмы вынесены в Application Tier -- мы достаточно легко пишем общее приложение расчета, которое работает с обеими базами. Если логика в хранимых процедурах (причем, одна база -- MySQL, а другая -- Oracle), то мы весело и бодро пишем все нахрен сначала.

История реальная, кстати.

Другая история, тоже реальная: для аналитической системы -- для блока что-если -- нужно протащить вычисление зарплаты. Т.е. менеджер играет коэффициентами, а система показывает, как это влияет на зарплату типичных сотрудников. А алгоритм кто-то додумался сунуть в хранимые процедуры. И начинается пляска с бубном. Правда, в реальности это были не зарплаты, а комиссионные.

Так что красивые идеи имеют обыкновение разбиваться о реалии суровой реальности.

Crazy,
все верно.

Но вот другой пример. Допустим алгоритм решает какую страницу (view) показать в зависимости от того какую кнопку (action) пользователь нажал. В этом случае ситуация объединения с чужими базами не грозит и менеджеру там играться нечего.

-----
С объединениями двух несовместимых баз мне пришла (еще незнаю какая) идея:

что если несовместимые базы объединить в одну временную базу?
Не всю базу конечно, в случае зарплат объединить только данные за прошлый месяц.
Все вычисления проводить с временной БД, а потом грузить данные обратно?
Все равно две несовместимые базы уже не транзактны.
А одна временная как раз может быть транзактной.

AlexShop писал(а):

Один из недостатков этого метода в том что программу труднее редактировать. Код хранится в бинарном виде, а не в простом ASCII текстовом файле.

Кстати я ошибся. В MySQL есть CSV Storage Engine

Так вот,
пришла мне в голову одна сумбурная идея . Начну из далека.

Если дать опытному шахматисту решить несложную 3-4 ходовую задачу, то он найдет решение от 10 сек. до нескольких минут. Почему так быстро? Потому что если задача не сложная, то первые ходы которые приходят в голову чаще всего будут верными.

Если дать программисту посмотреть на незнакомый код, то нередко ему потребуется много времени что бы понять его.

Иными словами: шахматист глядя на незнакомую позицию имеет большее представление, чем программист глядя на незнакомую программу.


Что если (включаем фантазию):

шахматная доска - это программа
фигуры - это объекты
правила по которым фигуры ходят - это правила по которым объекты работают (API)

Программист глядя на такую "шахматную" доску имеет представление что на ней происходит.
Когда программист двигает фигуры (объекты) он видит как программа работает.

Шахматные фигуры взаимосвязанны с друг другом, например: одна фигура защищает другую, делает вилку, подвязку и т.д.
Объекты так же взаимосвязанны с друг другом.

Теперь забудем про шахматы, это было только пример.
Что если придумать игру, которая наиболее реально отображала ООП?


------
Другой пример: игра Жизнь.

Кстати контрольные таблицы (Control Tables) думаю очень хорошо подходят для написания фронт контроллера (Front Controller).

Вот тривиальная задача: исполнить определенный файл в зависимости от URL. Варианты URL можно держать в базе данных (таблице):

В таблице видно какой файл исполнится при каком URL. Можно пойти дальше, например включить столбики в которых будут Actions, GET и POST, проверка авторизации, вызов методов и т.д. Конечно все склыдывать в одну таблицу не надо (помним про нормализацию).

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

Мы видели как объект может быть одновременно массивом (см. PHP: синтактический сахар с помощью ArrayAccess)

Можно создать объект с доступом к таблице. Одновременно этот объект работает как массив.
Например, что бы получить значение первой строки и столбика "article_name":


Вот так

AlexShop, для написания конфигов "front controller'ов" давно уже стандартом де-факто стал XML. Ввиду значительно меньших расходов на сопровождение.

Да, XML хорошо подходит для небольших баз, где данные нерегулярны или их трудно классифицировать (разложить по нужным таблицам).
Плюс XML легко редактировать в редакторе (в отличие от реляционной БД).

А с другой стороны, XML файл мне чем то напоминает одну большую switch case конструкцию.
Так не проще ли вместо XML элементов использовать case statements и несколько PHP классов. Т.е. вместо длинного XML кода, имеем длинный PHP код. Какая разница? Код есть код. Разница в том, что PHP код это не совсем данные, потому что мы не можем делать запросы к коду (как это делает XPath или SQL). Нужны ли нам запросы — я отвечу позже.

Так как в реляционной БД данные распологаются в таблице, то можно легко видеть и сравнивать данные: достаточно посмотреть на соседние строки. В XML что бы увидеть соседние данные порой надо прокрутить десятки а то и сотни строк ненужной информации. С помощью XPath и XSLT можно трансформировать XML в таблицу и посмотреть на данные с птичьего полета. Вот и ответ на вопрос: зачем нужны запросы к данным.

Если надо изменить имя колонки в реляционной БД, достаточно это сделать в одном месте. Если надо изменить имя элемента в XML, то это придется делать везде где этот элемент присутствует (я даже незнаю корректного способа как это проделать: Regexp, XSLT, PHP?) В любом случае XML Schema нужна.

Как бы есть плюсы и минусы в обоих подходах.

AlexShop, тебя постоянно срывает на воображаемые проблемы.

Я регулярно работаю с XML-конфигом того, что ты называешь фронт контроллера. Проблемы с поиском нужного места -- нет. Ты лучше расскажи, как ты держишь "базаданный" когфиг в системе управления версиями и как делаешь merge.

Crazy,
пока у меня нет конфига для Front Controller. Все написано в PHP (switch case statements). Со временем файл стал большим, несмотря на то что он только инклудит другие файлы (page controllers). Вот я думаю переписать его и сделать конфигурационный файл (таблицу). CVS не пользуюсь .

Вот Crazy скажи: в чем смыл переписывания с PHP на XML? Чем длинный код на XML отличается от длинного кода на PHP в данном случае?

----
Вопрос про систему управления версиями хорош (особенно для сторонников Table Oriented Programming). ИМХО проблема решается хранением таблиц в CSV файлах. Гугл выдает много страниц на запрос "database version control", наверняка есть другие решения, я этим не занимался.

AlexShop писал(а):

в чем смыл переписывания с PHP на XML?

"Separation of concerns" (c)

Цитата:

Чем длинный код на XML отличается от длинного кода на PHP в данном случае?

Тем, что это дает уверенность, что конфиг содержит только статические данные и не ходит, к примеру, к внешнему серверу по SOAP при обработке каждого запроса.

Цитата:

ИМХО проблема решается хранением таблиц в CSV файлах.

В данном случае "ИМХО" переводится как "я сам не пробовал, но чисто теоретически есть ненулевая вероятность, что при каких-то условиях эта идея не является абсолютно бессмысленной"?

Ну да, при каких-то -- не является.

Как говориться: начинающий программист пишет код понятный для компьютера, а опытный программист пишет код понятный для других программистов. Поэтому меня интересует: насколько удобно использовать XML в качестве файла конфигурации для Фронт-Контроллера.

В базе данных информация хранится в бинарном виде и для чтения информации нужны специальные программы и запросы.
В XML информация хранится в текстовом файле и его можно открыть в любом текстовом редакторе, читать и понять код. В этом есть большое приемущество XML.

Проблема: если XML файл становиться громоздким, то мы читая перестаем понимать код. Код предназначается больше для компьютера, чем для человека и XML теряет свое приемущество. Зачем информацию хранить в текстовом виде если мы не понимаем ее? Информацию можно хранить в бинарном виде.

Вот пример, когда XML делает информацию трудной для понимания:

математическое выражение:
в XML выглядело бы примерно так:

Что легче читать? Информация (о числах) потерялась за ХML элементами: получилось 90% элементов и всего 10% текста. Поэтому я и спросил: зачем переписывать PHP код в ХML?

Если использовать специальные объекты для Фронт-Контроллера, то возможно что PHP код будет компактнее и читаться легче чем ХML. Эти объекты также могут решать вопросы по оптимизации и Separation of concerns. Это я и хочу выяснить: есть ли приемущества перехода от PHP на XML?

А приемущества есть:
1. Да, ХML это статические данные. Но эти данные изменяют ход программы (как PHP операторы). Почему написание PHP кода длиной в тысячу строк является табу, тогда как написание ХML кода той же длины нормально?

Первая попытка ответить:
ХML данные изменяют ход программы, но сам процесс изменения не происходит в ХML. Данные ХML обрабатываются в одном месте и на их основе принимается решение о ходе программы. Но с PHP можно делать тоже самое: передавать данные на обработку в единственное место.

Думаю верный ответ:
На XML файл легко поставить ограничения, а в PHP пиши что хочешь под собственную ответственность. Так мы подходим к приемуществу номер два:

2. XML можно проверить с помощью DTD (или другой XML Scheme) — чего нельзя сделать с PHP кодом.

3. Можно сделать запросы к ХML коду и получать различной подробности отчеты — чего тоже нельзя сделать с PHP кодом.


Этими приемуществами обладает и информация находящиеся в базе данных:
1. Статические данные
2. Вместо XML Scheme — Database Scheme
3. SQL более сильный язык запросов, чем XPath

Плюс:
4. Быстрый поиск по индексам
5. Бинарный файл занимает меньше места, чем XML.

Минус:
бинарный файл не читается в текстовом редакторе. Но XML также может быть труден для понимания при чтении в текстовом редакторе.


Такие вот мысли вслух

AlexShop писал(а):

Поэтому меня интересует: насколько удобно использовать XML в качестве файла конфигурации для Фронт-Контроллера.

Для этого достаточно реализовать проект с использованием такого конфига. Настоящий проект.

Цитата:

Проблема: если XML файл становиться громоздким, то мы читая перестаем понимать код. Код предназначается больше для компьютера, чем для человека и XML теряет свое приемущество.

народ писал(а):

- Доктор, когда я делаю вот так -- у меня болит вот здесь. - А вы, дорогой мой, вот так не делайте.

Мораль: не нужно создавать такой XML. Нужно создавать понятный XML. К примеру, авторы struts осознали это 9 лет назад.

Цитата:

Зачем информацию хранить в текстовом виде если мы не понимаем ее?

Я поскипал следующий пример как не имеющий отношения к обсуждаемой теме. Да. Можно придумать пример бессмысленного использования XML. Но это никак не противоречит осмысленному использованию XML. См. выше процитированный анекдот.

Цитата:

Эти объекты также могут решать вопросы по оптимизации и Separation of concerns.

Лучше было время, потраченное на придумывания примера с бессмысленным XML, использования для написания примера separation of concerns в PHP.

Цитата:

На XML файл легко поставить ограничения, а в PHP пиши что хочешь под собственную ответственность. Так мы подходим к приемуществу номер два:

Это ОДНО И ТО ЖЕ преимущество. Мы можем наложить ограничения В ВИДЕ dtd или схемы.

Цитата:

чего нельзя сделать с PHP кодом.

bye-bye, separation of concerns?

Цитата:

Этими приемуществами обладает и информация находящиеся в базе данных: 1. Статические данные 2. Вместо XML Scheme — Database Scheme 3. SQL более сильный язык запросов, чем XPath

Хранящиеся в базе данные не обязательно являются статикой; Database Scheme, в отличие от XML Scheme, не переносима между разными СУБД и, в общем случае, не позволяет проверить корректность данных, не загрузив их предварительно в базу; чисто теоретически я могу допустить возможность ситуации, в которой средств XPath нехватает для работы с конфигом, однако мотивация разработчика, который этот конфиг спроектировал, находится выше моего понимания (см. ниже про непрофильное образование).

Цитата:

Плюс: 4. Быстрый поиск по индексам 5. Бинарный файл занимает меньше места, чем XML.

Читаю и плачу. Конфиг такого размера, что в нем требуется индексный поиск и существенной становится экономия места? Буду откровенен: написание конфигов размером в гигабайт является признаком мозговой болезни. Ввиду отсутствия профильного образования я не буду это комментировать.

Цитата:

Такие вот мысли вслух

Резюме: это моя последняя реплика в обсуждениях сферических коней в вакууме. Мне стало окончательно скучно.

Crazy,
выражение 3(1+2) вполне имеет практическое применение, например: цена = кол-во ( стоимость + наценка ).

В XML можно хранить различные формулы вычиления цены. Приведеный выше XML код наверно самый верный, потому что запись:
<price>quantity (cost + extra_charge)</price> хоть и легче читается, но имеет недостатки:

1. Запись надо парсировать eval() или своими средствами.
2. Операторы +-*/ ненадежны для денежных вычислений. См. тему: PHP мат. операторы (век живи - век учись).

В PHP правильное выражение читалось бы не легче чем в XML, например:
$price = bcmul($quantity, bcadd($cost, $extra_charge, 2), 2);

Когда я думаю о XML, мне хочется больше узнать о constraint programming.

Вообщем я сделал XML конфиг для фронт-контроллера. Работает он похоже на mod_rewrite:
адрес страницы (точнее URI) сравнивается с regex-выражением и вызывает соответствующий файл, класс и метод. Как и в mod_rewrite использую backreferences: $1 $2 и т.д.