Прямой вызов обработчиков на событие практичен в простых задачах. Если задача чуть более сложна, то важными факторами правильности работы системы оказывается упорядоченность обработчиков. Приоритеты, порядковые номера – камень в модульность системы. Чтобы корректно добавить обработчик, нужно знать о других обработчиках. Правильным решением будет, когда ни обработчик, ни событие не влияют на приоритеты, а процесс обработки построен по цепочке обязанностей – вверх или вниз по иерархии компонентов системы. В Javascript, к примеру, событие нажатия по ссылке движется от самой ссылки по её родителям до документа. В итоге порядок обработки четко соблюдается структурой приложения.
С динамичностью мы вроде поняли другу друга. Какой же существенный плюс дает использование классов?
В моих задачах по управлению содержимым назначение класса может быть дословным – для классификации данных, при этом не данные определяются классом, а класс возникает от соответствующих данных для последующего осмысления данных на более высоком уровне. Поэтому в качестве базовой сущности класс не нужен.
Уточню. В моей модели типизация получается динамической, так как одной базовой сущностью нужно уметь представлять разные значения. Но применение классов не решает вопрос динамичности/статичности. Если нужна гибкость, мы в любом случаи придем к динамической типизации, например, её имитацией. Прототипную модель реализовывал в реляционной базе, на её статической типизации имитировал динамическую ради гибкости. А что даст классовая модель?
Абсолютный предел до каких последствий довел? Меня тоже привлекает минимальное число базовых сущностей. В своём проекте применял классы и другие метаданные, но с метаданными приходится сталкиваться не только мне, как программисту, но и пользователям системы. В прототипной модели вижу гораздо больше гибкости и простоты, так как пользователи могут создавать сразу нужные объекты без необходимости предварительно создавать метаданные (классы).
Прототипная модель и классовая могут быть, а могут не быть динамически типизированными, это не их особенности. Проверка принадлежности к классу равносильна проверке наследования объекта. Какие вы видите преимущества у классовой модели? Думаю, они могут проявляться на конкретной задаче, но не во всём.
В прототипной модели нет самостоятельного понятия «прототип». Прототипом может быть любой объект. Это всего лишь терминология, чтоб обозначить роль объекта в конкретной рассматриваемой ситуации. У нас только объекты. Я скажу обратное, нам не нужны классы, чтоб творить ) Классы скорее нужны там, где важна стандартизация и запрет выхода за её границы, и в программном обеспечении это редко оправдано в виду его частого изменения, необходимости расширения функциональности, изменения стандартов деятельности, где программа внедрена. В итоге классы на порядок усложняются, придумываются примеси, динамические вызовы методов, свойства, модификация во время выполнения – процесс от обратного, сначала запретить/ограничить, а потом разрешать.
Приятно удивлен, что по этой теме диссертацию защищают. :)
В статье не затрагиваются вопросы реализации модели. Для реляционной, иерархической, документной есть свои СУБД. На реляционной можно и иерархию сделать, и объектную, и любую другую. Также и на документной и на иерархической. Вопрос в практичности. Для прототипной нет родной субд, поэтому её реализация на других потянет за собой их особенности.
Мною реализована эта модель на реляционной, и, к примеру, приходится придумывать трюки для работы с иерархией, с представлением неограниченных по длине и типу значений. Чем плоха иерархия в реляционной? Сделать можно, но она для этого не предназначена, приходится хранить и работать с специальными для этого данными: мат. путями, например. А как представить любого типа значение в одной колонке? Можно использовать строки, но тогда проявляются особенности сортировки по числам, работе с датами и индексированием таблиц. Или на каждый возможный тип делать свои колонки, отдельные таблицы…
Подозревая, что дополнительно тратиться время на проверку существования файлов и возможного отсутствия файла, игнорирую все запросы, соответствующие путям на файлы (имя + расширение файла + аргументы после? для сброса кэша): RewriteCond %{REQUEST_URI} !\.[a-zA-Z]{1,4}[\?0-9]*/?$ [NC]
RewriteRule ^(.*)$ index.php?q=$1 [E=REMOTE_USER:%{HTTP:Authorization},L,QSA]
С одной стороны слушаешь и думаешь, что доля правды есть, но слышать траурную речь от успешного бизнесмена ужасно… заняли «стул» и уверен, что другого никто не сделает без мегаденег?
Думаю, Riateche не предлагал использовать requre_once() везде. Если знаем где файлы, не нужно их искать. При первом обращении к классу автоматом грузим автоматом.
В моих задачах по управлению содержимым назначение класса может быть дословным – для классификации данных, при этом не данные определяются классом, а класс возникает от соответствующих данных для последующего осмысления данных на более высоком уровне. Поэтому в качестве базовой сущности класс не нужен.
Прототипная модель и классовая могут быть, а могут не быть динамически типизированными, это не их особенности. Проверка принадлежности к классу равносильна проверке наследования объекта. Какие вы видите преимущества у классовой модели? Думаю, они могут проявляться на конкретной задаче, но не во всём.
Приятно удивлен, что по этой теме диссертацию защищают. :)
Мною реализована эта модель на реляционной, и, к примеру, приходится придумывать трюки для работы с иерархией, с представлением неограниченных по длине и типу значений. Чем плоха иерархия в реляционной? Сделать можно, но она для этого не предназначена, приходится хранить и работать с специальными для этого данными: мат. путями, например. А как представить любого типа значение в одной колонке? Можно использовать строки, но тогда проявляются особенности сортировки по числам, работе с датами и индексированием таблиц. Или на каждый возможный тип делать свои колонки, отдельные таблицы…
RewriteCond %{REQUEST_URI} !\.[a-zA-Z]{1,4}[\?0-9]*/?$ [NC]
RewriteRule ^(.*)$ index.php?q=$1 [E=REMOTE_USER:%{HTTP:Authorization},L,QSA]
В RewriteRule учтена ещё HTTP авторизация.