Как научиться писать такой ООП код?

Question

[gog69]

У меня было тестовое задание.
Суть: есть url по которому список url картинок, проходим их все, ресайзим и выводим на экран.

Я уже не на том уровне, что бы писать функцию, которая отработает сверху вниз. Я бы создал один класс и по его методам раскидал логику - т.е. сделал бы методы download, resize, output, etc.

Вот как сделал его один гуру https://github.com/urakozz/tests/blob/master/getIm...

Он создал 3 класса и везде использовал итераторы, агрегаторы, SplFileObject, короче классы и паттерны для всего, чего можно.

Как этому научиться?

Comments

[evnuh]

перепишите вопрос по-русски, исправив все ошибки. Вы же не эпилептик?

Answer 1

[Copperfield]

Мне в школе физрук говорил:"Чтобы много подтягиваться - нужно много подтягиваться".

Answer 2

[Антон Шаманов]

Мэтт Зандстра - PHP. Объекты, шаблоны и методики программирования

Comments

[Евгений Одинец]

Хорошая книга

[Сергей Протько]

Не читал но осуждаю

Answer 3

[Дмитрий Ковальский]

Ну начать следует с перечитывания собственных вопросов. Далее перейти на книжку "Head First Паттерны проектирования" просто чтобы понять что это и зачем придумано. Более тщательно(раз 5) перечитать главу где пишут что не надо применять паттерны ради применения паттернов. А дальше вперед к практике.

Comments

[65536]

> перечитать главу где пишут что не надо применять паттерны ради применения паттернов

эта глава должна быть воткнута между всеми остальными главами, как припев

Answer 4

[Дмитрий Энтелис]

Вот честное слово, много паттернов + ооп != хороший код.
За код типа

$this->initBatch();
        $this->attachHandlers();
        $this->executeHandlers();
        $this->getContent();
        $this->detachHandlers();

я бы медленно убивал.

Comments

[Антон Шаманов]

А что не так то? вызов цепочкой не всегда актуален

[pi314]

Просто интересно, что бы Вы тогда делали за код типа

foreach ($processor as $key => $resource) {
        if(preg_match("/\.png/iu", $key)){
            ImagePng($resource, $i.".png", 0);
        } else {
            ImageJpeg($resource, $i.".jpg", 85);
        }
        $i++;
    }

(в частности для случая с .gif) ?

[Stalker_RED]

pi314: Широчайший выбор же. От else if до switch case default.

[pi314]

Stalker_RED: Да это-то понятно, непонятно другое! Почему не использован ни один внятный паттерн обработки исключений... ведь есть же fail fast, recovery, handling at work level / at case level и т.д. Где все эти замечательные вещи в коде глубокоуважаемого Гуру? (это все мысли вслух под тегом "сарказм", на случай, если целью кода было использовать максимальное количество паттернов)

Answer 5

[trevoga_su]

в этом коде нет ничего сверхъестественного
пишите больше и все придет с опытом

Answer 6

[Viktor Vsk]

Не делать ООП ради ООП, а решать каждую задачу оптимальным образом
Не считать сложный код - хорошим кодом: код по ссылке не выдержит вообще никакой критики.
Читать https://refactoring.guru/ и всякие термины SOLID, но без преждевременной оптимизации

Не просто что-то делать, а постоянно усложнять задачи (не путать с усложнением способа решения задачи), задаваясь вопросом, можно ли решить ее проще.

Answer 7

[Александр Мелеховец]

Если интересен код с ооп и паттернами ради ооп и паттернов - взгляните на https://github.com/EnterpriseQualityCoding/FizzBuz... и сравните с тем, что получится, если решать задачу в лоб. Потом спросите себя, а нафига козе баян? И задавайте этот вопрос себе постоянно, чтобы научиться находить баланс между простотой и гибкостью.
По книгам: Зандстра, потом PoEAA Фаулера, потом DDD Эванса. Читаем, применяем, думаем "нафига", и так до просветления :)
Удачи)

Answer 8

[Антон Тихомиров]

Коллеги вверху правильно ответили, что не стоит так усложнять код кроме разве что академического интереса. Задание по вашей ссылке можно было бы уместить в одну простую функцию и не городить из этого целый движок. Проблема не в ООП, он очень нужный и классный (серьезно), однако проблема в том, что его часто суют где только можно, но где это совершенно не нужно. Можно и гвозди унитазом забивать, только зачем?

Answer 9

[Pavel Shvedov]

Читайте и практикуйтесь, что тут еще посоветовать. Волшебной пилюли, которую съешь и всему научишься, не существует

Answer 10

[Олег Красавин]

Изучите приведенный вами пример.
Прогуглите непонятные вам места(генераторы, SplFileObject, ArrayIterator и тп)
Почитайте про встроенные интерфейсы php.net/manual/ru/reserved.interfaces.php
Для каждого из списка ответьте на вопрос "Зачем?" и "Для чего?"

Теперь попробуйте написать что-нибудь для себя, используя эти штуки.

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

Answer 11

[Андрей]

Добрый день.
Изучайте паттерны проектирования,работу с SPL,построение архитектуры приложения.
Самое главное - пишите код...много кода)

Answer 12

[Walt Disney]

Все заумные подходы к написанию кода нужны для того что бы его можно было долго писать, быстрее рефакторить и долго-долго поддерживать и т.п.

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

Если вы будете применять всякие заумные абстракции ради академического интереса, а не ради решения производственных проблем, то ваш код будет полной фигнёй.

Соответственно ответ на сам вопрос: начните решать задачи где написание такого кода жизненно необходимо.

Comments

[gog69]

это например где?

[Walt Disney]

Там где начинает тратиться неприемлемое количество времени на поддержку, исправление багов и т.п.
Упрощённый пример, работал один программист использовал только глобальные переменные, тратил в месяц неделю на отладку, пришли ещё двое в помощь, в результате чего каждый из трёх стал тратить 3 недели в месяц на отладку, перестали использовать глобальные переменные и каждый программист стал тратить на отладку 1 неделю в месяц.

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