Ответы пользователя по тегу ООП
  • Может кто-нибудь дать реальную задачу на которой можно применить ООП?

    Fockker
    @Fockker
    Потомок старинного рода Ипатьевых-Колотитьевых
    Это хороший вопрос, но однозначного ответа на него нет.

    Во-первых, надо понимать, что писать свои классы и использовать готовые - это две очень большие разницы.
    От современного программиста чаще всего требуется второе. И это не требует особого понимания ООП.

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

    В-третьих, все реальные примеры настолько замороченные, что по ним разобраться совершенно нереально. А упрощенные ничего толком не показывают. Только синтаксис.

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

    Это пример самой базовой и очень распространенной задачи - как сделать работу с SQL менее занудной и гарантированно безопасной. И начинать надо именно с таких задач, не замахиваясь на приложения целиком.

    Если говорить о приложении целиком, то стоит попробовать написать что-то примере фреймворка Symfony - это как раз даст понимание того, как ООП применяется на уровне приложения.
    Ответ написан
  • Есть ли смысл реализовывать интерфейс абстрактным классом?

    Fockker
    @Fockker
    Потомок старинного рода Ипатьевых-Колотитьевых
    Я это понимаю так:
    Интерфейс - это публичный контракт. Информация для посторонних, для тех кто будет с классом взаимодействовать.
    Абстрактный класс - это внутренняя кухня, прототип для реализации.
    То есть одно другому никак не противоречит. Даже если абстрактный класс и интерфейс будут сильно похожи.
    Ответ написан
    Комментировать
  • Как кастомизировать ексепшены в общем методе?

    Fockker
    @Fockker Куратор тега PHP
    Потомок старинного рода Ипатьевых-Колотитьевых
    Первый вариант - это однозначно глупость. Какое-то совсем уже натягивание процедурного подхода на ООП.
    Второй какой-то невнятный, про него ничего нельзя сказать толком.

    В общем случае, как правильно написал sl0 в комментарии, кидать надо ОДИН тип исключения, но с разными сообщениями.

    В данном конкретном случае, поскольку речь идёт о валидации, то никакое исключение в принципе кидаться не должно. Исключение кидается в случае, если функция не может выполнить свою работу. Но для функции checkParam() невалидный параметр НЕ ЯВЛЯЕТСЯ исключительной ситуацией. Потому что роль этой функции - как раз и определить валидность переданного параметра. В случае неверных данных функция должна записать сообщение об ошибке во внутренний массив ошибок класса-валидатора и вернуть false.
    spoiler

    Исключение в случае неверных параметров может кидать например функция сохранения в БД. Потому что её задача - сохранить переданные данные, а не валидировать их. И в случае, если функция не может сохранить данные - она должна кинуть исключение, в том числе из-за невалидности данных.
    Ответ написан
    9 комментариев
  • Какие основные понятия в ООП?

    Fockker
    @Fockker
    Потомок старинного рода Ипатьевых-Колотитьевых
    • Инкапсуляция - это самое простое. В объекте лежат данные и методы для работы с ними (причём данными могут быть и другие объекты. см. Композиция). Самое главное в инкапсуляции - не переборщить. Инкапсулировать только то, что относится одной конкретной задаче. Всё остальное делегировать другим объектам (см. Композиция).
    • Наследование - это тоже самое простое и самое опасное. Захотел добавить новый функционал к уже существующему классу - унаследовался, дописал методик - и в путь! А потом исходный класс поменяли, и он стал ломать поведение унаследованного. Лучше всего взять себе за правило наследоваться только от абстрактных классов. А поведение менять с помощью свойств-объектов других классов (см. Композиция).
    • Полиморфизм. Один метод - поведение разное. Проще всего достигается за счёт использования свойств-объектов других классов (см. Композиция).
    • Композиция - это самое интересное. Объект действует не сам по себе, а с помощью свойств-объектов, которые передаются в конструктор при создании объекта. Например, у нас есть класс Модели, который должен уметь делать КРУД. А точнее сам по себе он содержит только данные, а в качестве зависимости в него передаётся объект для работы с БД, имеющий собственно эти самые методы create(), read(), update() и delete(). И вот этот объект может быть как инстансом класса, работающего, например, с Mysql, а может быть - работающего с Редисом. И теперь, в зависимости от наших потребностей, одна и та же модель может сохраняться как в Редис, так и в РСУБД. Без изменения и единственной строчки кода!
    Ответ написан
    1 комментарий
  • Как продолжить цепь запросов в php?

    Fockker
    @Fockker Куратор тега PHP
    Потомок старинного рода Ипатьевых-Колотитьевых
    Если отбросить всю не относящуюся к вопросу чепуху, типа каких-то "внутренних запросов"(?!), то ответ сводится цепочке вызовов.
    Ответ написан
    Комментировать
  • Насколько целесообразно разбиение на функции и классы?

    Fockker
    @Fockker Куратор тега PHP
    Потомок старинного рода Ипатьевых-Колотитьевых
    Это нормально.
    Ну то есть про конкретный код нельзя сказать, не видя его, но " выносить каждые пару строк в отдельную функцию" - это нормально. Куда нормальнее, чем писать всю тысячу в одной.

    Рекомендую найти видео "Как писать код, который понравится вашим тестам" с первой PHPRussia. Там очень доходчиво рассказывается про то, почему надо делать простые методы. Не только для тестов. А ещё и для повторного использования и для упрощения поддержки кода. Когда надо прочитать основную логику модуля, то даже сокращение в два раза (по одному методу вместо двух строк кода) уже сильно облегчает задачу.
    А если уж даже тест понял, что делает ваш код, то человек поймёт и подавно :)

    Как вам написали выше - все дело в именах методов. Если они информативные, то есть если конструкция
    if ($this->function_7($a) && $this->function_8($b))
    читается как связный английскй текст, то mission accomplished! Функции выполняют свою роль: легче всего читать код, которого нет. Вместо того, чтобы разбирать, что делает тот или иной код, можно просто прочитать небольшой текст на английском.
    Ответ написан
    4 комментария