spl_autoload_register вызывается только тогда класс не объявлен и при обращении к конкретному классу если он его не находит...

так же как и __autoload()

 Цитату из Макконела, пожалуйста.

 В реалиях PHP данные фразы противоречат друг другу. Либо разбросать подключения, либо сделать автоподключение.

 Каким же образом? Да даже не усложнить, а просто повлиять на понимание? Любая IDE сама разберется, где какой файл подключается.

 И что? Посмотри, как автозагрузка работает.

 Зачем?

 Каким же образом? Да даже не усложнить, а просто повлиять на понимание? Любая IDE сама разберется, где какой файл подключается.

[/QUOTE]
Честно говоря не хочется вступать в дискусию (всё таки это холивар чистой воды будет  ).
У Макконнелла, если кто внимательно читал, всё "пропитано" простотой архитектуры и построения и если что то задаётся неявно и можно сделать проще - это нужно сделать. По поводу цитаты - можете сами у Макконнелла да и не только у него найти - пишите для людей (программистов) а не для IDE, да так что бы можно было читать код и не искать где производится включение кода (особенно если касается разработчиков работающих не с IDE (не будем разводить холивар что пора бы уже перебраться на них)). Это меня наводит на программистов на JS, которые пишут имена переменных и функций наподобие "btcdret", как говорится - повбывав бы )

Я бы сказал дискусия на тему _autoload() подобна применению директивы goto, так же неявно задаёт смысл читаемого кода.
Без цитат -   Макконнелл и его сторонники рекомендуют - прямолинейное "чтение" кода упрощает разработку и особенно  поддержку его последующими разработчиками.

Так же есть затруднение с переносимостью модулей (допустим модулей). При архитектруе фасад и фабрики мы могли бы модуль полностью сделать автономным, при "доверении" подключаемых файлов в __autoload мы лишаемся, некторой части автономности, а детальней при переносе в другой проект он уже потребует сторонних включений своих!!! же файлов, то есть мы перенесём знания структуры модуля во внешнюю структуру ... судите сами 

Это сообщение отредактировал(а) Sentox - 20.1.2012, 22:54

Sentox, если я правильно понимаю назначание __autoload то это в превую очередь исключение дублирующих include и require, а eже потом все остальное

Это сообщение отредактировал(а) krundetz - 20.1.2012, 23:16

Исключение дублирующих include и require - это include_once и require_once (при чём на уровне пхп машины!) всё остальное не должно это надстраивать если это уже до нас сделали.

Можно на эту тему? Кто в фасаде и фабрике расскажет фабрике где находятся модули?
Не будет ли более корректно отвязать фабрику и фасад от информации о структуре файлов модуля и оставить им только собственную логику? Не повысит ли такая отвязка автономность модуля?

Фактически фасад я упомянул так, для универсальности (скажем так пример модуля компилятора с фасадом к модулю (извините за тавталогию)), а вот фабрика может сама "знать" о с своей структуре и подключать файлы (хотя бы в switch (кстати хороший пример абстрактная фабрика, которая "отрывает" модуль от платформо - зависмости)). Допустим имеем одну фабрику (файл), который является так же и инфраструкторой модуля. При подключении одного файла - фабрики мы включаем в работу весь модуль не отдавая "знаний" включения его структурных файлов, а алгоритм использования модуля лежать может на интерфейсах фасада.

Впринципе это моё мнение.

Добавлено @ 23:39

Фасад наверное да, скорее всего, а вот фабрика как раз и призвана локализировать по определённой категории, аспекту или абстракции инстанцирование и подключение объектов. Так что её алгоритм основной как раз в этом и состоит.

Добавлено через 12 минут и 33 секунды
Наверное и скорее всего _autoload будет применим к конкретному аспекту подключения основных скриптов ядра системы, хотя честно говоря я не сторонник этого, несколько безответственно даёт разработчикам вносить включения классов, и если система будет раздуваться это грозит сложностями.

Это сообщение отредактировал(а) Sentox - 20.1.2012, 23:40

Sentox, ТОесть, что свалить в одну кучу ДВА РАЗНЫХ механизма ( файловую структура модуля и фабричную логику) будет более правильно с точки зрения ООП, чем сделать 2 независимых друг от друга механизма? 

Начнём с первого:
к ООП это точно не относится ,  (не люблю не аргументированных ответов) - так как ООП (как программирование так и проектирование) структурирует в основном (да ну в основном) данные и призвано к качественному манипулированию данными, но с инфраструтурой лучше справляется именно функциональные решения, поэтому вся инфраструктура может определена в одном методе (функции)

Второе:
вопросом на вопрос - в чём состоит суть фабрики (не абстрактной фабрики), и как лучше разделить аспекты подключения файловой структуры модуля и инстанциирование объектов из классов модуля?

Это сообщение отредактировал(а) Sentox - 21.1.2012, 00:24

Спрашивая о "не абстрактной фабрике" стоит ее как то определить, не так ли? Фабрика, вообще говоря по символическому обозначению предоставляет некий конкретный объект. К примеру, по запросу "дай мне класс для отправки почты", в зависимости от конфигурации приложения и состояния сервера может выдать класс, основанный на mail, smtp или еще какой почтовой приблуде... Фабрика обязана знать КАК инициировать все эти разные классы, однако не обязана знать ГДЕ конкретно они находятся.

Вообще говоря, все разговоры вокруг ООП и стиля программирования обязаны приводить к удобству повторного использования кода. При повторном использовании такой фабрики, в приложении с другой файловой организацией, но с тем-же примерно комплектом серв-объектов, не придется переписывать ее вообще.

Как же Вы не поймёте что файовая организация модуля локальна для модуля и соответственно фабрики.


Да нет же, я ж писал выше, она является ещё и инфраструктурой, если хотите index.php для модуля (компонента).
И ещё как должна знать, если она "хочет" быть инфраструктурой модуля и единственной знающей единицей о структуре..

Всё же мой вопрос в силе? Я просто могу пример привести что при выходе "знаний" структуры наружу рушится целостность автономности.

Это сообщение отредактировал(а) Sentox - 21.1.2012, 02:05

 Именно поэтому я за автозагрузку. Наиболее прямой и простой метод без дублирования. В данном случае автозагрузка дает простую иерархическую архитектуру модулей и единую точку подключения.

 Какой части автономности ты лишаешься?

 Ей знать не надо, она может просто нужное подключать и оно подключится. spl_autoload_register();

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

но ведь интепретатору нужно предприянять действия отсеевающие дубли? а так вроде бы один вызов одно подключение.

Хотелось бы увидеть.