Хабр Курсы для всех
РЕКЛАМА
Большая витрина: от крупнейших школ до частных авторов. Сравнивайте по цене, длительности, формату и выбирайте самый подходящий курс!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 107
На мой взгляд, при разработке системы лояльной к плугинам важно учитывать тот момент, что нельзя «заплугинить» всё и вся… и если они переплетутся обработками событий друг друга… то ничего хорошего из этого не выйдет… это как в 1С — проще будет кое что подправить в самой системе чем писать что то своё, в этом случае нужно сразу при разработке системы выделить тот функционал в который можно будет вмешиваться плугинам.
Все что написал в любом случае ИМХО и не противоречит статье, автору спасибо за интересный материал ;)
Все что написал в любом случае ИМХО и не противоречит статье, автору спасибо за интересный материал ;)
Да что ж за болезнь такая.
Какие плугины? Плагины!
Зачем коверкать иностранные слова?
Они от этого русскими не станут.
Какие плугины? Плагины!
Зачем коверкать иностранные слова?
Они от этого русскими не станут.
а зачем самому это всё реализовывать? Разве MEF не решает эту задачу?
прошу прощения. не к месту коммент.
По-моему действительно велосипед с опозданием лет на 5. Подобная архитектура уже давно реализована в любом MVC-фреймворке. В Spring например есть DispatchServlet, IoC и AOP interceptors. Struts тоже реализован подобным образом. Ценю идейность, но прежде чем рожать что-то, нужно сделать мало-мальский обзор того, что уже есть и того, чего еще нет, но хотелось бы. А уже затем придумывать гениальные решения.
придумывать то можно, никто не запретит, а вот браться за реализацию не стоит…
Народ!… это лишь маленький толчок для понимания идеи MVC-фреймворков для начинающих! )
Много людей еще учится, и им очень необходимое такое легкое разъяснение, как можно что-то сделать лучьше.
Веждь поначалу очень тяжело понимать общедоступную документацию, и разяснения, а тут все коротко и сно =)
Много людей еще учится, и им очень необходимое такое легкое разъяснение, как можно что-то сделать лучьше.
Веждь поначалу очень тяжело понимать общедоступную документацию, и разяснения, а тут все коротко и сно =)
Только к середине поста понял, что везде под «системой», «ядром» и т.д. понимается какой-то довольно частный случай системы — веб-приложение, и то даже его частный случай. Да, идея понятна, но непонятно почему всё же «ненормальное программирование»?)
Ненормальное оно из-за больших частностей. Не всегда применимо в реальной жизни, а иногда, зачастую, избыточно.
Очень прошу, подправьте в начале статьи «как создать такое ядро системы, » на «как создать такое ядро системы управления веб-сайтом, »!
Почему только вебсайтом? Я не согласен. Да, схема больше веб-ориентированая, но не обязательно.
потому что вы оперируете понятиями get/post и template->html, css, js
Сами понятия get и post не только http, можно любой процесс передачи события от любого устройства привести к данным абстрактным понятиям.
А темплейтирование может быть не только для веба. Можно смело интегрировать веб-движки в программу и рисовать интерфейсы при помощи HTML/XML/CSS/JS. Это, возможно, даже дешевле будет, чем формы билдером каким-то рисовать. Да, и темплейт-система может выдавать XML, который потом можно использовать где угодно.
А темплейтирование может быть не только для веба. Можно смело интегрировать веб-движки в программу и рисовать интерфейсы при помощи HTML/XML/CSS/JS. Это, возможно, даже дешевле будет, чем формы билдером каким-то рисовать. Да, и темплейт-система может выдавать XML, который потом можно использовать где угодно.
К данным абстрактным понятиям можно притянуть за уши даже вызов метода класса. Но реализация подобного подхода требует накладных расходов, которые далеко не везде нужны. Так что без нужды притягивать не стоит.
Веб-движок в программе — всё равно веб-движок. Напишите хотя бы «как создать такой веб-движок, », если Вам «веб-двидок» больше нравится, чем «ядро системы управления веб-сайтом».
С первых строк статьи надо очертить тему, а не вводить людей в заблуждение.
Веб-движок в программе — всё равно веб-движок. Напишите хотя бы «как создать такой веб-движок, », если Вам «веб-двидок» больше нравится, чем «ядро системы управления веб-сайтом».
С первых строк статьи надо очертить тему, а не вводить людей в заблуждение.
«Сами понятия get и post не только http, можно любой процесс передачи события от любого устройства привести к данным абстрактным понятиям.»
Нет, нельзя. К этим понятиям можно привести только ситуацию, когда у вас клиентское (или программное) действие преобразуется в запрос, который дальше идет по маршруту (то есть, message-based communication), причем одностороннему. Как только вам надо реализовать ситуацию, при которой в качестве реакции на событие надо получить не только данные, входящие в событие (=те, которые вы передали в запросе), но и какие-то другие с той же стороны, эта модель честно отдыхает.
(собственно, почему asp.net web forms нельзя один в один перенести на mvc)
Собственно об этом вся ваша идея говорит — и запрос на входе, и цепочка обработчиков — вы ориентируетесь на «сообщения», которые плывут по каналу, и которые вы модифицируете по пути. Но, честное слово, далеко не всякую систему эффективно так представлять.
В вебе это логично, потому что в итоге основной процесс обработки веб-события именно так и устроен. Но в rich applications это не так.
«Можно смело интегрировать веб-движки в программу и рисовать интерфейсы при помощи HTML/XML/CSS/JS. Это, возможно, даже дешевле будет, чем формы билдером каким-то рисовать.»
Вы сами это пробовали, или абстрактно рассуждаете?
А то я хочу напомнить, что вам эти псевдоформы потом надо интегрировать с реальным движком без участия веб-сервера.
«Да, и темплейт-система может выдавать XML, который потом можно использовать где угодно. „
Это, кстати, тоже неправда. Написать парсер, который будет по xml строить интерфейс, а потом обратно обратывать события и датабиндинг — это, конечно, круто, но пока никому особо не удавалось в полный рост: слишком много ограничений это накладывает.
Нет, нельзя. К этим понятиям можно привести только ситуацию, когда у вас клиентское (или программное) действие преобразуется в запрос, который дальше идет по маршруту (то есть, message-based communication), причем одностороннему. Как только вам надо реализовать ситуацию, при которой в качестве реакции на событие надо получить не только данные, входящие в событие (=те, которые вы передали в запросе), но и какие-то другие с той же стороны, эта модель честно отдыхает.
(собственно, почему asp.net web forms нельзя один в один перенести на mvc)
Собственно об этом вся ваша идея говорит — и запрос на входе, и цепочка обработчиков — вы ориентируетесь на «сообщения», которые плывут по каналу, и которые вы модифицируете по пути. Но, честное слово, далеко не всякую систему эффективно так представлять.
В вебе это логично, потому что в итоге основной процесс обработки веб-события именно так и устроен. Но в rich applications это не так.
«Можно смело интегрировать веб-движки в программу и рисовать интерфейсы при помощи HTML/XML/CSS/JS. Это, возможно, даже дешевле будет, чем формы билдером каким-то рисовать.»
Вы сами это пробовали, или абстрактно рассуждаете?
А то я хочу напомнить, что вам эти псевдоформы потом надо интегрировать с реальным движком без участия веб-сервера.
«Да, и темплейт-система может выдавать XML, который потом можно использовать где угодно. „
Это, кстати, тоже неправда. Написать парсер, который будет по xml строить интерфейс, а потом обратно обратывать события и датабиндинг — это, конечно, круто, но пока никому особо не удавалось в полный рост: слишком много ограничений это накладывает.
Вы сами это пробовали, или абстрактно рассуждаете?
Если я не ошибаюсь, так построен был (а наверное и есть) Explorer в Windows (не совсем понятно, зачем ему тогда mshtml.dll, если это не так)
Это, кстати, тоже неправда. Написать парсер, который будет по xml строить интерфейс, а потом обратно обратывать события и датабиндинг — это, конечно, круто, но пока никому особо не удавалось в полный рост: слишком много ограничений это накладывает.
Flex (Flash), XUL (Mozilla).
«Если я не ошибаюсь, так построен был (а наверное и есть) Explorer в Windows (не совсем понятно, зачем ему тогда mshtml.dll, если это не так)»
То есть, не пробовали.
Explorer умеет показывать html в своем окне, но он не пользуется им для формирования основного интерфейса.
«Flex (Flash), XUL (Mozilla). „
(а) покажите мне нормальный two-way-databinding в XUL
(б) покажите мне нормальное line-of-business приложение на XUL, хотя бы на 50-80 полей ввода со сложными зависимостями.
То есть, не пробовали.
Explorer умеет показывать html в своем окне, но он не пользуется им для формирования основного интерфейса.
«Flex (Flash), XUL (Mozilla). „
(а) покажите мне нормальный two-way-databinding в XUL
(б) покажите мне нормальное line-of-business приложение на XUL, хотя бы на 50-80 полей ввода со сложными зависимостями.
Лично я не пробовал.
(a) Почему именно two-way-databinding? Почитайте вот
это
(б) Если такое приложение можно реализовать на HTML, то его аналогично можно реализовать и на XUL.
Кстати, я легко могу сделать на XUL two-way-databinding. Для этого мне понадобится копеечные трудозатраты — всего лишь сделать надстройку для некого хранилища данных.
(a) Почему именно two-way-databinding? Почитайте вот
это
(б) Если такое приложение можно реализовать на HTML, то его аналогично можно реализовать и на XUL.
Кстати, я легко могу сделать на XUL two-way-databinding. Для этого мне понадобится копеечные трудозатраты — всего лишь сделать надстройку для некого хранилища данных.
«Почему именно two-way-databinding? Почитайте вот „
Потому что это один из немногих cost-effective способов работать с данными в интерфейсе. Как бы, каждый раз вручную перекладывать данные из контролов в хранилище и обратно — излишняя трата труда.
“Если такое приложение можно реализовать на HTML, то его аналогично можно реализовать и на XUL.»
На HTML его реализовать нельзя, очевидно. Его можно реализовать на веб-интерфейсе, про что и идет речь выше.
Потому что это один из немногих cost-effective способов работать с данными в интерфейсе. Как бы, каждый раз вручную перекладывать данные из контролов в хранилище и обратно — излишняя трата труда.
“Если такое приложение можно реализовать на HTML, то его аналогично можно реализовать и на XUL.»
На HTML его реализовать нельзя, очевидно. Его можно реализовать на веб-интерфейсе, про что и идет речь выше.
Признаю, использовал упрощение, но суть понятна, XUL без js не будет интерактивным.
А построить нужный интерфейс на нем не представляет труда. Лично я не знаю приложений на XUL, но это не значит, что их не существует.
А построить нужный интерфейс на нем не представляет труда. Лично я не знаю приложений на XUL, но это не значит, что их не существует.
Построить LOB на html+js без бэкенда (сервисов) невозможно. Как только появляются сервисы — мы, по сути, возвращаемся к веб-архитектуре (попробуйте из js обратиться к чистому TCP-сервису, да и то, сервисы все равно работают по request-reponse модели)
Про что и говорили выше — ваши подходы хороши в рамках одной парадигмы. Но ей жизнь не ограничивается совершенно,
Про что и говорили выше — ваши подходы хороши в рамках одной парадигмы. Но ей жизнь не ограничивается совершенно,
У mozilla есть все, чтобы на данный момент времени быть standalone приложением.
Mira, Songbird, ThunderBird… Все построено без сервисов.
Если вы намеренно хотите уменьшить сферу применения к одной парадигме, то я не буду вам мешать.
Mira, Songbird, ThunderBird… Все построено без сервисов.
Если вы намеренно хотите уменьшить сферу применения к одной парадигме, то я не буду вам мешать.
И что из этого LOB на 50-70 полей? Вот-вот.
Сонгберд — медиа-плеер (кстати, он правда на XUL? или все-таки только интерфейс на XUL, а все компоненты нормально изолированы?)
Тандерберд правда сам написан на XUL, или это только язык дополнений к нему?
«Если вы намеренно хотите уменьшить сферу применения к одной парадигме, то я не буду вам мешать. „
А вы пока не показали ни одного контр-примера, вот в чем дело.
Сонгберд — медиа-плеер (кстати, он правда на XUL? или все-таки только интерфейс на XUL, а все компоненты нормально изолированы?)
Тандерберд правда сам написан на XUL, или это только язык дополнений к нему?
«Если вы намеренно хотите уменьшить сферу применения к одной парадигме, то я не буду вам мешать. „
А вы пока не показали ни одного контр-примера, вот в чем дело.
XUL — язык построения интерфейсов. Интерфейс общается к функционалу проигрывателя через JS-прослойку. Gecko выступает в роли ядра всей системы. В SongBird'е есть плагины, которые не связаны с функционалом плеера.
Firefox для интерфейса использует XUL.
Контр-пример показываю, вы не считаете это за контр-пример.
Firefox для интерфейса использует XUL.
Контр-пример показываю, вы не считаете это за контр-пример.
«Контр-пример показываю, вы не считаете это за контр-пример. „
Я просил “покажите мне нормальное line-of-business приложение на XUL, хотя бы на 50-80 полей ввода со сложными зависимостями. „
То, что вы показываете, с точки зрения интерфейса ввода данных — мелкие поделки.
Я просил “покажите мне нормальное line-of-business приложение на XUL, хотя бы на 50-80 полей ввода со сложными зависимостями. „
То, что вы показываете, с точки зрения интерфейса ввода данных — мелкие поделки.
Тут есть ответ на ваш вопрос?
Нет. Там не раскрывается, как именно «uses XUL» и почему.
надо было написать статью как разбор работы какогото существующего фреймворка, а то читается как очередное открытие америки
К фдру подключаются модули — исправьте, пожалуйста.
А по статье у меня следующий вопрос. Правильно ли я понял, что API остается неизменным, а мы просто парсим вызовы функций API?
Интересная статья, автору спасибо. Я как раз занимаюсь проектированием системы с множеством подключаемых возможностей посредством плагинов, поэтому, думаю, мне это пригодится.
А по статье у меня следующий вопрос. Правильно ли я понял, что API остается неизменным, а мы просто парсим вызовы функций API?
Интересная статья, автору спасибо. Я как раз занимаюсь проектированием системы с множеством подключаемых возможностей посредством плагинов, поэтому, думаю, мне это пригодится.
Исправил, спасибо огромное.
" Я как раз занимаюсь проектированием системы с множеством подключаемых возможностей посредством плагинов, поэтому, думаю, мне это пригодится. "
А вы не хотите сначала посмотреть на чуть более 9000 существующих модульных систем?
А вы не хотите сначала посмотреть на чуть более 9000 существующих модульных систем?
Человеку работать надо, а не выковыривать из тонн грязи крупицы золота.
Вот именно для этого и надо быть в курсе технологий — чтобы работать, а не тратить время на переписывание существующего.
Знание технологий не всегда приводит к успешному их применению. А иногда даже и мешает в нахождении более изящного решения.
Но в целом да, нужно быть в курсе технологий.
Но в целом да, нужно быть в курсе технологий.
«А иногда даже и мешает в нахождении более изящного решения.»
Интересно, каким образом.
Интересно, каким образом.
Чрезмерное усложнение. Иногда достаточно написать всего лишь одну функцию, вместо того, чтобы подключать фреймворки, делать кучу надстроек и программировать мегасистему. Выхлоп будет один и тот же, зато трудозатраты будут в разы отличаться.
Вы зачем-то путаете знание с обязательностью применения.
Тот факт, что я знаю о наличии какой-то технологии не означает, что я буду ей пользоваться. Но при проектировании системы, которая требует уже многократно реализованной где-то кем-то функциональности, я сначала подумаю, нельзя ли взять готовое, а только потом буду думать, как написать свое.
Тот факт, что я знаю о наличии какой-то технологии не означает, что я буду ей пользоваться. Но при проектировании системы, которая требует уже многократно реализованной где-то кем-то функциональности, я сначала подумаю, нельзя ли взять готовое, а только потом буду думать, как написать свое.
Во многих знаниях много печали. (с) Мудрые прошлого
Готовое никогда не будет на 100% решать поставленную задачу. А даже если и будет решать, то непродолжительное время. Через время вы столкнетесь с тем, что некоторые ограничения будет вносить именно готовая система. Ими или можно будет пренебречь, или они станут негативно влиять на разработку в целом.
Готовое никогда не будет на 100% решать поставленную задачу. А даже если и будет решать, то непродолжительное время. Через время вы столкнетесь с тем, что некоторые ограничения будет вносить именно готовая система. Ими или можно будет пренебречь, или они станут негативно влиять на разработку в целом.
«Готовое никогда не будет на 100% решать поставленную задачу.»
Тем не менее, дописать 10% может быть дешевле, чем писать 100%.
(кстати, это неправда, потому что некоторые готовые решения регулярно решают поставленную задачу на 100%. Например, коробочные СУБД. Или веб-сервера. Или вы под каждый проект пишете свою ОС, СУБД, фреймворк, шину сообщений и сервисный протокол, а для веб-проектов — еще и веб-сервер? Или все-таки готовые берете?)
«Через время вы столкнетесь с тем, что некоторые ограничения будет вносить именно готовая система. „
Вы не поверите, но разработанная вами система тоже вносит ограничения — потому что у вас ограниченное время для разработки. Так что это moot point.
Тем не менее, дописать 10% может быть дешевле, чем писать 100%.
(кстати, это неправда, потому что некоторые готовые решения регулярно решают поставленную задачу на 100%. Например, коробочные СУБД. Или веб-сервера. Или вы под каждый проект пишете свою ОС, СУБД, фреймворк, шину сообщений и сервисный протокол, а для веб-проектов — еще и веб-сервер? Или все-таки готовые берете?)
«Через время вы столкнетесь с тем, что некоторые ограничения будет вносить именно готовая система. „
Вы не поверите, но разработанная вами система тоже вносит ограничения — потому что у вас ограниченное время для разработки. Так что это moot point.
Тем не менее, дописать 10% может быть дешевле, чем писать 100%.
Согласен.
Например, коробочные СУБД.
Коробочные СУБД решают не все задачи. В них регулярно появляются новые фичи. Например, тот же Oracle научился сжимать данные по столбцам только в 11r2, а до этого эта задача не решалась в этом продукте.
Мы залезли в коробочные продукты зря, потому что они не относились к теме разговора.
А чем коробочная система расширений отличается от коробочной СУБД в части вероятности покрытия всего нужного функционала? Да ничем.
И вы путаете «новые фичи» с «решаемыми задачами».
Поэтому точно так же, как мы выбираем СУБД, которая нам подходит или нет, вы выбираем и другие подсистемы, которые решают наши задачи или нет.
И вы путаете «новые фичи» с «решаемыми задачами».
Поэтому точно так же, как мы выбираем СУБД, которая нам подходит или нет, вы выбираем и другие подсистемы, которые решают наши задачи или нет.
Тем, с какой стороны вы находитесь, разработчика коробочной СУБД, или ее пользователем.
Новые фичи не решают никакие задачи? Очень интересно.
Если довести абстракции до абсурда, то программист ничем не отличается от пользователя.
Новые фичи не решают никакие задачи? Очень интересно.
Если довести абстракции до абсурда, то программист ничем не отличается от пользователя.
«Тем, с какой стороны вы находитесь, разработчика коробочной СУБД, или ее пользователем.»
Не понимаю вас.
Вот я — разработчик. Мне для решения конкретной задачи нужно (а) СУБД (б) система подключаемых модулей.
Сначала я решаю (а). Я могу выбрать существующую СУБД, могу написать сам (да, я _могу_ написать СУБД). Я выбираю более эффективное решение с точки зрения затрат на получение мной нужного мне функционала.
Потом я решаю (б). Я могу выбрать существующую систему модулей, могу написать сам. И я снова выбираю с точки зрения максимальной эффективности.
Только после этого я могу начать делать то, за что я, собственно, получаю деньги — решать задачу бизнеса.
И чтобы эффективно выбрать что (а), что (б), мне нужно ориентироваться в технологиях. Иначе я не смогу объяснить заказчику, что в случае (а) не надо использовать Access, как он настаивает, а в случае (б) мне хватит, скажем, MEF из коробки, и я сэкономлю еще недели три труда (а в случае (ц) я могу взять log4net, а не изобретать собственный логгер).
«Новые фичи не решают никакие задачи?»
Решают. Но совершенно не обязательно, что конкретную бизнес-задачу нельщя решить без них.
Не понимаю вас.
Вот я — разработчик. Мне для решения конкретной задачи нужно (а) СУБД (б) система подключаемых модулей.
Сначала я решаю (а). Я могу выбрать существующую СУБД, могу написать сам (да, я _могу_ написать СУБД). Я выбираю более эффективное решение с точки зрения затрат на получение мной нужного мне функционала.
Потом я решаю (б). Я могу выбрать существующую систему модулей, могу написать сам. И я снова выбираю с точки зрения максимальной эффективности.
Только после этого я могу начать делать то, за что я, собственно, получаю деньги — решать задачу бизнеса.
И чтобы эффективно выбрать что (а), что (б), мне нужно ориентироваться в технологиях. Иначе я не смогу объяснить заказчику, что в случае (а) не надо использовать Access, как он настаивает, а в случае (б) мне хватит, скажем, MEF из коробки, и я сэкономлю еще недели три труда (а в случае (ц) я могу взять log4net, а не изобретать собственный логгер).
«Новые фичи не решают никакие задачи?»
Решают. Но совершенно не обязательно, что конкретную бизнес-задачу нельщя решить без них.
Логика понятна. Вы максимизируете прибыль в краткосрочном периоде, возможно, не беря в рассчет проблемы долгосрочного периода. А я стараюсь минимизировать проблемы в будущем, возможно, немного увеличивая трудозатраты в настоящем. Перед выбором технологий, фреймворков и прочего я для начала постараюсь определить проблемы, которые меня ждут через год. И выбор сделаю только с учетом достаточной масштабируемости нужных технологий и решений.
И в этом наше отличие. Именно поэтому у нас нет консенсуса.
И в этом наше отличие. Именно поэтому у нас нет консенсуса.
«Логика понятна. Вы максимизируете прибыль в краткосрочном периоде, возможно, не беря в рассчет проблемы долгосрочного периода.»
Кто вам это сказал? «Нужный мне функционал» покрывает вопросы как краткосрочного, так и долгосрочного периода.
«А я стараюсь минимизировать проблемы в будущем, возможно, немного увеличивая трудозатраты в настоящем.»
… или, как это часто бывает, минимизируете проблему, которая никогда не случится, за счет лишнего человекомесяца работы (естественно, за счет клиента).
«И выбор сделаю только с учетом достаточной масштабируемости нужных технологий и решений. „
Я тоже. В чем отличие?
Вы мне так и необъяснили, почему принципы выбора одного компонента системы (СУБД) как-то отличается от принципов выбора другого компонента (системы обеспечения модульности). В обоих случаях мы собираем требования, оцениваем затраты, находим эффективное решение с учетом всех требований.
(я, как бы, оставляю за скобками тот факт, что далеко не каждую систему надо планировать на год работы)
Кто вам это сказал? «Нужный мне функционал» покрывает вопросы как краткосрочного, так и долгосрочного периода.
«А я стараюсь минимизировать проблемы в будущем, возможно, немного увеличивая трудозатраты в настоящем.»
… или, как это часто бывает, минимизируете проблему, которая никогда не случится, за счет лишнего человекомесяца работы (естественно, за счет клиента).
«И выбор сделаю только с учетом достаточной масштабируемости нужных технологий и решений. „
Я тоже. В чем отличие?
Вы мне так и необъяснили, почему принципы выбора одного компонента системы (СУБД) как-то отличается от принципов выбора другого компонента (системы обеспечения модульности). В обоих случаях мы собираем требования, оцениваем затраты, находим эффективное решение с учетом всех требований.
(я, как бы, оставляю за скобками тот факт, что далеко не каждую систему надо планировать на год работы)
Ну, в целом есть такое понятие, как «взгляд замылился»…
Есть. Но для того, чтобы он не замыливался, надо много смотреть на _разное_, а не все время на одно и то же (в том числе — на свой код).
Так что ровно наоборот, знание как можно большего количества способов решить поставленную задачу уменьшает вероятность замыливания, а не увеличивает.
Так что ровно наоборот, знание как можно большего количества способов решить поставленную задачу уменьшает вероятность замыливания, а не увеличивает.
Знания на замыливание не влияют. Потому что замыливание может быть от усталости, и в таком состоянии мозг может принять совершенно неадекватное решение. И чем больше путей решения проблемы, тем больше шанс на ошибку.
«Потому что замыливание может быть от усталости, и в таком состоянии мозг может принять совершенно неадекватное решение»
В таком состоянии просто не надо работать.
«И чем больше путей решения проблемы, тем больше шанс на ошибку. „
А чем их меньше — тем больше шанс, что один из них ошибочный. Баш на баш.
В таком состоянии просто не надо работать.
«И чем больше путей решения проблемы, тем больше шанс на ошибку. „
А чем их меньше — тем больше шанс, что один из них ошибочный. Баш на баш.
Я скорее про то, что кроме уже разного готового иногда появляется что-то радикально новое, и далеко не всегда это новое сделано потому, что анализ старого показал недостатки и новое их обошло. Иногда бывает, что новое — это просто свежий взгляд, не погрязший в деталях и особенностях старого. Типа, не знал что так нельзя, так не делают — и сделал, и получилось хорошо. Бывает же?
правда, редко…
правда, редко…
Я бы сказал, исключительно редко.
А если следовать вашей логике, то и книг читать не надо (в них же тоже «детали и особенности»), и чужой код анализировать не надо, и так далее.
Нет, так тоже можно. Просто медленно очень.
Опыт показывает, что анализировать чужое намного эффективнее; особенно если подходить к любому чужому с недоверием и пытливым скальпелем.
А если следовать вашей логике, то и книг читать не надо (в них же тоже «детали и особенности»), и чужой код анализировать не надо, и так далее.
Нет, так тоже можно. Просто медленно очень.
Опыт показывает, что анализировать чужое намного эффективнее; особенно если подходить к любому чужому с недоверием и пытливым скальпелем.
а вот это — безусловно :)
но речь-то и шла про «иногда» :)
но речь-то и шла про «иногда» :)
Опыт показывает, что вероятность такого «иногда», когда знание мешает (именно знание, а не его нехватка) — черезвычайно мала.
Я вот такого не видел (а обратного видел вагон, когда люди пишут свои реализации чего угодно, начиная от логирования и заканчивая lazy(of T))
Я вот такого не видел (а обратного видел вагон, когда люди пишут свои реализации чего угодно, начиная от логирования и заканчивая lazy(of T))
Автор конечно молодец, что изложил своё понимание вопросы, но для этого скорее место в личном блоге, а «советы начинающим» лучше давать другого рода:
— почитать что такое Event Bus и Publish/Subscribe
— посмотреть, что понимается под middleware в популярных веб-фреймворках, какая роль ему отводится и особенности реализации
— почитать что такое Event Bus и Publish/Subscribe
— посмотреть, что понимается под middleware в популярных веб-фреймворках, какая роль ему отводится и особенности реализации
Довольно сумбурная статья, с весьма странными мыслями. Я так понял, изложен скорее какой-то веб-ориентированный паттерн, если изложенное так можно назвать. Годится разве что для описания конвейера трансформации данных. Надо было так статью и назвать.
Большая часть современных реализации менеджеров расширений, или плагинов, основывается на паттерне Dependency Injection.
Большая часть современных реализации менеджеров расширений, или плагинов, основывается на паттерне Dependency Injection.
Как вариант, автор может ознакомиться с современными решениями в коде интернет-магазина Magento, где как раз применён шаблон Observer и конфиругируемая фабрика для моделей. Что позволяет заменять своими классами любой из существующих в системе.
Ну да, в статье конечно описано то, что в последствии вылилось в аспектно-ориентированное программирование, хотя в последнем помимо точек вызова «до» и «после» есть еще возможность определить «вместо», что позволяет полностью заменить код вызываемого метода. В частности в различных событийных моделях фреймворков, на языках которые не поддерживают АОП из коробки, часто этой функциональности недостает.
«Ядро системы, которая имеет модульную структуру обычно выглядит примерно так»
Вас обманули. Так выглядят _некоторые_ модульные приложения. В частности, внутри бизнес-слоя при использовании совершенно модульных систем расчета, никаких post/get все равно нет. И темплейтинга нет.
Может, не надо распространять какие-то идеи, которые у вас возникли в web, на все модульные системы вообще?
Вас обманули. Так выглядят _некоторые_ модульные приложения. В частности, внутри бизнес-слоя при использовании совершенно модульных систем расчета, никаких post/get все равно нет. И темплейтинга нет.
Может, не надо распространять какие-то идеи, которые у вас возникли в web, на все модульные системы вообще?
Слово «примерно» прочитали?
И слово «обычно» — тоже.
Так вот, «обычно» ядро системы, которая имеет модульную структуру выглядит «примерно» совсем не так.
Так вот, «обычно» ядро системы, которая имеет модульную структуру выглядит «примерно» совсем не так.
Мне стало интересно, нарисуете обобщенную схему?
Омг, она в любой книжке по архитектуре есть. Например:
(множество потребителей) — менеджер модулей — (множество модулей)
Каждый, кому нужен какой-то функционал, обращается в менеджер, получает в ответ точку входа для этого функционала (в зависимости от парадигмы — объект или функцию) и дальше с ним работает как ему заблагорассудится.
Всё.
(множество потребителей) — менеджер модулей — (множество модулей)
Каждый, кому нужен какой-то функционал, обращается в менеджер, получает в ответ точку входа для этого функционала (в зависимости от парадигмы — объект или функцию) и дальше с ним работает как ему заблагорассудится.
Всё.
Менеджер модулей и будет ядром этой системы, разве нет?
Нет. Я не знаю, что вы вкладываете в понятие «ядро». В моем случае это была бы некая сборка blah.ExtensibleSystem.Core, внутри которой жил бы менеджер, необходимый ему и клиентам набор сервисов, набор интерфейсов для реализации плагинов и так далее.
такая организация приводит к слишком запутанной архитектуре. типа есть нормальное стройное дерево и к нему сбоку налеплена куча хуков, хуков к хукам и тд…
лучше делать полную перегрузку функции. пользователь в настройках указывает, что по такому-то запросу нужно вызывать не функцию Юзеры и функцию ТипизированнаыеЮзеры, которая в процессе своей работы может вызывать функцию Юзеры.
лучше делать полную перегрузку функции. пользователь в настройках указывает, что по такому-то запросу нужно вызывать не функцию Юзеры и функцию ТипизированнаыеЮзеры, которая в процессе своей работы может вызывать функцию Юзеры.
Любое изменение в ядре системы может привести к нерабочему коду. Не забываем, что плагин должен работать как можно дольше без нарушения общего функционала. А возможно это только тогда, когда он общается на специализированном языке с другими модулями и ядром. Введение еще одного уровня абстракции помогает избавиться от проблем в будущем.
По моему вы изобретаете Kohana 3.
Я раньше тож мечтал о такой системе, планировал ее разработать на евентах/сообщениях (Qt меня поразил). Но потом наткнулся на Кохана. Доволен.
Я раньше тож мечтал о такой системе, планировал ее разработать на евентах/сообщениях (Qt меня поразил). Но потом наткнулся на Кохана. Доволен.
самая модульная система, это язык программирования, поддерживающий модульность :)
Приведенные onBefore/onAfter, кстати, давно составляют основу концепции АОП, или вместо них используются функции-обертки. Так что в верном направлении двигаетесь. Надо лишь развить идею немного больше, чтобы она стала считаться оригинальной.
Приведенные onBefore/onAfter, кстати, давно составляют основу концепции АОП, или вместо них используются функции-обертки. Так что в верном направлении двигаетесь. Надо лишь развить идею немного больше, чтобы она стала считаться оригинальной.
Оригинальности трудно добиться в наши дни. За пол сотни лет развития программирования выбрали почти все уникальные способы построения различных систем. Остается только собирать из различных методов самое лучшее для конкретной задачи.
«Оригинальности трудно добиться в наши дни. За пол сотни лет развития программирования выбрали почти все уникальные способы построения различных систем»
Это не так. Оригинальности не трудно добиться и способов построения систем больше, чем отрыто. Вы не забывайте о том, что система ориентированная под компьютер отличается от системы ориентированной под веб. А вебу только двадцать лет, и не все его возможности еще раскрыты.
Так же на развитие веб систем влияет тот факт, что пишут их «компьютероориентированные программисты». Они закладывают в код те решения, которые там попросту не нужны, на корню разрушая остальные подходы.
Кстати для построения веб систем, вы предложили практически идеальный вариант, вот только замыканий не предусмотрели (или просто не дорисовали).
Удачи в реализации, вы по правильному пути идете.
Это не так. Оригинальности не трудно добиться и способов построения систем больше, чем отрыто. Вы не забывайте о том, что система ориентированная под компьютер отличается от системы ориентированной под веб. А вебу только двадцать лет, и не все его возможности еще раскрыты.
Так же на развитие веб систем влияет тот факт, что пишут их «компьютероориентированные программисты». Они закладывают в код те решения, которые там попросту не нужны, на корню разрушая остальные подходы.
Кстати для построения веб систем, вы предложили практически идеальный вариант, вот только замыканий не предусмотрели (или просто не дорисовали).
Удачи в реализации, вы по правильному пути идете.
Так же на развитие веб систем влияет тот факт, что пишут их «компьютероориентированные программисты». Они закладывают в код те решения, которые там попросту не нужны, на корню разрушая остальные подходы.
Что верно, то верно. До сих пор не могу понять, зачем прикручивать к JS классическое ООП в виде классов, приватных методов и прочего.
Замыкания не люблю, так как ошибки, которые с ними связаны, очень трудно отлавливать. И, что-то у меня складывается впечатление, что вполне можно обойтись без них.
Что верно, то верно. До сих пор не могу понять, зачем прикручивать к JS классическое ООП в виде классов, приватных методов и прочего.
Замыкания не люблю, так как ошибки, которые с ними связаны, очень трудно отлавливать. И, что-то у меня складывается впечатление, что вполне можно обойтись без них.
Я имею ввиду замыкания на php. Это например такая ситуация:
Предположим перед вами форма добавления комментария на какой-то комментарий пользователя. Здесь, на хабре. Кнопка «написать» передает данные обработчику.
Обработчик выглядит примерно так:
public function func() {
db( blogmodel::addComment() );
}
Все.
Т.е. ядро должно уметь различать типы страниц и само включать действия по умолчанию в зависимости от типа, что в данном случае возврат на просмотр темы.
Если добавить комментарий на хабре, то окажешься в текущей теме, если же нажать кнопку «выход», то попадаешь на главную страницу. Это странно и неправильно. А если типизировать страницы, то придав обработчикам кнопок «выход» и «написать» один тип, можно довериться автоматическим действиям, которые в обоих случаях приведут именно на эту страницу. Это снимает много логики со всех модулей сразу. И типов в итоге получается четыре. У меня четыре просто, и мне их хватает чтобы ни один из методов любого плагина не содержал логики, а выполнял только то, ради чего собственно вызывался. Сперва это может показаться неудобным, но «позамыкать» между собой методы намного легче, чем строить сложные схемы связей страниц и всяческих перенаправлений. Автоматические же перенаправления должны содержать настройки для их частичной корректировки или полной отмены, чтобы если нужно сделать что-то вручную — то пожалуйста.
Предположим перед вами форма добавления комментария на какой-то комментарий пользователя. Здесь, на хабре. Кнопка «написать» передает данные обработчику.
Обработчик выглядит примерно так:
public function func() {
db( blogmodel::addComment() );
}
Все.
Т.е. ядро должно уметь различать типы страниц и само включать действия по умолчанию в зависимости от типа, что в данном случае возврат на просмотр темы.
Если добавить комментарий на хабре, то окажешься в текущей теме, если же нажать кнопку «выход», то попадаешь на главную страницу. Это странно и неправильно. А если типизировать страницы, то придав обработчикам кнопок «выход» и «написать» один тип, можно довериться автоматическим действиям, которые в обоих случаях приведут именно на эту страницу. Это снимает много логики со всех модулей сразу. И типов в итоге получается четыре. У меня четыре просто, и мне их хватает чтобы ни один из методов любого плагина не содержал логики, а выполнял только то, ради чего собственно вызывался. Сперва это может показаться неудобным, но «позамыкать» между собой методы намного легче, чем строить сложные схемы связей страниц и всяческих перенаправлений. Автоматические же перенаправления должны содержать настройки для их частичной корректировки или полной отмены, чтобы если нужно сделать что-то вручную — то пожалуйста.
мне кажется, что либо нужно четко ограничить рамки решаемых задач, представив систему в виде DSL, либо гибкая модульная система будет стремиться превратиться в еще один язык программирования. У вас нет ни слова о ограничениях, поэтому скорей всего ваш проект последует второму пути развития, часто дублируя существующий функционал над-стоящего языка (к примеру взять Smarty — результат достигается тот же, что можно достигнуть на чистом PHP, но через описание других концептов).
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Строим плагиноориентированную модульную систему