Ну скажем так. Для правильного проектирования ООП программ по принципу фреймворка. И я имел ввиду именно DIP.

Если идти по принципу pull, то приложение обязано знать, с чем именно работает. А библиотеки должны быть максимально автономны и пригодны к повторному использованию. Если инвертировать зависимость и заставить библиотеку зависеть от абстракций приложения, рано или поздно все опять скатится к фреймворку.

Если следовать идеологии - то нельзя конечно. Я не о том говорил. А о том, что нельзя упрекать мою схему в нарущении SOLID в части DIP.

Конечно, зачем бы я давал пруф. Я не говорил, что там разбили Мартина наголову. Я говорил о том, что нельзя все принимать на за чистую монету, всегда найдутся и другие мнения. Ведь они есть в этой статье?

Вот к вопросу о DIP и схемы pull

_____________
Если вам недостаточно собственных заблуждений, можно расширить их мнениями экспертов.

Нужно уважать мнение оппонета. Ведь заблуждаться - его святое право.

Настаивал, настаиваю и буду настаивать на своем. На кедровых орешках.

То есть у тебя точка входа на сайт, это файл приложения?

Из твоего пояснения я понял что в первом случае точка входа это файл фреймворка, который в зависимости от команд, выдаёт тот или иной результат с помощью расширений, библиотек и кузькиной матери, которые он в себя подключает.

Во втором случае получается что команды посылаются напрямую в приложение, которое в свою очередь может подключить в себя стартовые скрипты, библиотеки и кузькину мать.




_____________
Промокод предоставляет скидку на заказ домена и/или хостинга reg.ru
BFCC-3895-8804-9ED2

Читай внимательно. Я даже картинку нарисовал)

У меня нет фреймворка. Фреймворк, это самодостаточная программа, которая интегрирует в себя пользовательские скрипты и управляет ими, предоставляя свой внутренний функционал.

У меня пользовательские скрипты никуда не интегрируются, а работают автономно, управляя библиотеками и получая от них результат. Есть только инфраструктура запуска. Ну можно и эти скрипты отнести к разряду приложения.

Если по простому, как bestxp объяснял, то принцип тот же, RR. Только в случае фреймворка так:

В моем так:

chee
Ну а чего скромничаешь, покажи уже во что это вылилось в итоге.

Кому интересно про тот батл, сюда.

_____________
Если вам недостаточно собственных заблуждений, можно расширить их мнениями экспертов.

Нужно уважать мнение оппонета. Ведь заблуждаться - его святое право.

Настаивал, настаиваю и буду настаивать на своем. На кедровых орешках.

Мне кажется так везде.
Взять любой движок, там модули могут иметь свои библиотеки, модели, шаблоны, которые они используют.
Плюс есть какие то стандартные библиотеки типа отправка почты, загрузка файлов.

Не может такого быть. Фреймворк не может содержать всевозможные библиотеки для решения всевозможных задач.
Тогда бы и композер не придумали. Делали бы всё хуками как в друпале.
В любом случае расширение подключает или получает те библиотеки, которые ему нужны.
Некоторые библиотеки уже есть во фреймворке, некоторые предоставляет само приложение.

Например библиотека по управлению новостями, это часть модуля новостей, она не может быть по дефолту зашита в фреймворк. Ну точнее может, но она такая нафиг никому не нужна, потому в ней что то не реализовано, чего то в избытке, в итоге разработчику модуля новостей проще написать свою, чем безрезультатно использовать встроенную.

Внутренний функционал это и есть библиотеки.
У тебя либо библиотек общих нет и ты каждый раз для приложения пишешь класс для загрузки файлов, либо что то путаешь, либо я не могу тебя понять.


_____________
Промокод предоставляет скидку на заказ домена и/или хостинга reg.ru
BFCC-3895-8804-9ED2

Он все и не содержит. Но когда пишется фреймворк, в него стараются напихать их по максимуму. Я собираю сайт как конструктор, добавляя библиотеки из репозитария (ну или сторонние). Только те, которые востребованы. И ими управляют мои, пользовательские скрипты, а не фреймворк.

В первом случае приложение (равно как и сторонние либы) нужно подключить в фреймворк, чтобы он смог с ним работать.
Собственно в случае с фреймворком приложение является своего рода библиотекой. Допустим в Yii чтобы запустить контроллер, нужно отнаследовать его от базового. А часто нужно прописать еще и правила роутинга, чтобы фреймворк знал, куда ему обратиться за контроллером.

А чтобы использовать компонент, нужно прописать его в конфигу. И тогда сам фреймворк его увидит и внедрит в систему. И он станет доступен в пользовательских скриптах.

Если это сделано по схеме фреймворка, то ты должен и к этой библиотеке указать путь в конфиге. И её настройки. Дабы фреймворк знал, где её взять и что с ней делать. Ну как-нибудь так:

    'components' => [
                        'news' => [
                            'path'  => 'librares/news.php',
                            'count' => 20,
                        ],
                    ]; 

При этом ты должен написать либу так, чтобы она была совместима с фреймворком (принцип DIP). А это сильно бъет по возможности повторного использования. Ну или как минимум должен быть адаптер.

Если фреймворка нет, то либа просто подключается в пользовательский скрипт (модель допустим). И используется с родным интерфейсом, потому что нет глобального окружения - фреймворка. Который диктует свои условия.

Вот в этом и вся принципиальная разница.

_____________
Если вам недостаточно собственных заблуждений, можно расширить их мнениями экспертов.

Нужно уважать мнение оппонета. Ведь заблуждаться - его святое право.

Настаивал, настаиваю и буду настаивать на своем. На кедровых орешках.

Ты прежде чем что-то возражать, почитай на что ты возражаешь. Я же подробно написал, с пруфами даже, чем отличается фреймворк от сборки.

_____________
Если вам недостаточно собственных заблуждений, можно расширить их мнениями экспертов.

Нужно уважать мнение оппонета. Ведь заблуждаться - его святое право.

Настаивал, настаиваю и буду настаивать на своем. На кедровых орешках.

Это ты описал правила конкретных фреймворков, может что сам выдумал, может в каком то фреймворке это так, в каком то по другому.

Представь фреймворк где не надо наследоваться ни от чего, приложение может состоять из одного файла index.php с содержимым "Привет" даже без php тегов и это будет работать.
А можно написать контроллер в виде класса и получать его с помощью DI (DIC), а можно получать с помощью include и new.
А можно прям в index.php вызывать нужные методы из нужной модели, подключенной с помощью DI или new.
DI это библиотека фремворка, но её можно и не юзать, как и любые другие библиотеки. Просто написать "Привет" будет достаточно.

То есть приложения можно писать как хочешь, можно с MVC, можно простынёй, можно с классами, можно на функциях. Может использовать API фреймворка, может нет.
Правил нет.
Но это приложение не делает фреймворк фреймворком или не фреймворком, это просто приложение, которое запускается в стартовом файле с помощью стандартных библиотек.

Так вот такой фреймворк, тоже фреймворк, просто со своими правилами для разработки приложений.
Но он точно так же, как и все состоит из точки входа, стандартных библиотек и подключаемых приложений.

И количество библиотек в фремворке не делают его более сложным или тормознутым.
Потому что будут подключены только те, которые требуются для процедуры запуска и приложений.

_____________
Промокод предоставляет скидку на заказ домена и/или хостинга reg.ru
BFCC-3895-8804-9ED2

Как оказалось нет. Есть давно устоявшееся определение, чем отличается сборка (глобальная библиотека или приложение) от фреймворка.

Перевод:

Я почему на этом акцентируюсь, напомню. Потому что по незнанию ли, или по коньюнктурным побуждениям, или просто по течению, "правильным" ООП и рассово-верной архитектурой является как раз схема фреймворка. А это не так. Обе схемы равноправны и имеют право на жизнь.

_____________
Если вам недостаточно собственных заблуждений, можно расширить их мнениями экспертов.

Нужно уважать мнение оппонета. Ведь заблуждаться - его святое право.

Настаивал, настаиваю и буду настаивать на своем. На кедровых орешках.

Да это фреймворк, маленький и хлюпенький, но он выполняет свою роль, а именно настраивает окружение и передает управления приложению.

_____________
Люди, имеющие низкий уровень квалификации, делают ошибочные выводы, принимают неудачные решения и при этом неспособны осознавать свои ошибки в силу низкого уровня своей квалификации

Почему нет?
"Главное отличие библиотек от фреймворков в том, что фреймворк запускает приложение, а приложение может запускать библиотеки"
Это сравнение библиотеки и структуры в которой они работают.

У тебя фреймворк, он использует библиотеки и запускает приложения которые используют библиотеки.
У chee тоже самое, у меня тоже самое, в YII тоже самое. Разница в реализации, реализация накладывает правила.
Где то есть возможность, делать приложения без наследований, где то не додумались реализовать такую плюшку, пришлось наложить правила =)

_____________
Промокод предоставляет скидку на заказ домена и/или хостинга reg.ru
BFCC-3895-8804-9ED2

Нечесно дописывать после того, как я ответил.

У меня другое мнение. Причем ты сам себе противоречишь. Если у тебя четкие правила для расширения, наказываемые самой структурой, то о какой максимальной переносимости ты говоришь? В мою систему - да, можно легко. В неё вообще всё что угодно легко затолкать. Именно по причине такой архитектуры, где приложение пользуется интерфейсами компонентов, а не компоненты построены по "четким правилам". А вот если у системы (допустим у фрейма Ron'а) другие "четкие правила", то увы и ах.

А теперь про плюсы моей схемы. (про минусы твоей не буду, ты же не писал, хотя и завуалировал )

1. Низкая ресурсоемкость. Это очень важно на высоконагруженных проектах. Сравнение подходов из батла (volter_9 доделал все же свою поделку), при равном функционале моя свистопукалка работала в 10 раз быстрее. На порядок. А это значит, что если возможности сервака использовать на 100%, то можно принять в 10 раз больше посетителей.
Количество подключаемых файлов у нас с тобой отличается на порядок. А это тоже самое, но по оперативке. И я на серваке могу разместить десяток таких систем, вместо твоей одной.

2. Да, можно говнокодить. Можно использовать любую парадигму в компонентах, разницы нет. Допустим API платежных систем часто дают в процедурном виде. Нужно переписывать под твою систему, а зачем?

3. Я использую только то, что требуется. Допустим на работе по специфике невозможно использовать ЧПУ. Ну и на кой мне в системе преобразователь URL или правила роутинга? Или наоборот. У меня очень много специфичных модулей, которые не просто нельзя в опенсорс показывать. Это вообще под грифом "секретно". Зачем мне их интегрировать в инфраструктуру? Да и одна конфига только будет весить полтонны. А это удар по читабельности, соответственно по сопровождению. А так либа подключается сама.

4. Про сопровождение. У тебя есть четкие правила, как ты говоришь. А где они? Без документации твой код, это дебри и темный лес. Да и с документацией нужно тратить время на её изучение. У меня цепочка прохождения минимальна и код очевиден. Причем отсутствие сервис-локаторов намного упрощает дебаггинг. А это в проекте с постоянно модифицируемым функционалом очень важно. Логика алгоритмов компонента может быть запредельной, но логика управления им проста до безобразия.


5. Ну и последнее. Ты постоянно меняешь технологии. Вот если тебя сейчас убедят, что DI через свойства, это антипаттерн, тебе придется перелопатить всю систему. Что ты кстати и делал неоднократно. Я ничего делать не буду. Потому что нет инфраструктуры, нет проблем. Компоненты обновляются в эволюционном порядке не затрагивая остальных и всю систему.

Схема фреймворка хороша, когда это опенсорс или для фриланса. Где важна скорость разработки и наплевать на ресурс. Потому я и говорю - обе схемы имеют и преимущества и недостатки. И это не я придумал. Но они обе имеют право на жизнь. Так что не схватил ты Бога за яйца, никакие это не новейшие технологии. Это просто одно из направлений.

_____________
Если вам недостаточно собственных заблуждений, можно расширить их мнениями экспертов.

Нужно уважать мнение оппонета. Ведь заблуждаться - его святое право.

Настаивал, настаиваю и буду настаивать на своем. На кедровых орешках.