Сейчас для логической организации во "мэйнстримовых" языках применяется иерархическая организация — пространства имен, пакеты и т.п. Однако жизнь штука сложная и не всегда хорошо вписывается в иерархическую схему. У меня часто возникали ситуации, когда более естественным способом организовать типы и функции в программе была бы фасеточная классификация, где гранями являются функциональные аспекты системы. Но фасеточная классификация неоднозначно отображается в иерархическую, что порождает некоторые проблемы, особенно если над проектом работает несколько людей.
Собственно, вопрос: как Вы думаете, имеет ли право на полную и насыщенную пользой жизнь идея организации программ через систему граней/тэгов?
В принципе, это возможно и при поддержке со стороны языка, так и чисто инструментальными средствами. Например, плагин в IDE, который "заряжается" тэгами и строит на основании их иерархию определенным образом, заодно следя, что бы программист ручками не нарушил правильного порядка. Например, это было бы вполне естественной епархией решарпера.
Здравствуйте, 0x7be, Вы писали:
0>У меня часто возникали ситуации, когда более естественным способом организовать типы и функции в программе была бы фасеточная классификация, где гранями являются функциональные аспекты системы.
Реквестирую содержательные примеры, наводящие соображения и прочие промежуточные звенья рассуждений, что привели топик-стартера к вопросу в исходном сабже.
Здравствуйте, Qbit86, Вы писали:
Q>Реквестирую содержательные примеры, наводящие соображения и прочие промежуточные звенья рассуждений, что привели топик-стартера к вопросу в исходном сабже.
Участвую в разработке серверного антивирусного продукта, который проверяет циркулирующую в информационной системе информацию. Проверка ведется, собственно, антивирусным движком и движком, фильтрующим содержимое (например — спамфильтр). То есть уже две граним: антивирь, антиспам. Далее, проверка может быть осуществлена в двух разных сценариях — по инициативе контролируемой ИС и по нашей инициативе. Вот тебе ещё две грани, причем есть код, который специфичен для всех комбинацией грани из первой пары и из второй, равно как и код, принадлежащий этим граням по отдельности. Далее, базы данных для сканеров надо скачивать: плюс грань "скачивалка". Разработка ведется на .net с привлечением нативных компонентов и интерфейсов с ИС: плюс грань "интероп". Ещё для этих подсистем есть свой гуй, который тоже суть грань. И много ещё чего есть, все лень писать.
Сначала в проекте не было системного подхода к организации сборок и пространств имен, что привело к анархии в этом вопросе и большой энтропии в структуре проекта. Потом это надоело, все было пересмотрено, были выделены грани (означенные выше и не только), они были кодифицированы и занесены в инструкцию. Отображение на иерархическую структуру делалось так: все грани разранжировали и при необходимости составить путь к конкретному компоненту пользовались этим ранжированием. Например, решили, что "ативтирус" приоритетнее, чем "скачивалка", значит скачивалка для антивируса будет обзываться "антивирус.скачивалка". А код "просто скачивалки", будет располагаться в пространстве имен "скачивалка", ибо более приоритетной грани у неего нет. И грань "интероп" наименее приоритетная, так что интероп для скачивалки будет лежать в "скачивалка.интероп". На основании этого был проведен Большой Рефакторинг.
Данный метод, в принципе, неплох, но он обладает всеми недостатками административных методов. "Суровость законом компенсируется их необязательностью" и все такое, то есть надо следить, что бы люди были знакомы с документом, надо документ актуализировать по мере появления этих граней, надо следить, что бы люди действовали в соответствии с правилами и т.п. Хотелось бы инструментальной поддержки для этой активности.
Здравствуйте, 0x7be, Вы писали:
0>Сначала в проекте не было системного подхода к организации сборок и пространств имен, что привело к анархии в этом вопросе и большой энтропии в структуре проекта.
А почему вы думаете, что с тегами будет проще? Проблема — не в способе описания, а в том, что вы пытаетесь применить средство самодокументирования к области, для которой вы ещё не придумали способ классификации.
Если вы перейдёте к меткам, то фактически будете поощрять дальнейшую энтропию. Всё, что вы получите — множество равноправных иерархий вместо одной, но частично кривой. Посмотрите на самые удачные примеры тегирования — wiki и stackowerflow. Как, удобно?
Summary: если бардак не автоматизируется, неймспейсы винить как-то глупо
Если вернуться к примеру с антивирусом — почему нельзя было пойти самым простым путём — завести
YourCompany.Antivirus, YourCompany.Helpers.Downloader, YourCompany.Helpers.Interop etc?
Зачем вводить двустороннюю связность в именование и в архитектуру проекта? У вас что, скачивалка зависит каким-либо образом от антивируса? А интероп использует API скачивалки? Зачем их смешивать?
Здравствуйте, Sinix, Вы писали:
S>А почему вы думаете, что с тегами будет проще? Проблема — не в способе описания, а в том, что вы пытаетесь применить средство самодокументирования к области, для которой вы ещё не придумали способ классификации.
Нет, способ классификации мы придумали
Только он получился фасеточный, а не иерархический
S>Если вы перейдёте к меткам, то фактически будете поощрять дальнейшую энтропию. Всё, что вы получите — множество равноправных иерархий вместо одной, но частично кривой. Посмотрите на самые удачные примеры тегирования — wiki и stackowerflow. Как, удобно?
Да нет же, фасеточная классификация не подразумевает каких-либо отношений между отдельными гранями.
Какое "множество равноправных иехрархий", откуда?
S>Summary: если бардак не автоматизируется, неймспейсы винить как-то глупо S>Если вернуться к примеру с антивирусом — почему нельзя было пойти самым простым путём — завести S>YourCompany.Antivirus, YourCompany.Helpers.Downloader, YourCompany.Helpers.Interop etc? S>Зачем вводить двустороннюю связность в именование и в архитектуру проекта? У вас что, скачивалка зависит каким-либо образом от антивируса?
По-моему ты не очень внимательно прочитал мой пример. Или я его криво описал
Да, есть модуль "скачивалка", а есть модули, адаптирующие его к антивирю и антисмаму, ибо есть у них в плане качения баз своя специфика. То есть модули, которые связаны И со скачивалкой И с антивирусом/антиспамом.
Куда их помещать в единой иерархической структуре?
S>А интероп использует API скачивалки? Зачем их смешивать?
А интероп — это вообще отдельный аспект подсистемы, в которой задействован нативный компонент. То есть свой интероп есть и у антивиря, и у антиспама, и у скачивалки и ещё есть. То есть у нас есть "антивирь.интероп", "антиспам.интероп"... Понятно, что антивирус не имеет никаких дел с интеропом скачивалки.
Здравствуйте, 0x7be, Вы писали:
0>По-моему ты не очень внимательно прочитал мой пример. Или я его криво описал 0>Да, есть модуль "скачивалка", а есть модули, адаптирующие его к антивирю и антисмаму, ибо есть у них в плане качения баз своя специфика. То есть модули, которые связаны И со скачивалкой И с антивирусом/антиспамом. 0>Куда их помещать в единой иерархической структуре?
S>>А интероп использует API скачивалки? Зачем их смешивать? 0>А интероп — это вообще отдельный аспект подсистемы, в которой задействован нативный компонент. То есть свой интероп есть и у антивиря, и у антиспама, и у скачивалки и ещё есть. То есть у нас есть "антивирь.интероп", "антиспам.интероп"... Понятно, что антивирус не имеет никаких дел с интеропом скачивалки.
ИМХО, мысль интересная. У вас есть идеи, как это реализовать на уровне синтаксиса некоего гипотетического языка программирования?
И можно ли это совместить с традиционной иерархической организацией?
Здравствуйте, x-code, Вы писали:
XC>ИМХО, мысль интересная. У вас есть идеи, как это реализовать на уровне синтаксиса некоего гипотетического языка программирования? XC>И можно ли это совместить с традиционной иерархической организацией?
Пока нет, хотя мысли на этот счет крутятся.
Сказать по правде, идею поддержать это на уровне языка я считаю несколько утопической.
В том смысле, что в массы не пойдет, слишком революционное изменение.
Мне более перспективной кажется инструментальная поддержка такого стиля.
Здравствуйте, 0x7be, Вы писали: 0>Нет, способ классификации мы придумали 0>Только он получился фасеточный, а не иерархический 0>Какое "множество равноправных иехрархий", откуда?
Ну смотрите, у нас есть 2 крайних варианта:
1) (очевидно, не ваш случай) фасеты не пересекаются — что мешает их переобозвать в namespace?
2) одни и те же классы используются в нескольких фасетах — что мешает вынести эти классы в отдельные namespace?
Второй вариант как раз и превращается в кучу равноправных классификаторов. Если вы даже промеж себя никак не договоритесь, что куда отнести — как тут помогут фасеты?
Основное предназначение namespace-ов — самодокументирование, отражение структуры проекта и пояснение назначения его составляющих. Если перейти к меткам, то у нас всё вышеперечисленное отпадает и появляется куча вопросов аля
— "[Antivirus].Downloader" и "[AdwareBlocker].Downloader" — это один и тот же класс, или несколько?
— Если один — почему он нарушает SRP и делает 2 работы одновременно?
— Если он не нарушает, и это просто универсальный класс — каким боком он относится к антивирусу или адблоку?
0>Да, есть модуль "скачивалка", а есть модули, адаптирующие его к антивирю и антисмаму, ибо есть у них в плане качения баз своя специфика. То есть модули, которые связаны И со скачивалкой И с антивирусом/антиспамом. 0>Куда их помещать в единой иерархической структуре?
Последний идентификатор — имя класса.
Для _больших_ проектов:
-YourCompany.Components.Net.Downloader,
-YourCompany.YourProduct.SelfUpdate.UpdaterBase,
-YourCompany.YourProduct.Feature1.SelfUpdate.Feature1Updater,
-YourCompany.YourProduct.Feature2.SelfUpdate.Feature2Updater.
Для мелких:
-YourCompany.Net.Downloader,
-YourCompany.Antivirus.AntivirusUpdater,
-YourCompany.AdwareBlocker.AdwareBlockerUpdater.
Смысл такого разделения, в том, что _используемый_ компонент не должен ничего знать об остальном коде. Иначе у вас возникает сильная связь между всеми частями проекта: начинаете править downloader под сценарий для антивируса, ломаете адблокер.
0>А интероп — это вообще отдельный аспект подсистемы, в которой задействован нативный компонент. То есть свой интероп есть и у антивиря, и у антиспама, и у скачивалки и ещё есть.
Ну если это просто вспомогательный код, и он никак не переиспользуется — пусть живёт в YourCompany.Antivirus.Interop. При чём здесь фасеты?
Попробую ещё раз сформулировать свою точку зрения, чтобы не было разночтений:
Метки полезны только для поиска. Когда нет структуры, она не отражает действительность, или нет никакого желания в ней разбираться. Предлагать метки как основное решение — мягко говоря, ересь
Здравствуйте, Sinix, Вы писали:
S>Второй вариант как раз и превращается в кучу равноправных классификаторов. Если вы даже промеж себя никак не договоритесь, что куда отнести — как тут помогут фасеты?
Как раз промеж себя договоренность есть, просто она не вписывается в иерархическую модель.
Попытка отобразить это на иерархическую модель всегда будет приводит к условностям, которых хотелось бы избежать.
S>Основное предназначение namespace-ов — самодокументирование, отражение структуры проекта и пояснение назначения его составляющих. Если перейти к меткам, то у нас всё вышеперечисленное отпадает и появляется куча вопросов аля S>- "[Antivirus].Downloader" и "[AdwareBlocker].Downloader" — это один и тот же класс, или несколько? S>- Если один — почему он нарушает SRP и делает 2 работы одновременно? S>- Если он не нарушает, и это просто универсальный класс — каким боком он относится к антивирусу или адблоку?
Это в зависимости о того, как трактовать фасеты.
Например, не возникает же вопросов, один ли класс "Antivirus.Downloader" или "Adblock.Downloader" в традиционных пространствах имен.
Если принять, что совокупность фасетов + имя класса однозначно определяет уникальный класс, то вопросов не будет — это будут однозначно разные классы.
Вообще, если модуль находится строго на стыке двух функциональных областей, то попытка отнести его либо к одной либо к другой все равно приводит к натяжкам. Это фундаментальный недостаток иерархической модели.
S>Для _больших_ проектов: S>... S>Для мелких: S>...
Как вариант. Мы сделали похожим образом — директивно определили, что "antivirus" приоритетное "updater`a" и модули, где пересекаются этих области
помещаем не в "updater.antivirus", а в "antivirus.updater". Но это лишь соглашение, а не объективная реальность.
S>Смысл такого разделения, в том, что _используемый_ компонент не должен ничего знать об остальном коде. Иначе у вас возникает сильная связь между всеми частями проекта: начинаете править downloader под сценарий для антивируса, ломаете адблокер.
У нас "antivirus" не на прямую использует "antirivus.updater", они оба используются другими классами, оркестрирующими их работу.
В итоге такой порядок отображения фасетов на пространства имен не более чем условность.
S>Попробую ещё раз сформулировать свою точку зрения, чтобы не было разночтений: S>Метки полезны только для поиска. Когда нет структуры, она не отражает действительность, или нет никакого желания в ней разбираться. Предлагать метки как основное решение — мягко говоря, ересь
Я понял Вашу точку зрения, но не согласен с ней. Если несколько обобщить Ваши слова, то получается утверждение, что только иерархическая классификация способна отражать структуру, а фасеточная — нет. Я рассматриваю оба этих метода классификации как равноправные, со своей областью применимости каждый. И в конкретно своей ситуации я констатирую, что фасеточная классификация пригодилась бы мне больше.
Здравствуйте, 0x7be, Вы писали:
0>Как раз промеж себя договоренность есть, просто она не вписывается в иерархическую модель.
Т.е. оба варианта выше не подходят? Невесело вам
0>Это в зависимости о того, как трактовать фасеты.
Ну, мы вроде сошлись на том, что один класс может принадлежать нескольким фасетам, нет?
0>Например, не возникает же вопросов, один ли класс "Antivirus.Downloader" или "Adblock.Downloader" в традиционных пространствах имен.
Да. Потому что неймспейсы не создают двусмысленностей
0>Если принять, что совокупность фасетов + имя класса однозначно определяет уникальный класс, то вопросов не будет — это будут однозначно разные классы.
Ок, интересная идея. Только она убивает расширяемость в зародыше. Потребуется переиспользовать downloader для файрволла — как быть тогда?
Я же говорю — вы отражаете в именах обратные зависимости. Получается, что у вас downloader зависит и от антивируса, и от адблока и т.д. и т.п. Хотя в идеальном случае он должен быть просто вспомогательным классом, у которого ровно одна ответственность — скачивать данные.
0>Как вариант. Мы сделали похожим образом — директивно определили, что "antivirus" приоритетное "updater`a" и модули, где пересекаются этих области
Нет, вы сделали полностью обратную вещь: не разделили компоненты, а установили сильную связность между ними. Вы сделали обновлятор частью антивируса, и, тем самым, показали, что обновлятор не должен нигде больше использоваться, хотя на самом деле это не так. И, что самое худшее, вы делаете долгосрочные решения, напрямую влияющие на архитектуру софта на основании произвольно выбранных критериев.
0>У нас "antivirus" не на прямую использует "antirivus.updater", они оба используются другими классами, оркестрирующими их работу.
Тогда в неймспейсе "antirivus.updater" должна остаться только та часть, что знает об антивирусе и она должна быть унаследована от базового класса/интерфейса.
0>В итоге такой порядок отображения фасетов на пространства имен не более чем условность.
Я вообще-то пытался отразить зависимости между компонентами. Если получилась условность — я не угадал, и у вас получается другой граф зависимостей.
0>Я понял Вашу точку зрения, но не согласен с ней. Если несколько обобщить Ваши слова, то получается утверждение, что только иерархическая классификация способна отражать структуру, а фасеточная — нет.
Фасеточная способна отразить только часть структуры, но не всю её целиком. Поэтому, если вы отказываетесь от иерархии вы отказываетесь от _явной_ модели софта/архитектуры.
0>Я рассматриваю оба этих метода классификации как равноправные, со своей областью применимости каждый. И в конкретно своей ситуации я констатирую, что фасеточная классификация пригодилась бы мне больше.
Пока что не увидел — почему.
Здравствуйте, Sinix, Вы писали:
S>Здравствуйте, 0x7be, Вы писали:
0>>Как раз промеж себя договоренность есть, просто она не вписывается в иерархическую модель. S>Т.е. оба варианта выше не подходят? Невесело вам
Ну, мы нашли командно-административный выход, директивно назначив конкретный способ отображения фасетов на иерархию пространств имен.
Было бы приятно, если бы некая тулза ещё бы и присматривала за этим в автоматическом режиме.
S>Ну, мы вроде сошлись на том, что один класс может принадлежать нескольким фасетам, нет?
Да.
S>Ок, интересная идея. Только она убивает расширяемость в зародыше. S>Потребуется переиспользовать downloader для файрволла — как быть тогда? S>... S>Я же говорю — вы отражаете в именах обратные зависимости. Получается, что у вас downloader зависит и от антивируса, и от адблока и т.д. и т.п. Хотя в идеальном случае он должен быть просто вспомогательным классом, у которого ровно одна ответственность — скачивать данные.
Не уловил. Впрочем, см. ниже.
S>Я вообще-то пытался отразить зависимости между компонентами. Если получилась условность — я не угадал, и у вас получается другой граф зависимостей.
Боюсь у нас тут некоторый miscommunication по поводу нашей архитектуры. Ниже попробую снова изложить.
S>Фасеточная способна отразить только часть структуры, но не всю её целиком. S>Поэтому, если вы отказываетесь от иерархии вы отказываетесь от _явной_ модели софта/архитектуры.
Ну, мы говорим всего лишь об организации кода, а это лишь малая часть архитектуры
S>Пока что не увидел — почему.
Ок, второй заход. Опишу минимальный набор компонентов, пригодный для иллюстрации идеи:
Есть следующие компоненты:
Updater — реализует в себе общую для всех часть функционала обновления.
AntivirusScanner — антивирусный сканер, использует Updater.
AntispamScanner — антиспамовый сканер, использует Updater.
AntivirusUpdater — антивирусный обновитель.
AntispamUpdater — антиспамовый обновитель.
Тут мы наблюдаем 4 фасета: Updater, Antivirus, Antispam, Scanner.
Фишка в том, что, например, AntivirusUpdater может быть расположен пространстве имен двумя РАВНОПРАВНЫМИ способами:
1. Antivirus.Updater.AntivirusUpdater.
2. Updater.Antivirus.AntivirusUpdater.
(ПРИМЕЧАНИЕ: порядок слов в самом идентификаторе AntivirusUpdater следует из правил английского языка )
Сейчас волевым решением выбран первый вариант, но объективно он ничем не лучше.
Это исключительно соглашение, что бы было "безобразно, но единообразно".
Далее, если мы захотим заиметь ещё один вид сканера, то у нас добавляется ещё один фасет.
Пусть это будет какая-нибудь порнорезалка. Естественным образом у нас появляется фасет Pornbuster, и компоненты PornbusterScanner и PornbusterUpdater.
Никаких "криминальных" зависимостей между компонентами, которые бы зарубили нам расширяемость, тут не наблюдается.
0>>Это в зависимости о того, как трактовать фасеты. S>Ну, мы вроде сошлись на том, что один класс может принадлежать нескольким фасетам, нет?
Интуитивно — понятно, на практике — мне неясно, как тогда ссылаться на класс.
0>>У нас "antivirus" не на прямую использует "antirivus.updater", они оба используются другими классами, оркестрирующими их работу. S>Тогда в неймспейсе "antirivus.updater" должна остаться только та часть, что знает об антивирусе и она должна быть унаследована от базового класса/интерфейса.
Хорошо. А почему бы не поместить эту часть в неймспейс updater.antivirus?
S>Я вообще-то пытался отразить зависимости между компонентами. Если получилась условность — я не угадал, и у вас получается другой граф зависимостей.
Граф тот же, способ его планаризации — другой.
S>Фасеточная способна отразить только часть структуры, но не всю её целиком. Поэтому, если вы отказываетесь от иерархии вы отказываетесь от _явной_ модели софта/архитектуры.
Они пытаются ввести многомерную классификацию. Примерно то же, что и с множественным наследованием. Вот у вас табличка с классами; по горизонтали — слои (DB, UI, BL), по вертикали — функциональные блоки. Никакой неопределённости в помещении того или иного класса в одну из ячеек нет. Есть зато неопределённость в том, как именовать неймспейсы: ui.anitivirus, ui.antispam, или antivirus.ui, antivirus.bl.
Мне неизвестен язык программирования, который бы позволил задать правило "в функциональном неймспейсе могут быть только поднеймспейсы bl, db, и ui". Или хоть как-то гарантировать, что вместо antispam.db не появится какой-нибудь antispam.database, сломав стройную структуру таблички.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, 0x7be, Вы писали:
0>Сейчас для логической организации во "мэйнстримовых" языках применяется иерархическая организация — пространства имен, пакеты и т.п. Однако жизнь штука сложная и не всегда хорошо вписывается в иерархическую схему. У меня часто возникали ситуации, когда более естественным способом организовать типы и функции в программе была бы фасеточная классификация, где гранями являются функциональные аспекты системы. Но фасеточная классификация неоднозначно отображается в иерархическую, что порождает некоторые проблемы, особенно если над проектом работает несколько людей.
0>Собственно, вопрос: как Вы думаете, имеет ли право на полную и насыщенную пользой жизнь идея организации программ через систему граней/тэгов? 0>В принципе, это возможно и при поддержке со стороны языка, так и чисто инструментальными средствами. Например, плагин в IDE, который "заряжается" тэгами и строит на основании их иерархию определенным образом, заодно следя, что бы программист ручками не нарушил правильного порядка. Например, это было бы вполне естественной епархией решарпера.
Если над проектом работает несколько человек, пишутся правила, которых надо придерживатся и все норм.
Что касается тегов, а как ты предполагаешь их использовать?
В существующих языках обычно используют namespace для определения к какому блоку функционала относится класс и суффиксы для доп тегов.
Например java.util.concurrent.ExecutorService. Имя пакета java.util.concurrent говорит с том что классы в нем предназначены для упрощения работы с многопоточностью а Service определяет роль класса.
Так же в качестве тегов используют метаинформацию (аннотации\атрибуты) — это если надо иметь возможность для оперирования или в рантайме.
Здравствуйте, Kefir, Вы писали:
K>гляньте code bubles, это вариант с реализацией в IDE.
Занятная штука, но что-то не увидел там именно фасеточности/тэговости.
Может плохо смотрел
дико извиняюсь, но по-моему вы только создаете себе проблемы.
нету у вас никаких проблем с namespaces, у вас есть проблемы с зависимостями между типами.
[]
S>>Пока что не увидел — почему. 0>Ок, второй заход. Опишу минимальный набор компонентов, пригодный для иллюстрации идеи: 0>Есть следующие компоненты: 0>Updater — реализует в себе общую для всех часть функционала обновления. 0>AntivirusScanner — антивирусный сканер, использует Updater. 0>AntispamScanner — антиспамовый сканер, использует Updater. 0>AntivirusUpdater — антивирусный обновитель. 0>AntispamUpdater — антиспамовый обновитель.
0>Тут мы наблюдаем 4 фасета: Updater, Antivirus, Antispam, Scanner. 0>Фишка в том, что, например, AntivirusUpdater может быть расположен пространстве имен двумя РАВНОПРАВНЫМИ способами: 0>1. Antivirus.Updater.AntivirusUpdater. 0>2. Updater.Antivirus.AntivirusUpdater.
ну и в чем проблема? зачем тут какие-то фасеты?
ну и расположи либо в 1 либо в 2, исходя из архитектуры приложения и наименьшей связности кода.
[]
namespace <AVCo>.<Product>.Client.Common.Updates
{
class Updater {}
}
namespace <AVCo>.<Product>.Client.Scanners
{
class AntivirusScanner {}
class AntispamScanner {}
}
namespace <AVCo>.<Product>.Client.Scanners.Updates
{
class AntivirusUpdater {}
class AntispamUpdater {}
}
я не вижу причин почему я должен умело ориентироваться в трехмерных фигурах, которые суть отражают структуру типов проекта. у меня есть дела и поважнее.
Не то чтобы идея совсем неинтересна, просто с мотивацией что-то не то.
Даже в примеры не хочу вникать . Ересь эта фасеточная ваша модель.
Программист всегда будет конструировать структруры (фасет ваш тоже структура в конечном итоге).
А самая удобная модель структуры — дерево. Не произвольный граф, а именно дерево.
Вы можете построить любую структуру поверх дерева (заюзав тэги, идентификаторы).
Здравствуйте, barn_czn, Вы писали:
_>Даже в примеры не хочу вникать . Ересь эта фасеточная ваша модель.
"Не читал, но осуждаю"
_>Программист всегда будет конструировать структруры (фасет ваш тоже структура в конечном итоге).
Согласен.
_>А самая удобная модель структуры — дерево. Не произвольный граф, а именно дерево.
Спорно. Какие Ваши аргументы?
_>Вы можете построить любую структуру поверх дерева (заюзав тэги, идентификаторы).
Можем, но если предметная область не вписывается в иерархическую модель, то зачем себя насиловать?
