Разное

Добрый день!
У меня есть пробел, касающийся ООП - использовать сторонние библиотеки с объектным интерфейсом я умею, технический арсенал, который есть у PHP, касающийся объектов знаю, а вот разрабатывать классовые иерархии не умею - не знаю с чего начать и куда идти.
Т.е. если бы стояла задача разработать библиотеку с объектным интерфейсом или что-то подобное, то я бы скорее всего не справился (запутался). Ну а если бы и справился, то получилось бы коряво.

Поэтому хотелось бы этот пробел заполнить и разложить всю теорию, касающуюся объектно-ориентированного проектирования по полочкам.


Логика подсказывает 3 пути заполнения этого пробела:

1. Проработать вот этот талмуд:
http://www.books.ru/shop/books/574379

2. Разобраться в каком-нибудь средней сложности фреймворке (например CodeIgniter), понять как он устроен, затем прозреть - понять принципы, которыми руководствовались его создатели и, затем при необходимости, использовать эти принципы при построении своего проекта.

3. Пойти комбинированнам путем - сначала талмуд, потом фреймворк.

Может быть есть какой-то другой путь, о котором я не знаю.

Как вы считаете, какой путь наиболее правильный?

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

Кроме того, поставьте цель. Что должен дать ООП-метод? Скорость разработки, удобство использования, меньшее количество ошибок, скорость выполнения кода? Все сразу удовлетворить практически невозможно, по сути все ООП-библиотеки преследуют несколько целей, за счет ослабления других. Этого и нужно добиваться. По сути любая ООП-разработка - это усиление одних преимуществ, за счет ослабления других. Как правило, жертвуют скоростью приложения, ради ускорения разработки, уменьшения количества ошибок, увеличения безопасности. Ошибка начинающих разработчиков, в том что они жертвуют всем, не получая никаких преимуществ. Причем даже не это ошибка, а то, что они выводы из этого не делают и не видят проигрыша. Когда вы будете видеть, что у вас украла разработанная вами система, где её следует применять пореже, а где почаще, вот тогда вы сможете проектировать иерархию заранее, а не методом последовательного приближения. Однако такие вещи только с опытом приходят. Берите и проектируйте, не бойтесь ошибаться. Если отладка - это процесс устранения ошибок, то программирование - их создание :)

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

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

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

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

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

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

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

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

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

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

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

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

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