PHP. ООП. Сухие примеры с книг, а применять на проектах не получается, как быть?
Начал изучать объектно ориентированный стиль в PHP, с процедурного уже хочется уйти, просто из за "бардака" который там происходит.> который там происходит.
Обучение происходит в большую часть по книжке, знаю, большинство просто говорят "Скачай движок на PHP, начни разбирать, так все легче дастся". Не получается, слишком уж эти движки навороченные, да есть места где я понимаю, ну если все вывести на общую картину, то нечего не получается.
Читаю, книжку, читаю.. я сам удивлен, ясностью этой ООП. Все сразу становиться понятно, сразу видно сильны стороны такого стиля, даже работать над таким кодом, приятно. Ну вот сама проблема, не знаю я как это все в проектах применять, сухие примеры, не больше, не получается все собрать в одну большую кучу, что бы механизм наконец то стал работать.
P.S. Книжку еще до конца не дочитал, сейчас остановился на шаблоне Composite.
Как вообще эти шаблоны применять?
Понимаю, каждый шаблон, своя организация, свои слабые и сильные стороны, ну на сайт, как все "натянуть" то?
Помогите, хочется какого то результата увидеть со своей работы, а не сухие примеры с книг.
Скачай хороший фреймворк (рекомендую Symfony) и начни на нем что нибудь делать - хотя бы простое - список todo для себя.
там у тебя не получится писать процедурно - со временем на практике так и поймешь для чего все это.
а так бывает люди пишут классами (static методами или singleton (ну ладно singleton, еще более менее)) и думают что это уже ООП
и второе - писать шаблоны ради шаблонов - это отстой.
шаблоны надо исопльзовать для каких то целей. обычно важной предпосылкой их использования является гибкость проекта и реиспользование модулей.
еще один варинат если не хочешь с фреймворками и cms возится - попробуй напиши свой универсальный модуль коотрый другие люди могли бы реиспользовать.
могу дать пример задачи.
продолжая тему todo - напиши модуль который работал бы со списками туду и мог хранить их в разных хранилищах - локальных файлах, БД, сохранять через апи на какой нибудь сервис (то есть я сам могу написать сохранялку).
то есть я скачиваю твою библиотеку и пишу такой код
$todoStore = new TodoStoreMysql('localhost', 'mysql', 'pass');
$todoStore->setTable('todo_list_table');
$list = new TodoList($todoStore);
$id = $list->add('новое задание');
$list->getItems();
либо я мог бы захотеть хранить список в файлах
$todoStore = new TodoStoreJsonFile('todo.json');
$list = new TodoList($todoStore);
$id = $list->add('новое задание');
$list->delete(4);
попробуй разобраться в преимуществах такого подхода.
либо напишу свою обертку хранилища TodoStoreEvernoute например.
попробуй сделать библиотеку под такие требования.
да, "список дел". простой CRUD - т.е. туда можно добавлять задачи/ смотреть список / и удалять + не помешает редакирование.
зы участник выше это тоже я )
riky: Можно с вами как то позже связаться? Я попытаюсь сделать. ну почему то заранее уверен что там у меня будет куча ошибок, и хотелось бы иметь некого человека, который может исправить ошибки, ну и подсказать где надо.
Я столкнулся с такой же проблемой при изучении ООП (который в данный момент всё ещё изучаю). Пока читал книгу, мало представлял, как применять эти знания на практике. Но ответ нашёлся.
В начале изучения PHP, для практики я начал делать собственный проект, который мне был интересен, но как оказалось в будущем, он не такой простой, как ожидалось. Начал естественно в процедурном стиле, не знал ничего о разделении логики и вывода, всё было написано вперемешку. Потом узнал про разделение кода и разделил его. Но не просто разделил, а перед этим столкнулся с проблемами, вызванными неразделённым кодом.
Так вот проект растёт, и набралась уже куча проблем на архитектурном уровне, которые я не могу решить процедурным стилем. Начал видеть некоторые проблемы и понимать их суть. И вот когда понял суть проблемы, начали вспоминаться шаблоны и приёмы, о которых я читал в книге по ООП. Начал сталкиваться с повторением кода, тесными связями (там, где их видел), и в этих местах применял знания из книги, для устранения выявленных проблем.
Мой совет: делайте свой сложный проект, как умеете, и по мере роста проекта, неизбежно начнут возникать проблемы, требующие ООП подхода. Вот тогда информация из книг станет применима к практике. Вы будете решать реальные проблемы в своём проекте при помощи знаний полученных из книги. Причём это будет интересно и доставит удовольствие.
ЗЫЖ: Так же многие советуют использовать фреймворки. Пока я решил этого не делать именно для того чтобы понять - как и для чего применять ООП. Я считаю, что фреймворки это уже следующий шаг, во всяком случае, для такого самоучки как я. Возможно для человека с соответствующей базой это именно то, что нужно.
с процедурного уже хочется уйти, просто из за "бардака" который там происходит.
PHP сам по себе язык бардачный. Если бы Вы попробовали Java, то она не идет ни в какое сравнение с ОО в PHP, Вы бы восхитились куда больше )
Мой Вам совет один - начните читать Фаулера и Гради Буча. Второй - чисто ОО-теория, первый - реальные архитектурные решения.
У Фаулера читайте внимательно ту часть, где описаны доменные объекты и те решения, что затрагивают ОО-программирование и СУБД. Меня эта книга вывела на новый уровень, хотя перечитывать придется не раз - не все так просто.
Дело в том, что ООП в PHP по сути бесполезен, если не представлять записи из БД как объекты. А это очень нетривиальная задача. Прочтите все в книге, что качается темы ORM - Data Mapper, Active Record и про шлюзы записи данных почитайте. Не транслируя модели предметной области из СУБД в объекты, ОО в ваших программах по факту не будет.
OnYourLips: в Java все является объектом. Этого достаточно, что бы говорить о Java как об идеальном ОО языке.
> А это уже откровенная глупость.
В чем глупость? Товар в магазине, пользователь, пост в форуме - это все можно и нужно представить в видео объектов. Так ПРАВИЛЬНО, если мы заявляем, что пишем ОО-код. Если приложение на PHP не имеет возможности представлять сущности моделей данных в виде объектов - тогда это не ОО-приложение, а просто "мы используем классы".
В ≈90% веб-работ ООП либо вообще не нужно, либо используется какой-то чужой объект как чёрный ящик. В чём дело? А в том, что сессия PHP недолговечна. Отдал пользователю страничку — и кирдык. А всё, что нужно припрятать до новой встречи, рассовываешь по кукам, сессиям и БД.
Я бы посоветовал: а) экспериментировать с чем угодно другим, кроме веба; б) если есть возможность, писать в более-менее объектном стиле на JavaScript.
P.S. И вторая причина — почти всё, что нужно вебисту, уже кем-то написано, остаётся только собрать всё это в единый сайт. И третий совет: где в серверном вебе легко найти применение ООП, так это в поддержке сложных форматов (вики-разметка, например) и сложных протоколов.
> В ≈90% веб-работ ООП либо вообще не нужно
Глупость.
Вообще не имеет значения, для чего программа, для десткопа или для веба. ООП всегда дает преимущество. Надо лишь уметь его использовать.
Конечно, даже мне приходилось писать «абстрактный адаптер» или что-то подобное.
Но из-за того, что каждый вызов PHP — это только срез данных на момент t, огромная куча ООП-шаблонов отпадает.
Фундамент дома - фундамент дома это абстрактный класс, в нем создаются абстрактные методы и не, которые я буду использовать в своём доме.
Закладываю коммуникации, водопровод, канализацию и так далее, всеми этими вещами я буду пользоваться в потомках (потомки это будущий дом и комнаты дома).
Дом - как уже говорилось выше, коммуникации мы заложили. Строим дом. Дом будет в три этажа. Дом это один класс, он наследует методы фундамента, теперь в доме есть вода и канализация и прочие фундаментальные коммуникации.
Этаж 1 - наследует класс Дом на первом этаже уже есть вода (мы закладывали её в фундаменте).
Этаж 2 - наследует класс Дом
Этаж 3 - наследует класс Дом
Комната 1 этаж 1 - наследует Этаж 1 у меня в комнате есть вода и канализации я же закладывал ее в фундаментальном классе.
Извините, ну я вот именно не знаю как этот мелкий проект сделать, точнее знаю, создавать различные классы, а потом объектами все на деле использовать.
Ну мне что то подсказывает, что я смотрю совсем в другую сторону, если все сделать так как я написал выше, то от процедурного я вновь далеко не пойду, у меня в этом 'мелком проекте' будет сплошной мусор.
Просто вот хочется, какой то маленький толчок в правильную сторону, а дальше я уже попытаюсь сам разобраться)
olexandr7: Может вы не поверите, но именно это книжка сейчас лежит у меня на столе, и именно его я читаю по сей день, прочитал 150 стр. остановился на шаблонах.(208стр).
Ну ведь на этих 150 стр. нечего такого что бы можно было начать мелкий проект. по крайней мере для меня. Там просто теория, наследование, инкапсуляция, и многое другое. и самые обычные примеры. Хотя пример с Интернет Магазином был очень понятен)
Ну даже с такими знаниями, я не могу не как набраться смелости и приступить к создание, даже "простого проекта".
goodMenik1: забудьте про шаблоны пока не поймете суть ООП. Я вижу что вы только читаете и ничерта не практикуетесь. Вперед писать что то, хоть на пару классов, блеать!
Средний
