Вот это можно глянуть: bizzapps.ru/p/freescout
1. бесплатная и открытый код
2. модульная, написана на пхп и ларавел — можно взять готовые модули, можно дописать все что душе угодно
3. ставится легко и просто
4. удобная в использовании, есть мобильный клиент, может работать как PWA на любой мобиле
Есть еще разные мелкие недочеты. Но тк она открытая и модульная — то дописать можно что угодно.
Не очень понятно зачем для EAV делать 2 таблицы помимо основной таблицы сущностей?
Я работал так:
1. таблица сущностей: entity
2. таблица атрибутов: attributes
у таблицы атрибутов поля:
— id
— entity_id
— key
— value
Все. Это работает. Храним любые атрибуты и их значения.
По любой сущности можно получить все атрибуты и значения 1 запросом с 1 join. Атрибутов моджет быть хоть 1000 штук. Доходило до 20 000 штук.
Хранить такое в JSONB — мб плачевно.
С другой сторону конечно же EAV это не серебрянная пуля. У нее есть как плюсы так и минусы.
Например чаще всего индекс есть только у ключей, а value хранятся без индекса. У этого тоже есть плюсы, но и весомый минус — при больших данных поиск значений в value становится долгим.
Есть много решений. Что то можно выдернуть в отдельные таблицы. Иногда подключается внешний индекс типа Эластика или Алголии. Например для создания поисковых индексов.
JSONB крутая штука. Где то она будет показывать себя лучше. Но не везде )
Далее по книге Фредерик Б. пишет о том что под термином ООП скрывается 2 по сути не похожих друг на друга подхода. Один на классах, а второй на компонентах.
Если открыть википедию, то увидите что там уже 3 типа ООП методологии: классы, компоненты и прототипы.
Беда в том что разум 99% программистов ограничен только классами. Они в упор не хотят замечать существование альтернативных ООП концепций.
При этом побеждают на рынке те платформы, которые научились готовить ООП не только на классах, но и грамотно применять компонентные ООП подходы: Angular vs React, Drupal vs WordPress.
С ООП на классах можно делать нормально, но не все.
Если точнее то в крупных/сложных системах надо уметь делать ООП не только на классах.
Пока вы делаете что то мелкое и простое — можно жить с ООП только на классах.
Но как только система становится достаточно большой, в команде появляется 5-10-50 разработчиков — упор на классы влечет проблемы. Часть описана в этой статье, часть гуглится по фразе «проблема хрупкости базового класса».
Это не значит что надо отказаться от классов. Это значит что надо учить другие ООП методологии: компоненты и прототипы. Там же событийная архитектура. Это существенно прокачивает гибкость. И позволяет упрощать разработку больших систем.
Все просто. Бывает много типов ООП. Классы, компоненты, прототипы… Но 99% программистов осилили только классы. А далее включается психическая болячка под названием «комплекс утенка». Первое выученное становится единственно верным и родным как мама. Все что не похоже на классы то не ООП :)
Об этом говорит Ален Кей — автор идеи ООП. Об этом писал в 80е годы Фредерик Брукс в своей книге МЧМ. Про это написано в Википедии. Есть куча примеров в которых ООП не на классах (а на прототипах и/или компонентах) побеждает на рынке. Но ребята с комплексом утенка упорно не хотят это замечать )
Очередной холивар на тему ООП. При этом люди не удосужились понять что это такое. Как автор статьи, так и те кто в комментах пишет.
Надо почитать мысли Алана Кея, чтобы понять что ООП это не про классы.
Еще есть книга МЧМ Фредерика Брукса написанная аж в 80е годы. Там тоже расскрывается тема разных ООП подходов. Классы — это лишь один из подходов.
Как только разобраться в том что есть ООП — все эти холивары начинают походить на цирк и спор слепых людей о цвете помидора.
Согласен. Но у каждого человека своя матрица в голове.
И какие бы там матрицы не придумали — плоский список в любом случае создаст порядок и приоретизацию.
А какими там матрицами задачи будут подниматься вверх, а какими вниз — дело вкуса. В команде из 5 человек будет 5 матриц, часть из которых будет очень не понятной, но в ходе обсуждения люди быстро договорятся что надо поднять. И так наступит порядок.
Я не против этой матрицы. Если надо можно обосновать и через нее. Но из своей практики могу сказать что главное это плоский список. А до матрицы Важности и Срочности обычно дело не доходит. Просто люди договариваются и спокойно работают над тем что приоритетно. А все что второстепенно падает вниз… иногда закрывается так и не дойдя не до каких матриц. И это хорошо.
Некогда читал заметки автора системы Планфикс, где они придумывали как правильно сделать приоритеты задач в системе.
На то время я тоже искал ответ на вопрос как эффективно ставить приоритеты?
Там ребята пришли к выводу что единственно верная система — это плоский список задач.
Вообще слово Приоритет если изучить его этимологию означает «Первый». Сколько задач одновременно могут быть первыми? :)
И вот когда заставляешь всех работать по такому списку, где физически не возможно 2 задачи поставить на 1е место ) Вот тогда люди реально начинают думать. А разработчики реально понимают что надо делать.
В идеале. В реальности конечно и эту систему можно сломать и изуродовать. Но ничего лучше пока не нашел.
Еще это называется Backlog в мире Agile. Который вам как то не по душе. Судя по некоторым мыслям проскакивающим в тексте.
Например. Иногда подключаюсь к проектам/командам, в которых творится хаос, не понимание между руководством и разработчиками, полная чехорда. Одни орут что сроки не исполняются, другие что задачи не внятные. И просто привожу все задачи к плоскому списку ) Не сразу, но спустя 1-2 месяца ситуация самоорганизуется )
Плоский список задач — это проще чем матрица ) Играть с матрицей кончил лет 10 назад.
Я боюсь представить что будет когда вы узнаете что такое OKR )
Прочитал. Спасибо :) Прям собран весь русский опыт внедрения SCRUM. И вся боль которая из этого опыта выливается.
Однако стоит учитывать ряд важных моментов:
1. Если есть проект и дидлайн, по которому отчитывают за SCRUM — то это вывих головного мозга. Надо лечить мозг того кто эти вещи сочетает, а не обвинять SCRUM.
2. Проекты и дидлайны бывают. Но там применяются проектные методы. Классические. Без SCRUM. SCRUM — это иная история. При определенном умении их можно сочетать. Но получается это далеко не у каждого.
3. Про консультантов — в точку. В РФ именно такие. Бегают кричат про SCRUM. А по факту просто деньги сосут и портят процессы. Но опять же это не проблема SCRUM. Это специфика русских SCRUM-консультантов.
4. Видел десятки команд в РФ которые гордо заявляли что у них уже SCRUM или что они его внедряют. Но что то похожее на настоящий SCRUM видел только у 2х команд. Реально по опыту в РФ судить о этой идеологии не стоит. Тут слишком мало тех у кого хватает ума понять что это такое и как его готовить.
5. В качестве альтернативной точки зрения стоит почитать книгу про Automattic «Год без костюма». Там про то как выглядит реальный Agile. От которого один шаг до SCRUM. Но те кто по настоящему сумел освоить силу простоты Agile — редко переходят на SCRUM.
Сам по себе SCRUM не даст крутые результаты. Скорее наоборот — станет только хуже.
Выгоду дает умение играть SCRUM. Чувствуете разницу?
Плохие результаты не потому что SCRUM плохой, а птм что люди плохо умеют играть SCRUM.
Это как обвинять гитару в том что у тебя получается плохая музыка. Но если тот кто играет — «рукожоп» — то даже лучшая гитара в мире будет давать ужасную музыку в его руках.
Коммент чисто для обозначения альтернативной точки зрения. Ну и для ссылки на книгу где описана не вымышленная, а реальная компания, с реальным опытом, которая добилась тех самых 4х-10х результатов относительно конкурентов описанных в книге про SCRUM.
Да, мысли верные. Понятийный аппарат хромает на всю голову :)
Сервис — такого слова в русском языке нет. Он переводится как Услуга.
Товар — это материальный продукт. То что можно взять в руки или пощупать. Разработка софта не может быть Товаром. Это всегда Услуга или Сервис.
То о чем вы говорите это Продукт или Проект. Продукт без срока — нужно думать о завтра и играть в долгую. Проект всегда конечен — можно жить сегодняшним днем, сдать его и дальше хоть трава не рости.
У нас у людей мозги в смятку. Услуги называют словом Сервис. Продукты словом Проект. А вы тут отличились и Услугу умудрились назвать Товаром. При этом по понятиям Товар в вашем понятии и Проект в народном понятии — противоречящие вещи/идеи.
Также это классическая делема истории про Яблоко от Владимира Тарасова. Потратиться на чистку и скушать быстро? Или начать кушать сейчас, но медленно тк там могут быть риски (грязные/червивые участки)? Даже в продуктовой разработке ответ не всегда очевиден. Иногда надо войти в тех долг и сделать криво, но быстро. А иногда надо замедлиться, но сделать сразу хорошо и с заделом на будущее. Что правильно и кто решает? Решает владелец продукта и он же отвечает за результат принятых решений.
Готов согласиться. Проблема только в том что есть логика программы и здравый смысл?
Матеры разработчики это осознают благодаря эмпирическим знаниям.
Задача — найти некое описание, которое будет формализовано и понятно джунам/мидлам. Джуны как правило вообще не одупляют что почем. А мидлы часто буквально воспринимают рекомендации и начинают пилить 100500 функций на 3-4 строки и 55 классов с 1-2 методами — птм что так написано в библии Чистого кода.
Причем в РФ из за дефицита разработчиков часто мидлов и ставят сеньорами или тим лидами (из принципа — а лучше пока никого не нашли). Так и образуется рассадник шизокода, который спускается сверху теми кто до старшинства еще умом не дорос.
Везунчик. Я тоже до последнего времени страдал только от Говнокода и Хардкода. Но оно было не так затратно. А вот Шизокод долго не мог осознать. Ну а его проявление в куче классов пока что встретил лишь 1 раз. Но подумалось что причина та же самая… отсутствие желания у разработчика следовать стандартам и лучшим практикам, использованию существующих методов и функций, а вместо этого написать 10 своих классов и потом раскидать их по всей системе через 3-4 наследования в каждом. Насчитал более 300 строк кода и более 10 классов, которые можно было уместить в 3-4 строки кода и уже существующие методы внутри платформы. Решил что природа этого заболевания та же самая что и желание разработчиков писать свои CMS/фреймворки )
Но это не точно )
на мой взгляд — надо применять паттерн Best of breed.
для сайта я возьму WordPress. для магазина WooCommerce.
если мне надо написать какое то хитрое веб приложение — Laravel.
для API предпочту NodeJS или Go.
если что то системное то мб Python/Go.
тут мб куча факторов:
— мода на тот или иной фреймворк/язык
— компетенции команды
— адекватность инструмента задаче
Всегда приходится делать выбор исходя из множества факторов. Идеальных инструментов под все задачи пока не придумали.
это смотря с какой стороны посмотреть :)
думаю ничто не зло в абсолютном выражении. везде есть частичка добра )
но я встречался с проектами на своих CMS/фреймворках, где 80% времени приходилось тратить на угадывание логики ее авторов. а это не просто и очень дорого )
потому для себя решил что лучше буду работать с каким то платформами из топ-3, а лучше топ-1 )
Если родительский класс переиспользуется — ничего плохого.
Ключевое слово — излишество. Когда можно обойтись без наследования — надо обойтись без него. Птм что лишний слой абстракции — это нарушение бритвы Оккама. И там много негативных последствий.
Речь не о том что наследование это абсолютное зло и плохо. А о ситуации когда оно делается без причины. Если не встречались с таким — бамбалейо. Поздравлямба и все такое. Все впереди )
Безусловно в большом проекте бывают ситуации когда кто-то простое не понимает зачем тут эта швабра подпирает дверь. Он ее убирает и происходит извержение вулкана )
Тема весьма спорная и в отрыве от конкретной ситуации сложна для обсуждения.
Конечно говнокодинг и хардкодинг встречаются чаще. Их и лечить проще.
Однако шизокодинг существенно дороже. Мы тут зацепились за идею с излишним наследованием. Что действительно редкое проявление шизокодинга. Но все же бывает.
Гораздо чаще встречается ситуация когда разработчики начинают свои костыли пилить (при условии наличия существующих методов), фреймворки, CMS или делать Интернет магазин/Блог на чистом Laravel. На мой взгляд причина одна и таже — разработчик не удосужился изучить существующие решения. И начал пилить велосипед. И это дорого. Очень дорого обходится бизнесу.
> Не очень понятно, что тут значит stateless
Это значит что класс не хранит состояние (переменные, константы и т д) и применяется только для инкапсуляции методов. Такой стиль часто встречается в WordPress (например некоторые классы в WooCommerce). Обе платформы №1 в своих сегментах. Ну и в некоторых закрытых Enterprise проектах такое встречал.
Сам часто пишу именно в этом стиле. Птм что он с одной стороны дает возможность быстро писать код на старте не думая о будущем, а с другой стороны потом быстро переходить в любой из стилей по необходимости: Синглтон, классы с наследование, ФП и т. д.
Это из моего опыта: Enterprise, eCommerce, веб-приложения… на разных платформах: flat php, Laravel/Symfony, WP/WooCommerce…
Идеальный мир условно достижим на MVC фреймворках типа Laravel/Symfony. Но это в теории. На практике серьезных проектов на их базе не встречал. Только API и простые микросервисы/веб приложения.
Действительно без конкретной ситуации сложно объяснить все эти абстрактные ядра :)
Думаю тут важный момент — бритва Оккама. Речь именно про нее :)
Это лучший из известных мне способов объяснить абстрактно про излишнюю абстрактность :) Но боюсь он не идеален и не всем понятен с наскоку.
Если взять бритву то далее есть две ситуации:
— пишем все в 1 классе до тех пор пока нет веских причин разбивать его на подклассы
— появилась веская причина? разбиваем класс на разные классы
Какие могут быть причины? Их много:
— основной класс стал слишком большим и не понятным
— нужно разбить код на шаблоны и логику
— нужно часть функционала переиспользовать в других классах
и т д
Но бывает что причина только одна… разработчику хочется уталить свою жажду красоты и показать что он знает что такое наследование… и вот мы получаем кучу бесполезных классов, наследований и лишних слоев абстракции…
1. бесплатная и открытый код
2. модульная, написана на пхп и ларавел — можно взять готовые модули, можно дописать все что душе угодно
3. ставится легко и просто
4. удобная в использовании, есть мобильный клиент, может работать как PWA на любой мобиле
Есть еще разные мелкие недочеты. Но тк она открытая и модульная — то дописать можно что угодно.
Я работал так:
1. таблица сущностей: entity
2. таблица атрибутов: attributes
у таблицы атрибутов поля:
— id
— entity_id
— key
— value
Все. Это работает. Храним любые атрибуты и их значения.
По любой сущности можно получить все атрибуты и значения 1 запросом с 1 join. Атрибутов моджет быть хоть 1000 штук. Доходило до 20 000 штук.
Хранить такое в JSONB — мб плачевно.
С другой сторону конечно же EAV это не серебрянная пуля. У нее есть как плюсы так и минусы.
Например чаще всего индекс есть только у ключей, а value хранятся без индекса. У этого тоже есть плюсы, но и весомый минус — при больших данных поиск значений в value становится долгим.
Есть много решений. Что то можно выдернуть в отдельные таблицы. Иногда подключается внешний индекс типа Эластика или Алголии. Например для создания поисковых индексов.
JSONB крутая штука. Где то она будет показывать себя лучше. Но не везде )
Если открыть википедию, то увидите что там уже 3 типа ООП методологии: классы, компоненты и прототипы.
Беда в том что разум 99% программистов ограничен только классами. Они в упор не хотят замечать существование альтернативных ООП концепций.
При этом побеждают на рынке те платформы, которые научились готовить ООП не только на классах, но и грамотно применять компонентные ООП подходы: Angular vs React, Drupal vs WordPress.
Если точнее то в крупных/сложных системах надо уметь делать ООП не только на классах.
Пока вы делаете что то мелкое и простое — можно жить с ООП только на классах.
Но как только система становится достаточно большой, в команде появляется 5-10-50 разработчиков — упор на классы влечет проблемы. Часть описана в этой статье, часть гуглится по фразе «проблема хрупкости базового класса».
Это не значит что надо отказаться от классов. Это значит что надо учить другие ООП методологии: компоненты и прототипы. Там же событийная архитектура. Это существенно прокачивает гибкость. И позволяет упрощать разработку больших систем.
Об этом говорит Ален Кей — автор идеи ООП. Об этом писал в 80е годы Фредерик Брукс в своей книге МЧМ. Про это написано в Википедии. Есть куча примеров в которых ООП не на классах (а на прототипах и/или компонентах) побеждает на рынке. Но ребята с комплексом утенка упорно не хотят это замечать )
Надо почитать мысли Алана Кея, чтобы понять что ООП это не про классы.
Еще есть книга МЧМ Фредерика Брукса написанная аж в 80е годы. Там тоже расскрывается тема разных ООП подходов. Классы — это лишь один из подходов.
Как только разобраться в том что есть ООП — все эти холивары начинают походить на цирк и спор слепых людей о цвете помидора.
И какие бы там матрицы не придумали — плоский список в любом случае создаст порядок и приоретизацию.
А какими там матрицами задачи будут подниматься вверх, а какими вниз — дело вкуса. В команде из 5 человек будет 5 матриц, часть из которых будет очень не понятной, но в ходе обсуждения люди быстро договорятся что надо поднять. И так наступит порядок.
Я не против этой матрицы. Если надо можно обосновать и через нее. Но из своей практики могу сказать что главное это плоский список. А до матрицы Важности и Срочности обычно дело не доходит. Просто люди договариваются и спокойно работают над тем что приоритетно. А все что второстепенно падает вниз… иногда закрывается так и не дойдя не до каких матриц. И это хорошо.
На то время я тоже искал ответ на вопрос как эффективно ставить приоритеты?
Там ребята пришли к выводу что единственно верная система — это плоский список задач.
Вообще слово Приоритет если изучить его этимологию означает «Первый». Сколько задач одновременно могут быть первыми? :)
И вот когда заставляешь всех работать по такому списку, где физически не возможно 2 задачи поставить на 1е место ) Вот тогда люди реально начинают думать. А разработчики реально понимают что надо делать.
В идеале. В реальности конечно и эту систему можно сломать и изуродовать. Но ничего лучше пока не нашел.
Еще это называется Backlog в мире Agile. Который вам как то не по душе. Судя по некоторым мыслям проскакивающим в тексте.
Например. Иногда подключаюсь к проектам/командам, в которых творится хаос, не понимание между руководством и разработчиками, полная чехорда. Одни орут что сроки не исполняются, другие что задачи не внятные. И просто привожу все задачи к плоскому списку ) Не сразу, но спустя 1-2 месяца ситуация самоорганизуется )
Плоский список задач — это проще чем матрица ) Играть с матрицей кончил лет 10 назад.
Я боюсь представить что будет когда вы узнаете что такое OKR )
если под ссылкой понимать url то можно сделать так
www.google.ru/search?ei=Say3W7X6GcjKrgSrvbWAAw&q=Automattic+%D0%93%D0%BE%D0%B4+%D0%B1%D0%B5%D0%B7+%D0%BA%D0%BE%D1%81%D1%82%D1%8E%D0%BC%D0%B0&oq=Automattic+%D0%93%D0%BE%D0%B4+%D0%B1%D0%B5%D0%B7+%D0%BA%D0%BE%D1%81%D1%82%D1%8E%D0%BC%D0%B0&gs_l=psy-ab.3...3664.3664.0.4201.1.1.0.0.0.0.63.63.1.1.0....0...1c.1.64.psy-ab..0.0.0....0.ZfhRDAdFjLk
Однако стоит учитывать ряд важных моментов:
1. Если есть проект и дидлайн, по которому отчитывают за SCRUM — то это вывих головного мозга. Надо лечить мозг того кто эти вещи сочетает, а не обвинять SCRUM.
2. Проекты и дидлайны бывают. Но там применяются проектные методы. Классические. Без SCRUM. SCRUM — это иная история. При определенном умении их можно сочетать. Но получается это далеко не у каждого.
3. Про консультантов — в точку. В РФ именно такие. Бегают кричат про SCRUM. А по факту просто деньги сосут и портят процессы. Но опять же это не проблема SCRUM. Это специфика русских SCRUM-консультантов.
4. Видел десятки команд в РФ которые гордо заявляли что у них уже SCRUM или что они его внедряют. Но что то похожее на настоящий SCRUM видел только у 2х команд. Реально по опыту в РФ судить о этой идеологии не стоит. Тут слишком мало тех у кого хватает ума понять что это такое и как его готовить.
5. В качестве альтернативной точки зрения стоит почитать книгу про Automattic «Год без костюма». Там про то как выглядит реальный Agile. От которого один шаг до SCRUM. Но те кто по настоящему сумел освоить силу простоты Agile — редко переходят на SCRUM.
Сам по себе SCRUM не даст крутые результаты. Скорее наоборот — станет только хуже.
Выгоду дает умение играть SCRUM. Чувствуете разницу?
Плохие результаты не потому что SCRUM плохой, а птм что люди плохо умеют играть SCRUM.
Это как обвинять гитару в том что у тебя получается плохая музыка. Но если тот кто играет — «рукожоп» — то даже лучшая гитара в мире будет давать ужасную музыку в его руках.
Коммент чисто для обозначения альтернативной точки зрения. Ну и для ссылки на книгу где описана не вымышленная, а реальная компания, с реальным опытом, которая добилась тех самых 4х-10х результатов относительно конкурентов описанных в книге про SCRUM.
Сервис — такого слова в русском языке нет. Он переводится как Услуга.
Товар — это материальный продукт. То что можно взять в руки или пощупать. Разработка софта не может быть Товаром. Это всегда Услуга или Сервис.
То о чем вы говорите это Продукт или Проект. Продукт без срока — нужно думать о завтра и играть в долгую. Проект всегда конечен — можно жить сегодняшним днем, сдать его и дальше хоть трава не рости.
У нас у людей мозги в смятку. Услуги называют словом Сервис. Продукты словом Проект. А вы тут отличились и Услугу умудрились назвать Товаром. При этом по понятиям Товар в вашем понятии и Проект в народном понятии — противоречящие вещи/идеи.
Также это классическая делема истории про Яблоко от Владимира Тарасова. Потратиться на чистку и скушать быстро? Или начать кушать сейчас, но медленно тк там могут быть риски (грязные/червивые участки)? Даже в продуктовой разработке ответ не всегда очевиден. Иногда надо войти в тех долг и сделать криво, но быстро. А иногда надо замедлиться, но сделать сразу хорошо и с заделом на будущее. Что правильно и кто решает? Решает владелец продукта и он же отвечает за результат принятых решений.
Матеры разработчики это осознают благодаря эмпирическим знаниям.
Задача — найти некое описание, которое будет формализовано и понятно джунам/мидлам. Джуны как правило вообще не одупляют что почем. А мидлы часто буквально воспринимают рекомендации и начинают пилить 100500 функций на 3-4 строки и 55 классов с 1-2 методами — птм что так написано в библии Чистого кода.
Причем в РФ из за дефицита разработчиков часто мидлов и ставят сеньорами или тим лидами (из принципа — а лучше пока никого не нашли). Так и образуется рассадник шизокода, который спускается сверху теми кто до старшинства еще умом не дорос.
дай то бог )
надеюсь что вы уже не в конце своего пути )
Но это не точно )
для сайта я возьму WordPress. для магазина WooCommerce.
если мне надо написать какое то хитрое веб приложение — Laravel.
для API предпочту NodeJS или Go.
если что то системное то мб Python/Go.
тут мб куча факторов:
— мода на тот или иной фреймворк/язык
— компетенции команды
— адекватность инструмента задаче
Всегда приходится делать выбор исходя из множества факторов. Идеальных инструментов под все задачи пока не придумали.
думаю ничто не зло в абсолютном выражении. везде есть частичка добра )
но я встречался с проектами на своих CMS/фреймворках, где 80% времени приходилось тратить на угадывание логики ее авторов. а это не просто и очень дорого )
потому для себя решил что лучше буду работать с каким то платформами из топ-3, а лучше топ-1 )
Ключевое слово — излишество. Когда можно обойтись без наследования — надо обойтись без него. Птм что лишний слой абстракции — это нарушение бритвы Оккама. И там много негативных последствий.
Речь не о том что наследование это абсолютное зло и плохо. А о ситуации когда оно делается без причины. Если не встречались с таким — бамбалейо. Поздравлямба и все такое. Все впереди )
Тема весьма спорная и в отрыве от конкретной ситуации сложна для обсуждения.
Конечно говнокодинг и хардкодинг встречаются чаще. Их и лечить проще.
Однако шизокодинг существенно дороже. Мы тут зацепились за идею с излишним наследованием. Что действительно редкое проявление шизокодинга. Но все же бывает.
Гораздо чаще встречается ситуация когда разработчики начинают свои костыли пилить (при условии наличия существующих методов), фреймворки, CMS или делать Интернет магазин/Блог на чистом Laravel. На мой взгляд причина одна и таже — разработчик не удосужился изучить существующие решения. И начал пилить велосипед. И это дорого. Очень дорого обходится бизнесу.
Это значит что класс не хранит состояние (переменные, константы и т д) и применяется только для инкапсуляции методов. Такой стиль часто встречается в WordPress (например некоторые классы в WooCommerce). Обе платформы №1 в своих сегментах. Ну и в некоторых закрытых Enterprise проектах такое встречал.
Сам часто пишу именно в этом стиле. Птм что он с одной стороны дает возможность быстро писать код на старте не думая о будущем, а с другой стороны потом быстро переходить в любой из стилей по необходимости: Синглтон, классы с наследование, ФП и т. д.
Это из моего опыта: Enterprise, eCommerce, веб-приложения… на разных платформах: flat php, Laravel/Symfony, WP/WooCommerce…
Идеальный мир условно достижим на MVC фреймворках типа Laravel/Symfony. Но это в теории. На практике серьезных проектов на их базе не встречал. Только API и простые микросервисы/веб приложения.
Думаю тут важный момент — бритва Оккама. Речь именно про нее :)
Это лучший из известных мне способов объяснить абстрактно про излишнюю абстрактность :) Но боюсь он не идеален и не всем понятен с наскоку.
Если взять бритву то далее есть две ситуации:
— пишем все в 1 классе до тех пор пока нет веских причин разбивать его на подклассы
— появилась веская причина? разбиваем класс на разные классы
Какие могут быть причины? Их много:
— основной класс стал слишком большим и не понятным
— нужно разбить код на шаблоны и логику
— нужно часть функционала переиспользовать в других классах
и т д
Но бывает что причина только одна… разработчику хочется уталить свою жажду красоты и показать что он знает что такое наследование… и вот мы получаем кучу бесполезных классов, наследований и лишних слоев абстракции…