Так тогда Вы получите привязку в контексте объекта (точнее, класса объекта) - это точно такая же "эмуляция" соответствующей области видимости. То есть - "извне" доступа всё равно не происходит, суть та же, что указана в примере выше, когда привязка происходит изнутри метода.
Вкратце - "извне" (из другого контекста) доступ получить не получится. bindTo с указанием области видимости как класса текущего экземпляра есть лишь встраивание кода замыкания в контекст этого класса.
Начиная с 5.4 можно штатно к любому private методу или свойству получить доступ, не имея вовсе никакого отношения к этому классу... С помощью closure::bindTo.
Будет работать - но это лишь частный случай уже рассмотренной выше проблемы, когда доступ проверяется на уровне текущего класса, а не конкретного экземпляра класса.
Весь достойный материал - изначально на английском. И если и удастся что-то найти на другом языке, то с вероятностью 90% это будет перевод/перефразирование оригинала (не раз находил рекомандации тех или иных ресурсов, после прочтения/просмотра которых я узнавал предложения и абзацы из того, что видел в оригинале). Так что - если хочется получать качественную информацию, следует знать язык хотя бы на бызовом уровне.
Сегодня завершена бета-версия проекта mysql-unit. Цель - тестирование хранимого кода для MySQL. Хранимый код - достаточно редко оправдан в применении, однако тогда, когда его использование требуется, должна быть возможность его протестировать. Это и является причиной создания фреймворка.
Проект не основан на UDF, поэтому установка не потребует установки сторонних библиотек; даже перезапуск MySQL-сервера не нужен. Документация доступна здесь
Вообще - нет. Именно в корне и есть отличие. Потому что конкретный паттерн можно реализовать на каком-нибудь функциональном языке (типа Haskell) - за исключением, быть может, тех паттернов, что проистекают из объектного подхода и связаны с сохранением состояния (но называть их просто "паттернами" в таком случае - некорректно, так как они - всего лишь подкласс паттернов). И ООП здесь ни при чём. ООП - это, грубо выражаясь, "протокол более низкого уровня" по отношению к паттернам.
eai пишет:
Вконтакте на функциях наляпяли и ниче , не хужее фейсбуку
Во-первых, это отдельная история (со своими решениями), во-вторых, ради этого им пришлось.. разработать методику тестирования. И - у них не "наобум" сделана структура. Создано упрощение, но умышленное и направленное.
Шаблоны проектирования, которые как правило заточены под ООП.
Шаблоны проектирования концептуально не имеют ничего общего с ООП. Дело другое, что реализации конкретных шаблонов могут быть сделаны в контексте ООП, а некоторые частные паттерны даже привязаны к этому контексту.
teddy пишет:
Мой тебе совет, сначала просто изучи возможности ООП, узнай, как это работает технически
Технически ООП никак не работает, это лишь подход. Технически работает его реализация в конкретно взятых языке и платформе.
OrmaJever пишет:
Если интересует скорость то функции быстрее, но классы в большинстве случаев удобнее
Если под скоростью имеется ввиду стек вызовов, то расходы ничтожны. Если абстракции - то зависимо от того, что требуется. Правильно спроектированное приложение не будет злоупотреблять абстракциями.
eai пишет:
Делайте как вам удобнее или как требуется для проекта.
Всё же, если это именно "проект" - то без изоляционности объектного подхода практически никуда не двинуться. Поскольку код нужно тестировать. Если это - скрипт на пару десятков строк, который что-нибудь пишет в нужный файл и делается на один раз - то - да, объектный подход вряд ли пригодится
По теме - почитайте про S.O.L.I.D. подход, тестирование кода (особенно про интеграционные тесты (то есть, как с ними работать и как свести их число к минимуму), так как с юнитами и так всё ясно). Классика Макконела тоже пригодится. Ах да, ещё про S.T.U.P.I.D. код тоже пройтись можно. Хороший набор анти-паттернов.
Если вы не знаете, нужны ли вам хранимые функции/процедуры, то они вам не нужны.
Use-cases
Несмотря на очевидные недостатки, у хранимого кода есть области применения. Основная из них - когда требуется высокая безопасность и у хранимых данных нет доверия к коду, работающему с ними. Иными словами, когда разработчик приложения - не доверенное лицо. У него может не быть никаких прав, кроме вызова ограниченного набора процедур, возвращающих лишь ту часть данных, к которым у него есть доступ.
Кроме того, иногда бывает нужно реализовать вещи которые попросту отсутствуют в СУБД. Для MySQL это - например, замена по регулярному выражению. Не так давно я реализовал это. Конечно, есть UDF - но далеко не всегда возможно их использовать (равно как и устанавливать сторонние библиотеки)
Нет, потому что это - часть "S.T.U.P.I.D." - кода.
- Tight coupling (Жёсткая связка)
- Untestability (Невозможность тестирования)
- Duplication (Дублирование)
Общеизвестный пример. Если для того, чтобы построить дом, нам нужна дверь, мы не будем её создавать, а просто возьмём готовую. Так и здесь - если для исполнения метода нужен объект, не следует его создавать, следует его передавать.
Ни в чём. Первый - весьма простой вопрос. Требует базовых знаний. Второй - ну, для разнообразия. Если кто-либо не видел и кому интересно посмотреть глубже.