Классу нужен другой объект: как правильно?

добрый время сутки)
есть класс парсера. ему для работы нужен объект curl. не знаю как правильно: создавать объект curl при создании класса, где-нибудь в конструкторе, или создавать его отдельно от парсера, и передавать в методы как параметр?
спасибо)

0

На мой взгляд не правильно вообще мешать в одну кучу.

У вас две "подзадачи"

1. Получить контент
2. Распарсить контент

А если захотите распарсить контент загруженный иным способом?

Имхо. Клиентом получаете контент, а в парсер передаете именно контент. (Если, конечно, нет каких то реальный и объективных причин конкретно в вашей ситуации использовать как таковой клиент внутри парсера.

0

расскажу подробнее про задачу.
есть магазин с товарами. товары выгружаются из 1с, но без описаний. название, цена, артикул. вся остальная информация есть на других сайтах этой же компании. их 2. т.е. делаю механизм, который будет получать информацию из 2х источников.
кроме этого - товар находится через поиск. первым запросом я обращаюсь в поиск по сайту, смотрю нашлось ли что-то, потом получаю ссылку, иду по ней, и уже там собираю инфо о товаре.
вообще идея сделать такой парсер в стиле ооп пришла после провальной попытки не заморачиваться и сделать его в процедурном стиле. штука в том что на сайтах источников все параметры называются однотипно. у всех товаров цвет, у всех товаров размер, куча типа-общих параметров. я их собрал, разделил по категориям, чтобы на сайте были понятные названия свойств и удобочитаемый умный фильтр. но этот порыв привалил меня необходимостью при парсинге понимать к какой категории относится товар, и к с какими свойствами в нашей бд связывать свойства этого товара.
хочу сбежать от макарон - сделать аккуратный объект, которому скармливаешь артикул, он творит магию, и отдает массив свойств. и я думаю куда лучше прилепить этот самый курл

0

Ну если прям совсем по ООП, то создаете интерфейс и прячете за ним работу с курл. А реализацию этого интерфейса передаете параметром в конструктор. А можно просто Guzzle скачать и не пилить свой велосипед
Создавать объект напрямую точно плохо, как минимум будут сложности с тестированием, а curl это же еще и поход по сети.
Единственное, если это разовый парсер, то может оно того и не стоит...

0

guzzle, судя по тому, что я про него нашел, это тоже самое что и курл, только удобнее. точно так же мне надо сделать его объект и через него получать контент... не понял почему использование guzzle убирает какой-то велосипед. если можно то объясните этот момент.

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

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

0

Сообщение от user20011993 не понял почему использование guzzle убирает какой-то велосипед. если можно то объясните этот момент.

Потому что у него из коробки уже есть интерфейс, соответственно самому можно его не описывать.
Более того, это не просто интерфейс, а интерфейс по PSR. Многие аналогичные библиотеки реализуют его, что позволяет подменять одну реализацию на другую. Это возможно потому что код зависит от интерфейса, а не от реализации.

Пересказывать все принципы можно долго. Лучше почитайте про solid, grasp, паттерны итд, там все разжевано и с примерами.

0

это про дальнейшую поддержку. вроде понял. на этом этапе интересовало как действовать с таким дополнительным объектом, который нужен для работы. будем пробовать, спасибо

0

Сообщение от user20011993 это про дальнейшую поддержку

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

0