Дмитрий Байбухтин: а причем тут собственно контроллеры? Контроллеры пусть дублируются, они для того и нужны. Другое дело что там кода будет по 3 строчки на экшен + контроллеры всегда можно сгенерить (собственно я так и делаю). Представления - если юзать нормальный шаблонизатор (twig) - наследование полностью устраняет дублирование и при этом оставляет простор для внесения изменений.
Словом, я концентрируюсь на бизнес логике (у нас тут ее кот наплакал), а для устранения дублирования логики в UI есть отдельные методы (либо можно вообще забить).
Дмитрий Байбухтин: 1) базовая сущность CatalogItem, абстрактная. От нее наследую все остальные. Делаю базовые сервисы для управления всем этим делом. Результат - ноль дублирования. А если мне вдруг захочется сильно поменять логику я просто заведу для отдельного типа сущности свои сервисы и реализую цепочку ответственности или что-нибудь в этом духе.
Дмитрий Байбухтин: мне не нравится идея разделения приложения на модули без видимой на то причины. У вас появляются зависимости между модулями (все модули зависят от модуля Catalog), и при этом все модули находятся на одном уровне.
То есть мое ИМХО - вы можете вынести общие вещи в модуль Catalog, но он должен быть на уровень ниже всех остальных модулей что бы прослеживалась зависимость.
В целом поскольку вы не описали что да как вы делали в рамках этого "разделения" - все что приходит на ум так это то, что вы ограничились старым добрым наследованием (или кастыли аля трейты, миксины и т.д.)
Я говорю о том что 90% задач для которых применяли компас - миксины для префиксов. Еще 9% - спрайты. Для первого - autoprefixer лучшее решение на данный момент. Для второго - отдельные инструменты (профит в том что они не привязаны к конкретному препроцессору).
uaSaint: Я полностью согласен с мыслью что "главное задача а не технология", технология это лишь деталь. И я категорически против "адептов" чего-либо. Как говорится A foolish consistency is the hobgoblin of little minds и все такое.
смысл stylus чуть более "удобном" синтаксисе. И удобства эти весьма субъективны. Я тоже не совсем понимаю зачем нужен стайлус. Но народу нравится делать свой варианты синтаксиса под себя. И у этих людей есть свои предпочтения и с этим надо просто смириться.
Спам для могза это вообще концентрироваться на конкретики без оперирования абстракциями, принципами и идеями. Знание реализации без понимания идеи вообще ничего не стоит как по мне.
Уточню первый абзац - есть такая штука - привычка. Я вот года 4 назад освоил less и мои нужды он покрывает целиком и полностью. То есть заводя новый проект я сразу подключаю less и т.д. Но у меня нет никаких проблем с тем что бы использовать scss (скажем если проект начинал не я, или UI фреймворк написан на scss), или что-либо другое.
Для подавляющего большинства задач возможности всех популярных препроцессоров приблизительно одинаковы.
Хотите более прозаичную причину почему эти проекты все еще используют scss? Потому что на тот момент, когда начиналась разработка, ничего лучше небыло, а сейчас переводить стили на что-то другое не имеет практической пользы. Да и добавить постпроцессоры какие-то сверху проблемы не составляет.
Взять тот же compass - он не нужен сегодня. Совсем. Все эти "полезные" миксины слихвой заменяют инструменты на базе postcss (autoprefixer тот же) и прочие постпроцессоры, и при этом поддержка стилей упрощается в разы.
У меня складывается впечатление что вы вознесли scss на какой-то пьедестал, как будто бы это что-то важное, а как по мне - совсем не важно less, scss или stylus использует разработчик. Цель у этих инструментов одна, так же как и методы достижения этой цели.
blnk: главное почитайте на википедии (желательно на английской, там картинки лучше) про dependency inversion и вообще почитайте чего про SOLID. В целом без инверсии зависимостей ООП теряет добрую половину смысла.