Введение в ООП
| Шаг 1. Немного лирики | Шаг 3. Пространство имен | Шаг 5. Наследование | Шаг 7. Интерфейсы | Шаг 9. Автолоад |
| Шаг 2. Самое начало | Шаг 4. Инкапсуляция | Шаг 6. Полиморфизм | Шаг 8. Магические методы | Шаг 10. Обработка исключений |
Немного лирики
Хочу сразу предупредить – всё, что здесь написано, имеет статус ИМХО и ни в коем случае не является каким то постулатом.
Просто мои наблюдения и некоторые логические выкладки.
Так что же это такое – ООП и с чем его едят
Последнее время, с подачи работодателей стало считаться, что ООП это вершина девелопинга. То есть если ты владеешь навыками Объектного программирования – ты гуру, достиг небывалых высот и можешь делать сайты любой сложности. Вот тут как раз и зарыта собака.
Совершенно непонятно зачем делать сайт огромной сложности, если все тоже самое можно сделать на порядок проще…
Было бы любопытно, если для прокладки простого водопровода приглашали бы исключительно профессоров по гидродинамике. И они, вместо того, что бы прокладывать трубы, изучали ламинарные течения и поведение жидкости в нетурбулентном режиме. В результате мы имели бы не водопровод, каким привыкли его видеть, а двухжидкостную нерелятивистскую модель со сверхсложной системой перепускных клапанов, фильтров и защит от гидродинамических ударов. Со всеми вытекающими последствиями – дороговизной обслуживания, сложностью в ремонте, да и чего греха таить – полным отсутствием экономии самой воды.
Что мы собственно и наблюдаем последнее время. Программы неоправданно усложняются, растут в объёме и стоимости. Даже термин придумали – индусский код. То есть чем больше и сложнее программа, тем больше она стоит. А заказчик откуда может знать, что тоже самое можно сделать тремя строчками.
Давайте попробуем разобраться, что же это такое ООП, для чего придумано и как применяется с этой точки зрения.
Сначала небольшой экскурс.
PHP изначально создавался (и концепция его практически не изменилась) исключительно для веб приложений. И хотя он может работать из командной строки, сути это не меняет.
А раз он планировался для веб-приложений, то и структура его такова, что на нем легко писать наборы маленьких программ – страничек если хотите, и довольно сложно написать одну огромную програмищщщу. Почему так.
Самый большой затык – область видимости. У PHP одна глобальная область видимости, и если на одном конце программы объявлена переменная или функция, а на другом сделать тоже самое – получится конфликт. Это может нарушить логику программы. Особенно это сильно заметно, если разработчиков несколько.
Но. Эта опасность подстерегает девелоперов, если они пишут единую, цельную программу на несколько метров, а то и гектаров)))
А веб-приложение в идеале это не одна цельная программа, а много маленьких, вызываемых в нужное время. Откуда же появилась мода писать монстров?
Это все от лени и жажды наживы желания сделать программирование еще проще (казалось бы – куда еще то). То есть упростить существующий язык. И началось повальное изобретение фреймворков.
А что в итоге? Фреймворк, это по сути своей такой же язык программирования, который теперь выступает посредником между разработчиком и PHP. А значит он обязан быть цельным и неделимым, раз это язык. То есть мы должны иметь возможность в любое время вызвать любую команду, которую способен выполнить фреймворк.
И вот тут как раз и появляется первая грабля: область видимости. Что бы создать большую программу, нужно быть уверенным, что ничего ни где не конфликтует. Лучше всего поделить её на самостоятельные блоки. Но тогда пропадает возможность сделать сам фреймворк – он же должен быть неделимым.
Выход был найден – старое доброе Объектное Программирование. Разделяй программу на классы, организовывай нужные взаимодействия и все в шоколаде – ни кто никому не мешает. Однако за что боролись, на то и напоролись. Хотели облегчить жизнь – на самом деле жутко все усложнили. Теперь требуется изучать уже не просто язык программирования, а еще и отдельное направление в нем, а потом и язык фреймворка. Но изучить – пол беды, дело наживное. Главный подвох в управляемости и прозрачности кода. А тут полный абзац. Да и экономичным такой подход не назвать – ZEND фреймворк к примеру весит больше 5 метров и грузится практически весь. Даже если нужно всего навсего написать “Привет, Мир!”
Одно дело – прикладное программирование. Вы запускаете программу (тот же допустим редактор), она загружается в оперативку и работает, пока не будет нажата кнопка “Выход”. Это называется – процесс. Тут ясен перец – нужно грузить все целиком, что бы не ждать подгрузки разных частей в процессе исполнения.
Другое дело веб. Программа (скрипт) работает короткое время, только чтобы сформировать страницу. Но таких процессов очень много – по числу пользователей. И чем больше программа, тем больше нужно оперативки для работы сайта. Попробуйте открыть одновременно 100 редакторов в своем компьютере… И если каждый занимает 300 mB, то оперативки потребуется 30000 mB. что не каждый компьютер потянет.
На мой взгляд ООП трудно найти оправданное место в веб-программировании. Я имею ввиду парадигму, а не сами классы. Классы – вещь крайне удобная и полезная. А вот построение логики объектов, да еще и с прицелом на всеобъемлимость – горе от ума.
Особенно в части фреймворков. Вот представьте задачу – изготовить мобильный телефон с встроенной камерой. Если это реализовать с помощью фреймворка, то выйдет примерно это:
Мало того, что огромно, так еще и сложно в применении. Но зато все может…