Понимание или не понимание ООП.

Друзья всем привет.Такая делемма,по процедурному стилю вопросов нет,пишу то что задумал,понимаю что писать и где.подошел к изучению ООП и кроме как наследование дальше нифига не понимаю,для чего и как использовать ооп.пересмотрел кучу видосов,но и там ответа нет.как бы используется в крупных проектах.а на сколько крупныеи что на процедурном стиле нельзя что это сделать,не ясно.и все примеры ооп это по котов и машины.чистые абстракции.

 

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

 

Книжки читать не пробовали?

 

Агась. Потому что ООП и строится на абстракциях На самом деле, в большинстве проектов, где есть классы и т.п., ООП на самом деле нету, есть тот же процедурный стиль, просто процедуры в классы впихнуты. То же MVC — это ещё не ООП.

Мэтт Зандстра. «PHP. Объекты, шаблоны и методики программирования» — наверное лучшее, что можно прочитать для PHP по объектам.
— Добавлено —

Таких не бывает. На процедурном стиле ОС писали, не то, что сайтики Другое дело, будет ли это так же удобно, быстро с точки зрения разработки, читаемо и т.п.

 

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

Теперь заказчику нужно, чтоб каждой значение из формочки вырисовывалось поверх существующих PDF шаблонов. Чекбоксики и радиобатаны ставили крестик, где надо, инпуты писали текст, даты были в нужном поясе и правильно отформатированы. Для того, чтобы просто знать, где это будет, всё просто — сделали редактор, в котором мышкой можно указать координаты. А вот теперь это всё надо выводить по этим координатам. Но

• у каждого поля свой формат хранения значения (хотя есть общее поле, тип)
• у каждого поля свой формат вывода

Традиционное процедурное решение — это поставить какой-нибудь switch(), которые потом будет жутко разрастаться с увеличением количества ереси в формочках. А ОО решение — сделать иерархию классов для рендеринга, и фабрику, которая в зависимости от типа, будет создавать нужный. Причём, благодаря тому, что PHP умеет читать имена классов из строковых переменных, в моём всё так построено, что при появлении нового типа элемента формы я просто допишу новый рендерер, и больше ни строчки менять не придётся.

 

Из литературы, наверное, Мэтт Зандстра. Это фундаментально.
По паттернам хорошая книга — Погружение в паттерны проектирования (так и набирать в поисковике)
А насколько глубокое нужно понимание ООП?
Если пользоваться макрофреймворками типа Laravel, Yii2, Symfony, то достаточно просто начать почитывать, впараллель. Да может, с этого бы и стоило начать, прежде чем «погружаться»…
Но если нужно действительно понять, пожалуй, возможно, стоило бы начать работать с чем-нибудь вроде Slim 4, с понимания внедрения зависимостей.

 

Современный PHP позволяет использовать ООП не везде где попало, а только там где это к месту. Для этого и были введены статические методы и неймспейсы. Там где нужно наследование, конструкторы и т.п., там юзаем объекты, в остальных случаях удобнее статика через неймспейсы. Каждому инструменту свое место. Это современный подход который нужно также понимать.

 

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

 

Статика с неймспейсами прошу заметить. И ввели ее уже далеко после ООП на пыхе, как раз с версии 5.4 примерно и выше. Нужно просто подумать для чего и как ее применять, а не искать врага в статике.

 

В 5.3 появились неймспейсы. Ну у меня был опыт работы с самописным фреймворком полностью на статике. Заказ я сделал, но впечатления остались отрицательные. А когда я с нуля пишу, то не использую полностью статические классы, только DI, хоть, признаюсь, не совсем чистый DI — у меня не всегда зависимость на интерфейсы. То, что могло бы быть статическим классом — соответственно, в DI-контейнер идёт как singleton, что позволяет уже и туда внедрять зависимости, чего с полностью статическим классом сделать невозможно.
— Добавлено —
Скорость работы — у меня ни разу не было проблем со скоростью работы именно из-за того, что я объекты создаю. Обычно проблемы со скоростью из-за неудачных алгоритмов, медленных запросов к БД и т.п. А создание экземпляра сейчас достаточно дёшево по времени.

 

Статику тестировать PHPUnit’ом неудобно, однако.

 

Статика, как не крути, создает жесткую зависимость, что противоречит паттерну Low Coupling от grasp

 

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

btw, ООП нужно кодеру по как минимум двум причинам:

1. Удобно структурировать код, хотя бы даже и на элементарном уровне — методы для работы с почтой складываешь в один класс, а методы для работы с БД — в другой

2. Если ты не знаешь ООП — не сможешь участвовать в коммерческих разработках.

Совет:

— Начни изучать Laravel или Symfony — там постепенно лишние вопросы сами отпадут по ходу действия

 

Очень хорошо что Вы участвуете в дискуссии. Но хотел бы Вас совсем немного поправить.

ООП к компоновке методов в классы не имеет прямого отношения. ООП — это прежде всего работа с классами через Объект. Это наследование и инкапсуляция, и некоторые другие фичи.

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

 

да как бы если вы используете слово class в кодинге — значит это уже имеет отношение к ООП

сначала человек использует класс просто для инкапсуляции переменных и методов. ну а уже потом подтягивается все остальное.

это нормально.

 

Не-а. Можно понатыкать классов, а код всё равно процедурный будет

 

Ну можно конечно сказать и так, что без интерфейсов и DI — это не ООП

Но ведь это неправда будет ))

 

Почти так. Если нет ни одного абстрактного класса, не используется полиморфизм и прочие плюшки — код процедурный. И обратная сторона — ООП возможен вообще без классов, если есть функциональные типы (например, с помощью указателей на функции в С можно построить объектно-ориентированную программу, хотя там не будет слова class. Известный факт, что первые версии C++ компилировали код в C, а уже потом вызывали компилятор C для генерации машинного кода)

 

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

И вообще написать сайт любой сложности можно на процедурном коде, изучать ООП это еще сколько времени надо потратить.

 

PHP без PDO на хостингах я не видел уже лет 15. Он встроен как стандартный пакет в PHP.