Так дело в том, что ООП - это вовсе не форма записи, это концепция организации кода. Сама форма записи не имеет значения. Равно как и выбор языка. Другое дело, что определенная форма записи, определенный как бы заставляет (или пытается заставлять) следовать принципам ООП, создает для этого подходящие условия.
Оба примера - это объектный подход. То, что вы записали одно и то же разными способами сути не меняет. Собственно классы появились именно как развитие того, что вы назвали "функциональным подходом".
Отражения - это уже плюшка выросшая из ООП. Также как ООП выросло из изоляции логики в отдельных файлах и модулях, которые в ООП уже превратились в классы.
Вам не кажется, что если один и тот же код сначала записать в виде классов, следуя всем канонам ООП, а затем позаменять всё на аналогичный процедурный код (как это делалось в примерах выше), то вы всё равно будете иметь нечто, соответствующее идеям ООП? Естественно, что обратное в общем случае - неверно. Более того: c моей точки зрения дело вовсе не в классах. Можно писать процедурный код завернутый в классы, а можно писать ОПП-код без классов. Если вы будете на С моделировать классы, абстракции и отражения - вы по суте получите тот же ООП, только синтаксически иначе записанный.
Для меня ООП - это концепция написания кода таким образом, чтобы его можно было эффективно повторно использовать, расширять и заменять. Такая аналогия: в ООП мы вместо того, чтобы просто прокладывать дорогу по кратчайшему пути из точки A в точку B, делаем на этой дороги съезды на другие дороги - это ничуть не ускорит поездку из A в B, но зато если вы захотите получить дорогу из A в C, расположенное рядом с дорогой, то вам это будет гораздо проще.
А вам не кажется, что это как раз тот же ООП, только искуственно записаный полностью процедурно? Или наоборот - такая процедурная запись это как раз то, из чего выросло ООП и разница здесь - только на уровне синтаксиса?
Некоторые провайдеры режут реферреров. Некоторые сетевые администраторы настраивают в сетях шлюзы/огнестенки так (не всегда специально), чтобы реферреры резались. Итого имеем проблему: метод для некоторых пользователей принципиально не работает.
Имхо, самое подходящее применение для инлайн изображений - капча (не нужно кэшировать, привязано к странице, код на сервере немного упрощается). В остальных случаях обычно лучше от лишних запросов избавляться с помощью "CSS sprites".
А вы не знаете, сколько по статистике водителей либо знают упомянутую статистику, либо в состоянии догадаться что сейчас произойдёт? Думаю довольно немного. Вот мне бы никогда раньше просто в голову не пришло, что машину, на которой я еду, могут остановить, чтобы перекрыть дорогу не выпуская пассажиров.
Так дело в том, что люди, на момент остановки гаишником, не имели понятия, почему их остановили и оставили посреди дороги. Любой нормальный человек если бы знал, что его сейчас протаранить могут - конечно бы не остался стоять на месте или по крайней мере вылез бы из машины.
К сожалению я имею несколько негативное мнение насчет удобства джойстика xbox, поэтому продолжу настаивать, что по крайней мере для некоторых игр некоторые джойстики - это очень удобно.
Я до прошлого года также «не верил в приставки». Но знаете, если просто прийти к человеку с, например, PS2 и два-три часа на ней поиграть, то вы поймете, что джойстик - это реально очень удобно.
В дополноение PngOut советую присмотреться к компрессору Pngcrush.
А вообще, очень рекомендую использовать вот этот наборчик с сайта по технике перевода манги. В набор входит несколько компрессоров PNG и батники для пакетного сжатия PNG разными комбинациями компрессоров + интсрукции по использованию. Notice: в инструкциях «сканы»=«PNG-файлы».
Это наглядная трехмерная схема - на самом деле «воронка» там четырехмерная. Но так как четырехмерную воронку на бумаге просто так не нарисуешь, то одно из трех «обычных» измерений отбрасывают, а вместо него изображается измерение, в котором изменение пространства-времени выглядит как воронка.
Если представить, что к данной собираемой информации получат доступ те самые террористы (а 100% надежных систем не бывает), то они потенциально смогут нанести такие удары, что трагедия с башнями-близнецами уйдет на второй план.
Вам не кажется, что если один и тот же код сначала записать в виде классов, следуя всем канонам ООП, а затем позаменять всё на аналогичный процедурный код (как это делалось в примерах выше), то вы всё равно будете иметь нечто, соответствующее идеям ООП? Естественно, что обратное в общем случае - неверно. Более того: c моей точки зрения дело вовсе не в классах. Можно писать процедурный код завернутый в классы, а можно писать ОПП-код без классов. Если вы будете на С моделировать классы, абстракции и отражения - вы по суте получите тот же ООП, только синтаксически иначе записанный.
Для меня ООП - это концепция написания кода таким образом, чтобы его можно было эффективно повторно использовать, расширять и заменять. Такая аналогия: в ООП мы вместо того, чтобы просто прокладывать дорогу по кратчайшему пути из точки A в точку B, делаем на этой дороги съезды на другие дороги - это ничуть не ускорит поездку из A в B, но зато если вы захотите получить дорогу из A в C, расположенное рядом с дорогой, то вам это будет гораздо проще.
И да. Используйте патенотованные велосипеды:
History/Remote - jQuery plugin solution for hijaxing links and enabling history <- тут всё есть ^_^
А вообще, очень рекомендую использовать вот этот наборчик с сайта по технике перевода манги. В набор входит несколько компрессоров PNG и батники для пакетного сжатия PNG разными комбинациями компрессоров + интсрукции по использованию. Notice: в инструкциях «сканы»=«PNG-файлы».
Так что пользователи - тоже могут. Правда очень небольшой их процент :-/