Такой подход губителен в крупных проектах. Написание скинов превращается в кровавую оргию с копипастом. Да и в небольших проектах аккуратное точечное применение фрагментации позволяет упростить жизнь.
Вы про {php}? Там же его запретить можно, что и надо делать первым делом. А исполняемый код пусть в плагинах живет.
Другое дело, что интеграция с фреймворками идёт гладко ровно до тех пор, пока работа шаблона ограничивается выводом переменных. Как только идём дальше (например, хотим использовать хелпер url в ZF для генерации URL) — начинается адский оверхед, каждому хелперу нужен прокси-плагин.
Шаблнизаторы — не панацея. Я много лет работал со Smarty и другими шаблонизаторами, потом вернулся к нативной шаблонизации. Не хотелось бы начинать холивар ради холивара, есть преимущества у обоих подходов, в том числе и множество преимуществ у нативной шаблонизации. Единственный безусловный минус — verbosity, это действительно раздражает.
Забавно, у меня имел место обратный процесс :) Я много лет был апологетом Smarty, а сейчас предпочитаю обходиться без него, а в качестве плюшек — ZF-овские view helpers. Да, синтаксис не слишком удобный, но зато на порядок меньше оверхеда при большей гибкости. Шаблонизатор отлично изолирует логику представления, но я в какой-то момент поймал себя на том, что зачастую эта изоляция дороговато обходится. Например, внедрять все хелперы в Smarty в качестве плагинов — дикий головняк, практической пользы от которого очень мало, если не отдавать проект на растерзание заведомым говнокодерам.
Насчёт 1.4 — тут такая фишка: шаблон — это тоже программа. Даже голый HTML является программой отображения страницы в браузере. В шаблонах голый HTML разбавлен дополнительными инструкциями, формирующими — сюрприз! — логику представления. Естественно, эта логика решает задачи типа «вывести в таблице список значений», а не делает SQL-запросы к базе. PHP для этого вполне подходит, другое дело, что такой подход требует определённой дисциплины.
Для интеграции несовместимых интерфейсов существует паттерн "Адаптер". А объект-логгер должен быть контейнером для объектов-адаптеров с обобщенным интерфейсом. Даже в отсутствие конфликта интерфейсов нормальный проектировщик поступит именно так в целях масштабируемости. «Минимизация количества классов» — не та цель, за которую стоит воевать. Классов должно быть столько, сколько необходимо для реализации грамотной архитектуры.
Я считаю, что если возникает проблема «конфликтующих интерфейсов», то это явный результат грязных хаков и плохой архитектуры.
Задачи, где «старое доброе процедурное программирование» действительно (а не по причине плохого знания ООП разработчиком) эффективнее ООП, редки и нетривиальны, если речь, конечно, не о helloworld'ах и не о простых скриптах на коленке, в которых время решения непосредственно кореллирует с количеством набранных символов.
Единственная здравая мысль — про шаблонизацию родными средствами PHP, остальное представляет собой смесь словоблудия и «вредных советов».
Во-первых, не только («адъютант», «трехъярусный»). Во-вторых, допускается использование при транскрипции иностранных имён и названий (недавнего японского премьера звали Коидзуми Дзюнъитиро, например).
У меня не получается представить ситуацию, в которой мне пришлось бы реализовывать в одном классе два сторонних интерфейса. Можете привести более-менее реалистичный пример?
Мне кажется, проблема надуманная. Если два интерфейса обладают одним и тем же методом, который служит для одного и того же, то этот метод скорее всего должен быть унаследован от некоего абстрактного интерфейса по логике вещей. В противном случае такого просто быть не должно, если серьезно подходить к именованию методов, т.е. чтобы название метода однозначно говорило, что он делает.
Надо отметить, что в 5.4 у traits будет возможность разрешать конфликты и переименовывать методы; но надо понимать, что trait — это не интерфейс, задачи у этих механизмов разные.
Красивый — это тот, который не обладает дурным запахом по Беку/Фаулеру, если мы говорим о рефакторинге. За официальным списком «вонючек» — в литературу, плиз, и лучше бы туда заглядывать до того, как встревать в обсуждение теории, с которой вы незнакомы.
Топик-то вроде про рефакторинг, а не про coding standards :))) Какие рефакторинги по Фаулеру унифицируют отступы, ну-ка расскажите мне.
Что у автора статьи каша в голове, что у половины комментаторов, ужас просто. Теперь вот выясняем, «зачем чинить правильную архитектуру». Хоть какую-нибудь книжку по обсуждаемой теме прочитайте, а то обзовут «рефакторингом» любую медитацию над кодом, а потом один вопит, что ему «навязывают понимание», второй требует определение в студию и спрашивает, «о каком рефакторинге речь». Вторая половина комментаторов тихо изображает facepalm, больше ничего не остаётся. Теории сто лет в обед, вся терминология давно устоялась, написаны толстые книжки — но нет, это всё не для нас, у нас свое понимание, ггг.
Хорошо хоть в матанализе выше порог входа, чем в программировании, а то там, наверное, такой же бардак царил бы.
А бывает код без отступов и без названий переменных? Мы сейчас ведь не об институтских курсачах?
Красота кода как цель рефакторинга определяется его понятностью. Это достигается как правильным форматированием, так и правильной архитектурой. И вы заявляете, что при работе над кодом абсолютно неважно, понятен он или нет? Снимаю шляпу.
Другое дело, что интеграция с фреймворками идёт гладко ровно до тех пор, пока работа шаблона ограничивается выводом переменных. Как только идём дальше (например, хотим использовать хелпер url в ZF для генерации URL) — начинается адский оверхед, каждому хелперу нужен прокси-плагин.
Насчёт 1.4 — тут такая фишка: шаблон — это тоже программа. Даже голый HTML является программой отображения страницы в браузере. В шаблонах голый HTML разбавлен дополнительными инструкциями, формирующими — сюрприз! — логику представления. Естественно, эта логика решает задачи типа «вывести в таблице список значений», а не делает SQL-запросы к базе. PHP для этого вполне подходит, другое дело, что такой подход требует определённой дисциплины.
Я считаю, что если возникает проблема «конфликтующих интерфейсов», то это явный результат грязных хаков и плохой архитектуры.
Единственная здравая мысль — про шаблонизацию родными средствами PHP, остальное представляет собой смесь словоблудия и «вредных советов».
Надо отметить, что в 5.4 у traits будет возможность разрешать конфликты и переименовывать методы; но надо понимать, что trait — это не интерфейс, задачи у этих механизмов разные.
Что у автора статьи каша в голове, что у половины комментаторов, ужас просто. Теперь вот выясняем, «зачем чинить правильную архитектуру». Хоть какую-нибудь книжку по обсуждаемой теме прочитайте, а то обзовут «рефакторингом» любую медитацию над кодом, а потом один вопит, что ему «навязывают понимание», второй требует определение в студию и спрашивает, «о каком рефакторинге речь». Вторая половина комментаторов тихо изображает facepalm, больше ничего не остаётся. Теории сто лет в обед, вся терминология давно устоялась, написаны толстые книжки — но нет, это всё не для нас, у нас свое понимание, ггг.
Хорошо хоть в матанализе выше порог входа, чем в программировании, а то там, наверное, такой же бардак царил бы.
Красота кода как цель рефакторинга определяется его понятностью. Это достигается как правильным форматированием, так и правильной архитектурой. И вы заявляете, что при работе над кодом абсолютно неважно, понятен он или нет? Снимаю шляпу.