Я продолжаю цикл статей, посвященных некоторым простым правилам разработки под Unix «по версии Эрика Реймонда», которые, по моему глубочайшему убеждению, могут быть распространены на любые другие операционные системы. Я уже рассказывал в первых трех частях о правилах модульности, ясности и композиции. Сегодня дело дошло до четвертого правила —
Правило разделения: отделяйте правила от механизма, а интерфейсы от движка («бизнес-логики» ) (Rule of Separation: Separate policy from mechanism; separate interfaces from engines)
Многиевеб-программисты , наверное, посчитают правило довольно банальным. Ведь этот принцип является основополагающим для миллионов фреймворков и систем управления содержанием сайтов, а они являются базой для почти любого современного веб-решения . Тем не менее, все чаще замечаешь, что соблюдают этот принцип чаще только при разработке продукта «с нуля», а потом всячески нарушают при его поддержке и развитии. Потому что «нужно было срочно». Во-вторых , в части всего остального ПО, кроме веб-сайтов , о нем вспоминают все реже. Ведь интерфейсами могут являться не только веб-интерфейсы .
В связи с этой темой следует вспомнить концепциюModel-View-Controller , или, сокращенно, MVC. В ней предполагается разделять данные (Model), представление (View) и бизнес-логику (Controller). Упрощенно говоря, вся логика, все интерфейсы и все данные должны быть друг от друга разделены по разным компонетам и связаны стандартными интерфейсами. Этот шаблон проектирования реализован для практически всех современных языков программирования. Из популярной «классики» можно вспомнить Apache Struts (JAVA), Symfony (PHP), ASP.NET MVC. Использование хорошо документированных, широко используемых фреймворков для этой цели значительно предпочтительнее, чем писать их с нуля самому, потому что никакой специфики для решаемой задачи в них закладывать не придёться, и, скорее всего, будет это все не более, чем изобретение велосипеда и перерасход времени и ресурсов.
Очень интересным примером разделения интерфейса и логики является реализация шахмат для Unix, распространяемых под лицензией GNU. Существует отдельный шахматный движок с текстовым интерфейсом. Внутри него интерфейс тоже разделен от «логики», но — важно — его намеренно не «утяжеляли». Доска же с фигурами — это отдельные приложения, как XChess, Pychess, Winboard.
Классическим примером использования этой концепции является реализация X Window System, оконной системы, не имеющей собственной графической среды. Отрисовкой «окошек» и «иконок» занимаются сторонние оконные менеджеры, которые, в свою очередь, лишены «математики» и не заботятся о поддержке устройствввода-вывода .
Часть этого принципа — разделение правил от механизмов. Он — про построение гибкой, настраиваемой логики, основанной на данных. Здесь, к сожалению или к счастью, нет универсального совета на то, где проводить грань между гибкостью и достаточностью. К примеру, можно заложиться на разное разрешение экрана при проектировании приложения под iPhone и это однозначно поможет, если встанет вопрос портирования на iPad. Это однозначно потребует дополнительных усилий и времени. Поэтому здесь должен обязательно участвовать менеджер по продукту или лицо, его заменяющее, а задача программиста — правильно и своевременно поднять эти вопросы в ясной и понятной форме.
Одной из сложных ситуаций при соблюдении этого принципа — использование Javascript вместе с серверной логикой. При создании систем, активно использующих AJAX, нужно тщательно за этим следить еще на этапе проектирования. Очень частой ошибкой является чрезмерное усложнениеJavascript-ами шаблонов сайтов, в результате чего они превращаются в сложноподдерживаемую систему. Поэтому каждый раз, когда планируется активное использование Javascript, принять в команде разработчиков согласованный подход, как в этом случае разделять бизнес-логику и интерфейсы.
Правило разделения: отделяйте правила от механизма, а интерфейсы от движка (
Многие
В связи с этой темой следует вспомнить концепцию
Очень интересным примером разделения интерфейса и логики является реализация шахмат для Unix, распространяемых под лицензией GNU. Существует отдельный шахматный движок с текстовым интерфейсом. Внутри него интерфейс тоже разделен от «логики», но — важно — его намеренно не «утяжеляли». Доска же с фигурами — это отдельные приложения, как XChess, Pychess, Winboard.
Классическим примером использования этой концепции является реализация X Window System, оконной системы, не имеющей собственной графической среды. Отрисовкой «окошек» и «иконок» занимаются сторонние оконные менеджеры, которые, в свою очередь, лишены «математики» и не заботятся о поддержке устройств
Часть этого принципа — разделение правил от механизмов. Он — про построение гибкой, настраиваемой логики, основанной на данных. Здесь, к сожалению или к счастью, нет универсального совета на то, где проводить грань между гибкостью и достаточностью. К примеру, можно заложиться на разное разрешение экрана при проектировании приложения под iPhone и это однозначно поможет, если встанет вопрос портирования на iPad. Это однозначно потребует дополнительных усилий и времени. Поэтому здесь должен обязательно участвовать менеджер по продукту или лицо, его заменяющее, а задача программиста — правильно и своевременно поднять эти вопросы в ясной и понятной форме.
Одной из сложных ситуаций при соблюдении этого принципа — использование Javascript вместе с серверной логикой. При создании систем, активно использующих AJAX, нужно тщательно за этим следить еще на этапе проектирования. Очень частой ошибкой является чрезмерное усложнение
| « Ранее: правило композиции | Продолжение: правило простоты » |
