PHP. ООП. Сухие примеры с книг, а применять на проектах не получается, как быть?

Начал изучать объектно ориентированный стиль в PHP, с процедурного уже хочется уйти, просто из за "бардака" который там происходит.> который там происходит.
Обучение происходит в большую часть по книжке, знаю, большинство просто говорят "Скачай движок на PHP, начни разбирать, так все легче дастся". Не получается, слишком уж эти движки навороченные, да есть места где я понимаю, ну если все вывести на общую картину, то нечего не получается.
Читаю, книжку, читаю.. я сам удивлен, ясностью этой ООП. Все сразу становиться понятно, сразу видно сильны стороны такого стиля, даже работать над таким кодом, приятно. Ну вот сама проблема, не знаю я как это все в проектах применять, сухие примеры, не больше, не получается все собрать в одну большую кучу, что бы механизм наконец то стал работать.
P.S. Книжку еще до конца не дочитал, сейчас остановился на шаблоне Composite.
Как вообще эти шаблоны применять?
Понимаю, каждый шаблон, своя организация, свои слабые и сильные стороны, ну на сайт, как все "натянуть" то?
Помогите, хочется какого то результата увидеть со своей работы, а не сухие примеры с книг.
  • Вопрос задан
  • 9809 просмотров
Решения вопроса 2
riky
@riky
Laravel
Скачай хороший фреймворк (рекомендую Symfony) и начни на нем что нибудь делать - хотя бы простое - список todo для себя.
там у тебя не получится писать процедурно - со временем на практике так и поймешь для чего все это.

а так бывает люди пишут классами (static методами или singleton (ну ладно singleton, еще более менее)) и думают что это уже ООП
Ответ написан
dm84ya08
@dm84ya08
Самоучка
Я столкнулся с такой же проблемой при изучении ООП (который в данный момент всё ещё изучаю). Пока читал книгу, мало представлял, как применять эти знания на практике. Но ответ нашёлся.

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

Так вот проект растёт, и набралась уже куча проблем на архитектурном уровне, которые я не могу решить процедурным стилем. Начал видеть некоторые проблемы и понимать их суть. И вот когда понял суть проблемы, начали вспоминаться шаблоны и приёмы, о которых я читал в книге по ООП. Начал сталкиваться с повторением кода, тесными связями (там, где их видел), и в этих местах применял знания из книги, для устранения выявленных проблем.

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

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

ЗЗЫЖ: Книгу по ООП читал ту же что и вы.
Ответ написан
Комментировать
Пригласить эксперта
Ответы на вопрос 6
trevoga_su
@trevoga_su
с процедурного уже хочется уйти, просто из за "бардака" который там происходит.
PHP сам по себе язык бардачный. Если бы Вы попробовали Java, то она не идет ни в какое сравнение с ОО в PHP, Вы бы восхитились куда больше )

Мой Вам совет один - начните читать Фаулера и Гради Буча. Второй - чисто ОО-теория, первый - реальные архитектурные решения.

У Фаулера читайте внимательно ту часть, где описаны доменные объекты и те решения, что затрагивают ОО-программирование и СУБД. Меня эта книга вывела на новый уровень, хотя перечитывать придется не раз - не все так просто.

Дело в том, что ООП в PHP по сути бесполезен, если не представлять записи из БД как объекты. А это очень нетривиальная задача. Прочтите все в книге, что качается темы ORM - Data Mapper, Active Record и про шлюзы записи данных почитайте. Не транслируя модели предметной области из СУБД в объекты, ОО в ваших программах по факту не будет.
Ответ написан
@Mercury13
Программист на «си с крестами» и не только
В ≈90% веб-работ ООП либо вообще не нужно, либо используется какой-то чужой объект как чёрный ящик. В чём дело? А в том, что сессия PHP недолговечна. Отдал пользователю страничку — и кирдык. А всё, что нужно припрятать до новой встречи, рассовываешь по кукам, сессиям и БД.

Я бы посоветовал: а) экспериментировать с чем угодно другим, кроме веба; б) если есть возможность, писать в более-менее объектном стиле на JavaScript.

P.S. И вторая причина — почти всё, что нужно вебисту, уже кем-то написано, остаётся только собрать всё это в единый сайт. И третий совет: где в серверном вебе легко найти применение ООП, так это в поддержке сложных форматов (вики-разметка, например) и сложных протоколов.
Ответ написан
@igorpopryduhin
5c0640e53ed75188503117.jpeg

Что касается ООП, как я обычно это делаю.

Моделирую как конструктор.
Например:

Фундамент дома - фундамент дома это абстрактный класс, в нем создаются абстрактные методы и не, которые я буду использовать в своём доме.
Закладываю коммуникации, водопровод, канализацию и так далее, всеми этими вещами я буду пользоваться в потомках (потомки это будущий дом и комнаты дома).

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

Этаж 1 - наследует класс Дом на первом этаже уже есть вода (мы закладывали её в фундаменте).

Этаж 2 - наследует класс Дом

Этаж 3 - наследует класс Дом

Комната 1 этаж 1 - наследует Этаж 1 у меня в комнате есть вода и канализации я же закладывал ее в фундаментальном классе.

И всё в таком же духе!!!

Не забываем про https://ru.wikipedia.org/wiki/Инкапсуляция_(програ...
Ответ написан
Комментировать
@olexandr7
Пиши свой какой то самый мелкий проект и там практикуй знания. П.С. певратить код в УГ можно и с использованием ООП, личный пример.
Ответ написан
He11ion
@He11ion
PHP-monkey
Автор, ООП =/= паттернам(шаблонам) проектирования. Учите именно ООП и старайтесь его применять на практике, только практика дает нужные умения.

А паттерны просто имейте в виду, потом понимание где и как их использовать
Ответ написан
Комментировать
@2vtlk
Если писать на symfony или laravel, то таких проблем не будет. 3NVMnB
Ответ написан
Комментировать
Ваш ответ на вопрос

Войдите, чтобы написать ответ

Войти через центр авторизации
Похожие вопросы
19 апр. 2024, в 23:00
5000 руб./за проект
19 апр. 2024, в 20:43
20000 руб./за проект