Разное

http://www.apasov.com/php/schtirlitz_und_muller.html :)))

Так же можно открыть книгу C++ Страуструпа.. Прочитать про ООП...
Вот небольшие термины, которые ты ДОЛЖЕН знать:
1)Что такое класс
2)Объект
3)Суть ООП
4)Инкапсуляция (по сути один из _главных_ составных ООП; зачем она нужна?)
5)Абстракция (как она применяется, где, для чего, почему она нужна?)
6)статические поля, и пр. модификаторы(public,private,static,protected)..
7) Конструкторы, деструкторы..
8)Интерфейсы, абстрактные классы
9)Полиморфизм..(как он достигается?)

Понятно. Спасибо!

Как правило, пользоваться чужой, даже не пользоваться, а расширять её, дописывая классы-потомки.

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

Когда смотришь вакансии web-программистов, то во многих из них к соискателю предявляются такие требования:
- Знание PHP5, владение ООП.
Обычно под этим что подразумевается? То что нужно будет разрабатывать свою систему или то, что нужно будет научиться пользоваться чужой?

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

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

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

[поправлено модератором]

Вот тезка кстати )))

мне кажется нужно вникнуть для начала что такое инкапсуляция, наследование и полиморфизм, и определиться нужны ли эти концепции в разрабатываемом проекте, а дальше уже осваивать методы языка

Вот оно как значит..... Последую Вашему совету, буду постигать ООП на практике.
Спасибо!