при отсутствии одного или более из китов это уже не ООП
Нуу это спорно. Например, я считаю, что главный кит - инкапсуляция, потому что грамотная инкапсуляция в первую очередь позволяет снизить сложность проекта.
Чрезмерное наследование - наоборот увеличивает сложность (правда, без него никак не обойтись). Но обходиться на маленьких задачах без него вполне можно. (Добавление)
caballero пишет:
Суть ООП - это инкапсуляция. Остальное -удобные фишки.
О, я не один так считаю (Добавление)
DeepVarvar пишет:
ще бы объяснить доходчиво, что это за "инкапсуляция" такая..
Попробую. Есть логика. Например, логика того, как мы идем вечером с работы домой.
1. Сохранить наделанное.
2. Надеть куртку.
3. Идти, идти, пока не придешь.
Это три функции. Разберем, например, вторую. Ее реализация будет примерно такой:
2.1. Поднять руку, снять ее с вешалки, повернуть к себе нужной стороной, сунуть в нее руки, проверить, вошли ли руки удачно (если не удачно, то бросить ексепшн и попробовать заново), застегнуть.
Вот функция НадетьКуртку инкапсулировала в себя сложный процесс. Вся эта сложная вещь скрыта в том, что описано в 2.1 (это приватные методы класса. Ими не положено пользоваться из вне и о них не нужно даже думать), а мы беззаботно пользуемся публичным методом НадетьКуркту нашего класса.
А как разработчик класса, мы можем менять, оптимизировать эти приватные методы, инкапсулированные от пользователя класса, никак не мешая ему пользоваться старыми добрыми публичными методами, которые мы ему дали.
Часто мы можем сами выступать и как разработчик класса, и как пользователь, инкапсулировав его сложность на этапе разработки и дальше беззаботно пользоваться его интерфейсом(его публичными методами).
Вот. Это конечно неполное такое описание, но какое-то накатал
Во-первых, речь не о "каком угодно наборе", а о
snikers987 пишет:
SELECT * FROM `table` LIMIT 999, 1
Ну на опытах Мелкого и такой запрос никак не оптимизируется. И в експлейне никакого намека на оптимизацию. И в том же експлейне предполагаемое количество обрабатываемых строк сопоставимо с цифрой Х в выражении LIMIT X,1.
EuGen пишет:
LIMIT - это частный случай HAVING
Никогда об этом не задумывался, но по сути да, так и есть. Но дело в том, что ХЭВИНГ применяется так же к получившемуся набору после всех остальных опираций и никогда не думает пользоваться ни индексом, ни чем-то похожим.
MySQL 5.1. Вот (Добавление)
... Однако, с myisam limit всё-таки, похоже, оптимизируется, да.
С InnoDB - нет.
MySQL >=4.1 - СУБД сразу выберет нужное исходя из параметров LIMIT
Ээм. Это физически не может быть реализовано, потому что результирующий набор может получаться каким угодно способом и сортироваться не менее каким угодно способом. Чтоб выполнить такой Limit, надо в любом случае пробежаться по всем строкам
Возможно, что Вы рассчитываете на регистронезависимость регулярки. На самом деле она регистрозависимая, и буквы в расширении надо указать в обоих регистрах.
А еще хорошо бы знать пример запроса (он действительно отличается только заменой png на lol или, может быть, чем-то еще?). И хорошо бы знать, какие до этого указаны RewriteCond, если они указаны.
Это о провайдерах, выдающих динамические ИП. Разве не похоже? И еще у Вас грамматические ошибки и слова в падежах не согласуются.
KoDeRSmerT пишет:
da cto to takoye xocu no kat delat/?
Свой браузер со своим юзерагентом. Только в этом юзерагенте уникальная штука, которую только придумайте как сгенерить. GUID, например. Только его очень просто подменить, если не будет каких-нибудь дополнительных проверок корректности. Но это так, в порядке бреда. Не заморачивайтесь
Да, ни при чем. Перенес в другой раздел. KoDeRSmerT, единственный достоверный способ - регистрация и авторизация. Либо выпустите свой собственный браузер (назовите его "бровзер"), реализуйте в нем метод уникальной идентификации(скорее всего чудо-заголовком (но его можно будет подделать) ) и принуждайте Ваших посетителей пользоваться именно "бровзером".
Главная
Помощь
Поиск
Пользователи
Найдено сообщений: 4334
