Друзья всем привет.Такая делемма,по процедурному стилю вопросов нет,пишу то что задумал,понимаю что писать и где.подошел к изучению ООП и кроме как наследование дальше нифига не понимаю,для чего и как использовать ооп.пересмотрел кучу видосов,но и там ответа нет.как бы используется в крупных проектах.а на сколько крупныеи что на процедурном стиле нельзя что это сделать,не ясно.и все примеры ооп это по котов и машины.чистые абстракции.
у меня такая же фигня была)) я начинал с cms разных) а там все в функциональном стиле) в целом то на котов и на машин не зацикливайся.. они нифига не помогают)) попробуй сделать свой MVC фреймворк с ООП подходом)) по ходу изобретешь несколько паттернов и придет понимание нафига это ООП вообще надо))
Агась. Потому что ООП и строится на абстракциях На самом деле, в большинстве проектов, где есть классы и т.п., ООП на самом деле нету, есть тот же процедурный стиль, просто процедуры в классы впихнуты. То же MVC - это ещё не ООП. Мэтт Зандстра. "PHP. Объекты, шаблоны и методики программирования" - наверное лучшее, что можно прочитать для PHP по объектам. --- Добавлено --- Таких не бывает. На процедурном стиле ОС писали, не то, что сайтики Другое дело, будет ли это так же удобно, быстро с точки зрения разработки, читаемо и т.п.
Вот пример задачи, реальной, которую удобно решать с помощью ООП. Есть в системе возможность создавать произвольные формы, эти формы создаются, потом наполняются, потом лежат в базе. В формах бывают чекбоксики, радиобатаны, инпуты и прочая ересь. Теперь заказчику нужно, чтоб каждой значение из формочки вырисовывалось поверх существующих PDF шаблонов. Чекбоксики и радиобатаны ставили крестик, где надо, инпуты писали текст, даты были в нужном поясе и правильно отформатированы. Для того, чтобы просто знать, где это будет, всё просто - сделали редактор, в котором мышкой можно указать координаты. А вот теперь это всё надо выводить по этим координатам. Но у каждого поля свой формат хранения значения (хотя есть общее поле, тип) у каждого поля свой формат вывода Традиционное процедурное решение - это поставить какой-нибудь switch(), которые потом будет жутко разрастаться с увеличением количества ереси в формочках. А ОО решение - сделать иерархию классов для рендеринга, и фабрику, которая в зависимости от типа, будет создавать нужный. Причём, благодаря тому, что PHP умеет читать имена классов из строковых переменных, в моём всё так построено, что при появлении нового типа элемента формы я просто допишу новый рендерер, и больше ни строчки менять не придётся.
Из литературы, наверное, Мэтт Зандстра. Это фундаментально. По паттернам хорошая книга - Погружение в паттерны проектирования (так и набирать в поисковике) А насколько глубокое нужно понимание ООП? Если пользоваться макрофреймворками типа Laravel, Yii2, Symfony, то достаточно просто начать почитывать, впараллель. Да может, с этого бы и стоило начать, прежде чем "погружаться"... Но если нужно действительно понять, пожалуй, возможно, стоило бы начать работать с чем-нибудь вроде Slim 4, с понимания внедрения зависимостей.
Современный PHP позволяет использовать ООП не везде где попало, а только там где это к месту. Для этого и были введены статические методы и неймспейсы. Там где нужно наследование, конструкторы и т.п., там юзаем объекты, в остальных случаях удобнее статика через неймспейсы. Каждому инструменту свое место. Это современный подход который нужно также понимать.
Почти не использую статику. Это же вырождение ООП в процедурный подход --- Добавлено --- Статические методы не были введены для того, чтоб делать классы только из них. Они были введены для того, чтоб можно было реализовать некоторые операции, которые не касаются конкретного экземпляра класса. А так в основном должны быть вызовы экземпляров
Статика с неймспейсами прошу заметить. И ввели ее уже далеко после ООП на пыхе, как раз с версии 5.4 примерно и выше. Нужно просто подумать для чего и как ее применять, а не искать врага в статике.
В 5.3 появились неймспейсы. Ну у меня был опыт работы с самописным фреймворком полностью на статике. Заказ я сделал, но впечатления остались отрицательные. А когда я с нуля пишу, то не использую полностью статические классы, только DI, хоть, признаюсь, не совсем чистый DI - у меня не всегда зависимость на интерфейсы. То, что могло бы быть статическим классом - соответственно, в DI-контейнер идёт как singleton, что позволяет уже и туда внедрять зависимости, чего с полностью статическим классом сделать невозможно. --- Добавлено --- Скорость работы - у меня ни разу не было проблем со скоростью работы именно из-за того, что я объекты создаю. Обычно проблемы со скоростью из-за неудачных алгоритмов, медленных запросов к БД и т.п. А создание экземпляра сейчас достаточно дёшево по времени.
Вот кстати да, в этом проблема обучалок написанных школьниками они оторваны от жизни и по ним непонятно зачем оно вообще всё нужно. btw, ООП нужно кодеру по как минимум двум причинам: 1. Удобно структурировать код, хотя бы даже и на элементарном уровне - методы для работы с почтой складываешь в один класс, а методы для работы с БД - в другой 2. Если ты не знаешь ООП - не сможешь участвовать в коммерческих разработках. Совет: - Начни изучать Laravel или Symfony - там постепенно лишние вопросы сами отпадут по ходу действия
Очень хорошо что Вы участвуете в дискуссии. Но хотел бы Вас совсем немного поправить. ООП к компоновке методов в классы не имеет прямого отношения. ООП - это прежде всего работа с классами через Объект. Это наследование и инкапсуляция, и некоторые другие фичи. Но классы - это часть ООП. И безусловно это первый шаг к хорошему коду и ООП. Кроме того и статические классы (без создания объекта) также являются частью ООП-структуры, но применяются для этих целей немного в ином контексте. Вообще ООП это довольно размазанное определение. Самое важное что Вы начали этот путь, и Вам это интересно.
да как бы если вы используете слово class в кодинге - значит это уже имеет отношение к ООП сначала человек использует класс просто для инкапсуляции переменных и методов. ну а уже потом подтягивается все остальное. это нормально.
Почти так. Если нет ни одного абстрактного класса, не используется полиморфизм и прочие плюшки - код процедурный. И обратная сторона - ООП возможен вообще без классов, если есть функциональные типы (например, с помощью указателей на функции в С можно построить объектно-ориентированную программу, хотя там не будет слова class. Известный факт, что первые версии C++ компилировали код в C, а уже потом вызывали компилятор C для генерации машинного кода)
для себя процедурного кода хватит и функций с инклудом, если в фирму идти работать там все на ООП) Если искать нужный код, то он будет на ООП, как не крути учить ООП придется. Интересно если у меня подключение к базе данных через процедурный код, то могу ли я писать далее на ООП? Не думаю что все хостинги будут поддерживать пакет PDO И вообще написать сайт любой сложности можно на процедурном коде, изучать ООП это еще сколько времени надо потратить.