Ответы пользователя по тегу ООП
  • Зачем нужны абстрактные классы и интерфейсы в php?

    search
    @search
    мама говорит что я особенный
    Интерфейс - это контракт, который реализовывает класс, а пользователи класса знают как этот класс использовать. Это альтернатива множественному наследованию. Например у вас есть два типа коллекции: бинарное дерево и граф. Это довольно отличающиеся структуры данных. Но каждая из коллекций может реализовать интерфейс Iterator и в этом случае интерпретатор будет знать как перебрать коллекцию в цикле foreach.

    Абстрактные классы в основном используются в том случае, если какую-то часть кода можно описать в родительском классе, но для того чтоб эта часть приобрела смысл, нужна конкретика: дополнить общую картину подробностями в виде методов или полей. Если вы присмотритесь к абстрактным классам в современных фреймворках, то увидите что сам по себе абстрактный класс не имеет смысла. Например, если создать объект такого класса оператором new, то этому объекту всё равно будет чего-то не хватать и именно это что-то и добавляют дочерние классы.
    Ответ написан
    2 комментария
  • Как создать дочерний класс, который виден в родительском в PHP?

    search
    @search
    мама говорит что я особенный
    Смотрите на это так: каждая кнопка реализует интерфейс `Button`. К тому же каждая кнопка может иметь общего родителя. Это если вы так захотите. Это не обязательно. Так же у вас существует класс `Panel`, который хранит коллекцию объектов, реализующих интерфейс `Button`.

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

    search
    @search
    мама говорит что я особенный
    Книга Приёмы объектно-ориентированного проектирования. П... предоставляет весьма популярные практики использования ООП. Написана в 1994 году. По сей день считается "маст рид" для программиста.
    Ответ написан
    Комментировать
  • [PHP] DataBase на ООП, как лучше написать?

    search
    @search
    мама говорит что я особенный
    Вот тут вкратце описаны все популярные шаблоны проектирования DB слоя https://gist.github.com/codedokode/c4cbc4d7dc8e45ea074a

    Выбирайте тот что вам по душе и кайфуйте.

    Попробуйте DataMapper. Он довольно прост в реализации (вам даже либа не пондобится. Ну разве что стандартная PDO) и меньше чем ActiveRecord склоняет программистов к говнокоду. Ну и гораздо менее тяжеловесен чем полноценная ОРМ. Для понимания и закрепления ООП - самое то.

    Только что попробовал поискать примеры в русском тырнете, но ничего вменяемого не нашел. Попробуйте сами погуглить ради интереса.

    Вот очень подробная статья на инглише https://www.sitepoint.com/integrating-the-data-mappers/

    А самый, на мой взгляд, лучший пример, предоставлен японцем (не пугайтесь иероглифов, смотрите код): https://github.com/hirak/pdo-datamapper-example
    Ответ написан
    2 комментария
  • Правильно ли я использую делегирование?

    search
    @search
    мама говорит что я особенный
    Во-первых, вы молодец, что движетесь в этом направлении. Продолжайте в том же духе.

    По коду есть следующие замечания/предложения по улучшению:
    - Делегирование подразумевает передачу некоторого функционала другому объекту. По сути, когда вы создали объект класса и выполнили метод этого объекта - вы уже делегировали некую функциональность. Например в контроллере задачу по выборке юзера вы делегировали объекту класса User. В случае же с классами User и Image, происходит внедрение класса Image в User (привет Dependency Injection), но дальше Image никак не используется классом User. Т.е. происходит Dependency Injection, но нет делегирования. На том этапе, который я сейчас вижу, я бы не стал внедрять Image в User. Сейчас это выглядет как задел на будущее, но любой опытный программист подтвердит, что композиция, созданная на будущее - ненужная композиция.
    - Глядя на структуру классов, мне не совсем понятно чем они занимаются. Вроде как класс User и Image должны хранить информацию о пользователе и картинке (об этом нам говорит $id в конструкторе). Но в тех же классах есть логика по выборке данных из базы. По-хорошему выборкой должны заниматься другие классы. Лучше разделить задачи выборки и хранения на 2 разных класса. Я очень рекомендую вам ознакомиться с паттерном Data Mapper (наример тут designpatternsphp.readthedocs.io/en/latest/Structu... или тут codeinthehole.com/projects/domain-model-mapper-a-p... На мой взгляд, Data Mapper - это то что вам сейчас нужно реализовать чтоб получить чёткую структуру кода и разделение ответсвенности за выбор/хранени.

    По поводу делегирования. Просто старайтесь чтоб ваши классы были как можно меньше. Критерий 1-3 метода на один класс вполне может подойти (помните, что это не золотое правило). Когда у вас появится желание добавить еще один метод в класс A - спросите себя, а нужен ли там вообще этот метод? Может лучше переложить всю ответственность на новый класс B, в который вы будете передавать объект A (или какое-то из его полей), а сам класс B уже проведёт необходимые преобразования/вычисления? Это и будет делегирование в том виде, в котором его ждёт от нас банда четырёх (если вы еще не читали их книгу, то это must read для любого программиста).

    Фух, длинный ответ получился. Надеюсь, что не зря.
    Ответ написан
    3 комментария