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

Pavel666

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

 

Алекс8

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

 

don.bidon

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

 

mkramer

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

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

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

 

mkramer

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

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

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

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

 

Androbim

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

 

musicman3

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

 

mkramer

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

 

musicman3

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

 

mkramer

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

 

don.bidon

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

 

Дюран

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

 

Репозиторий

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

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

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

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

Совет:

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

 

musicman3

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

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

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

 

Репозиторий

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

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

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

 

mkramer

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

 

Репозиторий

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

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

 

mkramer

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

 

Evgenii_web

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

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

 

musicman3

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

 

Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *