Да, если у тебя денвер, то тебе необходимо скачать пакет расширений php5 и установить его предварительно или выкачать с оффсайта бинарную сборку и накатить сверхуhttp://windows.php.net/download/ я просто не знаю каким сервером пользуешься
а зачем его качать, он идет в стандартной сборке php лежит в папке ext, называется php_sqlite.dll, тебе надо в php.ini раскомментировать строку ;extension=php_sqlite.dll
Получается работники стоит на конвейере и выполняет одну операцию, далее деталь идет к следующему, который выполняет над ней другую операцию из технологической цепочки. Над ними стоит начальник цеха. А таких цехов несколько, а над ними еще подразделения и т.д. Как-то очень громоздка получается.
не придумывай лишнего чего там не написано тогда и не будет громоздко
тем более что аналогия не слишком удачная.
не понимаю про то, чего не написано
предложите свою
Представьте себе, что Ваш сайт это предприятие. Классы - это работники. И цех - один php-файл, допустим, init.php. В нем работают объекты классов, проходит весь "процесс" работы на более высоком уровне, а все глубинные процессы описаны в самих классах. Это очень удобно. Важно понимать, что класс это не набор функций и переменных, а будущая сущность, которая что-то умеет и обладает какими-то свойствами. Опять же, преимущества становятся очевидными, когда поработаешь над чем-то более-менее крупным. А если ещё и в команде, то сразу видно разницу.
Мэтт Зандстра рекомендует думать, как вы предлагаете, т.е. интерфейсами, одна сущность - одно действие, ну это в идеале. Получается работники стоит на конвейере и выполняет одну операцию, далее деталь идет к следующему, который выполняет над ней другую операцию из технологической цепочки. Над ними стоит начальник цеха. А таких цехов несколько, а над ними еще подразделения и т.д. Как-то очень громоздка получается.
Здравствуйте, armancho7777777. Я помню, тот же вопрос задавал здесь. Так ответы вроде Вашего жутко раздражали Это я сейчас понимаю, что ответ-то верный, а тогда казалось, что ООП это тайна покрытая мраком и никто ею делиться не хочет)
igosja, у меня в арсенале два мною недописанных движка. Первый кагбэ готов, но там говнокода много, он не расширяем толком, + ещё тысяча и один недостаток. А второй просто не дописал, т.к. пропала нужда и свободное время. Когда-нибудь обязательно второй допишу.
Так вот, к чему я это. Первый я начинал писАть в далекие времена, когда Е.Попов был для меня кем-то на уровне Бьёрна Страуструпа. Но главное, как я его начал писать...
Создал файл index.php в корне, в нем написал <?php и начал по мере поступления идей в мозг, их реализовывать. В итоге получил черт-ногу-сломит архитектуру с хрен-че-найди реализацией. Оно-то работает, но когда нужно что-то изменить/доделать/переделать - капец.
А ко второму я подошел серьезнее. Сначала я начал продумывать архитектуру приложения. Я нарисовал на бумаге, что и как у меня будет работать. Схема не из сложных: несколько блоков, соединенных линиями, каждый из которых за что-то отвечает. Один - за пользователей (авторизацию|регистрацию|бан и т.д.), другой - за текущую страницу, третий - за работу модулей, четвертый - за базу данных, и т.д.. Так вот когда есть такой "план", а он должен быть, если Вы собираетесь разрабатывать что-либо более-менее серьезное, то в данном случае как минимум удобно для каждого блока нашей схемы написать класс.
Представьте себе, что Ваш сайт это предприятие. Классы - это работники. И цех - один php-файл, допустим, init.php. В нем работают объекты классов, проходит весь "процесс" работы на более высоком уровне, а все глубинные процессы описаны в самих классах. Это очень удобно. Важно понимать, что класс это не набор функций и переменных, а будущая сущность, которая что-то умеет и обладает какими-то свойствами. Опять же, преимущества становятся очевидными, когда поработаешь над чем-то более-менее крупным. А если ещё и в команде, то сразу видно разницу.
И когда наступает момент, что без инкапсуляции, полиморфизма и наследования нет так уж и удобно, приходит прозрение
Сейчас прочитал слова, которые хорошо описывают преимущества ООП
habrahabr пишет:
Вкусив запретного плода расширенного синтаксиса, программисты не остановились и возжелали модульности: ведь это так удобно — вызывать отдельно написанный модуль программы и не вникать в его алгоритм. Главное — это знать как он принимает на вход данные и как возвращает результат.
]классная метафора в связи с ней есть ряд уточняющих вопросов, мы можем здесь их обсудить?
Наткнулся на такое мнение, что каптчи используют как это корректно выразить не совсем пряморукие программисты, она преследует повсеместно, ее ставят на все, что можно поставить.
Вопрос в следующем, а как реализовать защиту без нее?