Форум PHP

Почему многие разработкичи, типа разработчики известных скриптов или движков пишут на классах, а не простым способом. Почему они выбирают именно этот метод?

По большому счету причины две:
1) Повторное использование, вы можете унаследовать свою систему классов не только от конечных классов, но и тех, что находятся в середине иерархии. Т.е. не с нуля разрабатывать, не таскать коди и отлаживать в новом проекте. А взять и свернуть на новую ветку разработки с середины уже существующего проекта ничего не меняя в старом проекте и не разрабатывая половину нового.
2) Свой язык программирования - ООП создавался для того, чтобы вводить свои понятия на более абстрактном уровне, языке задач. Предметный язык - это великая сила, но разрабатывать полноценный язык - это сложная задача.

пункт 1) - не очень понял

почему так подробно спрашиваю - потому что не могу вникнуть и понять полноценно все прелести использования ООП

>почему так подробно спрашиваю - потому что не могу вникнуть и понять полноценно все
>прелести использования ООП
Большой проект нужен и опыт... на небольшом проекте ООП просто не удастся в полную силу использовать.

Разрабатываете вы допустим интернет-магазин, вводите понятия-классы пользователя, товара, от которого наследуете десяток самых разных классов, договора, выстраиваете на этих классах систему. Поступает задача разработать сайт регистратора доменных имен - вы уже не разрабатываете классы пользователя, договора, вы их берете и наследуете от готовых новые классы и вносите небольшие усовершенствованиями (если они требуются). Когда у вас система маленькая кажется чего проще просто разработать с нуля или взять и адаптировать код из прокта. Когда системы большие и на ту и на другую операцию может уйти изрядно времени и привнести в проект ошибки. Когда вы берете отлаженные классы - вам ничего не нужно делать, просто унаследовать от них свои. Повторю еще раз ООП - выгоден на крупных проектах, при обязательном наследовании или использовании классов в нескольких пректах. Иначе - это просто дополнительный код и время.

спасибо. Теперь же становится яснее на твоем примере.

"Классы — это контейнеры для функций и переменных, аналог пространства имён" — когда-то я думал так. Долго не мог понять смысла ООП. Все прелести ООП раскрываются на другом уровне абстракции. А это приходит с опытом. Кодируйте в ООП, изучайте чужие проекты, заставляйте себя заниматься этим и понимание прийдёт само. Мне помог именно такой подход, а не тот, который был описан в самоучителе Симдянова и Кузнецова. Так же попробуйте изучить какой-нибудь чисто объектный язык, например java или c#.

В рамках самоучителя, да и не самоучителя тоже, передать опыт разработки сложно, а ООП без 3-4 проектов за спиной - плохо идет.

Это верно. Но сравнение ООП со столами и метизами не только не вносит ясности, но ещё более запутывает. Только после познания ООП становится очевидной эта аллегория.

Еще форматы книг бывает диктует содержимое, т.е. если вы пишите Самоучитель или любую другую последовательную книгу по языку - вы должны коснуться всех конструкций языка, даже если некоторые конструкции довольно тяжело рассматривать в рамках главы. А так да, ООП - это архитектурный инструмент тяжелых и крупных проектов. Без опыта разработки таких проектов, даже хорошо понимающий принципы ООП разработчик делает массу ошибок и ляпов, так как даже понимать и знать концепции ООП не достаточно, чтобы разрабатывать хорошие ООП-схемы, а не клубок перепутанных классов, который не удобен ни разработчику, ни машине.

мда... после последних двух сообщений аж страшно браться за ООП )

Не бойтесь, мы вам поможем :)

Важно не гипнотизироваться идеалом, во-первых его нет, во-вторых без плохих проектов, хороший построить не удастся... здесь дело даже не опыте, зачастую и опытные разработчики создают прототип или полноценную рабочую систему, только для того, чтобы посмотреть на неё, как ужасно она спроектирована и выкинуть. После чего уже проектируют четкую и красивую систему. Причем этот прототип запланирован по времени и бюджету.

Знаете как раньше химические заводы строили? Компьютеров нет, жидкости разных вязкостей, кипения, взрывоопасности, а нужно не просто завод построить, но и с максимальной эффективностью... Считать все эти уравнения Новье-Стокса было не реально... строили небольшой завод, смотрели как он работает, подставляли реальные значения в модель завода и на основании этого проектировали завод побольше, повторяли операцию (иногда модель усложняли) и так до тех пор, пока завод не будет построен... Тут тоже самое, со временем вам будет требоваться все меньше и меньше заводов... сейчас, например, в химической промышленности так не делают - научились проектировать без промежуточных стадий.

Поэтому не бойтесь создавать плохие ООП-проекты, иначе как вы научитесь делать хорошие?

инкапсуляция-наследование-полиморфизм