двинутый чувак?)

ну да, он сам себе противоречит немного

или не очень немного

зачем тогда называть BaseParser? назови это просто Parser

ну это другой вопрос.

ну это другой вопрос.

это главный вопрос

предлагает отказаться от процедурщины, но не объясняет чем его код не процедурщина и чем она поможет

ну я еще пару его видосов глянул, ну, идеи там прикольные есть, но в целом ты прав)

стоит смотреть ?

стоит смотреть ?

ну хз, если посмотреть вечером нечего

я за едой смотрел

предлагает отказаться от процедурщины, но не объясняет чем его код не процедурщина и чем она поможет

мне больше его интервью с Дэвидом Вэстом понравилось

еще не посмотрел

я вот object thinking не читал

BaseParser - просто с потолка

поэтому вчера решил наверстать упущенное)

BaseParser - просто с потолка

вопрос, вот эти детекторы, они где юзаются?

в наследниках

то есть ты можешь сделать их... protected?

в родителе возвращают false

lf

да

окей, идем дальше

можешь хотя бы примерно описать что на входе

html какой-то?

да

страницы допустим авито

окей

дальше

ну абстрактно совсем

что они возвращают? всегда bool или еще чего?

это главный вопрос

class Modul{ public function getUrlRedirect(){ // тут чтото } // и 5 других функций } class Pocket extends Modul{ } Это нормально? или как тогда сделать модульную систему без extends . Что бы я с генерировал модуль и он уже отдавал базовые данные

3 детекста всегда бул

мне больше его интервью с Дэвидом Вэстом понравилось

хотя пример второго чувака про описание картины пикасо простым текстом норм)

class Modul{ public function getUrlRedirect(){ // тут чтото } // и 5 других функций } class Pocket extends Modul{ } Это нормально? или как тогда сделать модульную систему без extends . Что бы я с генерировал модуль и он уже отдавал базовые данные

не нормально

хотя пример второго чувака про описание картины пикасо простым текстом норм)

да, мне дико доставили аналогии

3 детекста всегда бул

а 4-ый?

возвращает массив

не нормально

Как реализовывать модульную систему ?

то есть это не детектор, это экстрактор

да

Как реализовывать модульную систему ?

напиши ТЗ

да

interface Detector { public function detect(string $html): bool; } interface Extractor { public function extract(string $html): array; }

POJO это то, где нет инкапсуляции :)))

POJO это то, где нет инкапсуляции :)))

эм... не помню такого... ну да ладно)

тогда лучше абстрактый класс

тогда лучше абстрактый класс

не не

хотя второй чувак за сеттеры топит

но интерфейсы норм? на вход html на выход либо bool либо данные

странные они короче

абстрактные методы обязательны к реализации

абстрактные методы обязательны к реализации

это понятно, у меня другая тема в голове

придется имплементить постоянно

странные они короче

https://i.ytimg.com/vi/c3Fmue_fe-g/hqdefault.jpg

придется имплементить постоянно

там один метод, ты мне скажи норм интерфейсы? покрывают задачу?

если в первый интерфес поместить 3 метода детека, то наверно да

а теперь ход конем

....рано написал... 2 минутки

но нужно чтоб 4 метод возвращал не пустой массив

Extractor

ну "не пустой массив" это тогда делай какой-то тип вроде Result

https://gist.github.com/fesor/fc298d4a97eb7d27858f0668f237a79a

удобно тестить, удобно расширять

юзаешь всегда только то что нужно

напиши ТЗ

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

> Проект разделен на модули . У каждого сервиса уже неконсистентность требований

> У каждого сервиса свои параметры авторизации, настройки. Один сервис требует логин пароль, а другой настройки подключения. сделай интерфейс Connector

Вы опять ту тему начали?))

и пихай в класс конкретную реализацию

полиморфизм!

ERROR: S client not available

согласен, спс за конкретику

согласен, спс за конкретику

вообще то что ты описал в "нормальных" языках решается функциями а не классами.

export interface Extractor { (html: string): Array; }

и тогда

можно будет вместо ажно целого класса тупо юзать функции

но это typescript, ненастоящий язык

в php для структутизации кода у тебя только классы...

а потому приходится сильно больше писать что бы было норм

можно было в твоем примере использовать trait с 3 методами детекторов, и имплементить Extract

можно было в твоем примере использовать trait с 3 методами детекторов, и имплементить Extract

это убивает всю идею

зато не нужное писать 3 класса

для реализации детектов

тебе IDE сгенерит 80% кода

ленивый

и пихай в класс конкретную реализацию

понял.

зато потом тотальный контроль над ситуацией

мноооого маленьких классов

не облее двух экранов длиной

(без читерства в виде 24" вертикально стоящих экрана)

final для этих классов нельзя использовать

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

немного расширяя его

сделаешь новый класс

вместо того что бы наследоваться

но это скорее исключительные ситуации

Да вернулись к той теме

сделаешь новый класс классы будут повторять код

не очень хорошо

но это скорее исключительные ситуации

final class ExtendedMyExtractor implements Extractor { private $base; public function __construct(Extractor $base) { $this->base = $base; } public function extract(string $html): string { $result = $this->base->extract($html); // do something with result return $result; } }

это называется декорация

@fes0r что почитать о минусах наследования ?

http://www.javaworld.com/article/2073649/core-java/why-extends-is-evil.html