на самом деле нет, но говорить на эту тему не хочу

Поудалял гифки. А по поводу file_get_contents - она все видео сначала загрузит в память а потом будет отдавать в барузер, зачем такое надо

да там все абсурд

да там все абсурд

Отличное описание IT ?

Отличное описание IT ?

прекрасное описание только на прекрасном айти, там все как есть, без приукрас

взял проект китайский мультивендор, так там девочка фронтэндер без знания html, css и js, ну просто нулевая, даже в гит не может, в глаза не видела

ну фронт конечно кривой как будто в ie6

задаю вопрос, а оно надо такую, получаю в ответ других нет ))

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

фулстаки без знания php на проекте пхпешном и т.д.

такая боль

выдохнул, стул вроде живой, спс что выслушали

фулстаки без знания php на проекте пхпешном и т.д.

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

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

иди лучше синтаксис учи, тебе еще до нормального пару лет

такая боль

Обожаю свой детсад )))

Ребят, подскажите такой вопрос, хочу сохранить Емоджи в БД, один сохраняется а дальше весь текст обрезается, как это побороть?

Ребят, подскажите такой вопрос, хочу сохранить Емоджи в БД, один сохраняется а дальше весь текст обрезается, как это побороть?

utf8?

код приоожи на пастебин

База да

Ребята,вы часто используете вьюшки в бд и когда стоит делать хранимые процедуры ?

Ребята,вы часто используете вьюшки в бд и когда стоит делать хранимые процедуры ?

если код можно продать несколько раз, то никогда )

Vera будет жить. Поприветствуем!

Кто-то работает в web или phpstorm? Никак не могу убрать ошибку "JSHint: 'Promise' is not defined. (W117)"

@KonstantinKaretny будет жить. Поприветствуем!

Всем привет, есть вопрос по последнему правилу SOLID - DIP, кто в теме?

Всем привет, есть вопрос по последнему правилу SOLID - DIP, кто в теме?

Задавай сразу

Задавай сразу

Правило DIP обязывает меня указывать интерфейс в качестве типа входящего параметра

https://github.com/wataridori/solid-php-example/blob/master/5-dependency-inversion-principle.php

строка 44

Если следовать этому правилу - придётся для каждого класса заводить интерфейс

Ведь объект любого класса может быть в дальнешем проброшен в качестве аргумента

https://github.com/Piterden/crosswords-module/tree/master/src Посмотри как тут

Эт что?

Тут интерфейсы только у моделей и у репозиториев

Эт что?

API подбора слов по длине и известным буквам

Нашёл

https://github.com/Piterden/crosswords-module/blob/master/src/Clue/ClueRepository.php

строка 31

нарушение правила DIP

Указано имя класса, а не абсракции

public function __construct(ClueModel $model)

Это противоречит последнему правилу SOLID

Почитай про паттерны репозиторий и презентер

В миграциях тоже модели

Почитай про паттерны репозиторий и презентер

кажется он имел ввиду то, что туда ты мог передать ClueInterface или даже EntryInterface, репозиторий тут не при чем.

Глянул примеры шаблонов репозиторий и презентер, это не совсем по теме и во многих примерах DIP также нарушается

Почему все нарушают это правило?

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

В любом случае мой вопрос отаётся открытым

Ещё раз, если следовать правилу DIP, мне всегда в аргументах нужно указывать не конкретные классы, а интерфейсы, а это значит, что под любой класс, какой бы я не создавал, мне нужно заводить интерфейс

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

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

Ещё раз, если следовать правилу DIP, мне всегда в аргументах нужно указывать не конкретные классы, а интерфейсы, а это значит, что под любой класс, какой бы я не создавал, мне нужно заводить интерфейс

с репозиторем таже фигня, там тоже все на интерфейсах и абстрагирование от реализации

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

class A {} class B { public function method(A $arg) { ... } } Это плохо, согласнго DIP нужно так AInterface {} class A implements AInterface {} class B { public function method(AInterface $arg) { ... } }

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

с репозиторем таже фигня, там тоже все на интерфейсах и абстрагирование от реализации

Паттерны сейчас вообще не при чём, речь о DIP и интерфейсах

Чтобы соблюсти DIP в моей программе придётся заводить сотни нтерфейсов, понимаете?

А зачем это вообще? Выполнять правило ради выполнения правила.

А зачем это вообще? Выполнять правило ради выполнения правила.

Я тоже пытаюсь понять зачем это, но SOLID это ведь краеугольный камень ООП

SOLID не просто так обязывет делать именно так, на это есть причины, но если следовать DIP у меня в программе будут сотни сущностей

Сотни интерфейсов

Не вижу вообще никакого смысла иметь интерфейс с одной реализацией в своей программе.

Реализаций может быть множество, не обязательно одна

AInterface {} class A implements AInterface {} class B implements AInterface {} class C implements AInterface {} class D { public function method(AInterface $arg): bool { ... } }

Я тоже пытаюсь понять зачем это, но SOLID это ведь краеугольный камень ООП

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

Не вижу вообще никакого смысла иметь интерфейс с одной реализацией в своей программе.

это называется поддерживаемый код.

Там где несколько реализаций интерфейс ок. Но ведь а куче мест реализация только одна.

Я тоже пытаюсь понять зачем это, но SOLID это ведь краеугольный камень ООП

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

Там где несколько реализаций интерфейс ок. Но ведь а куче мест реализация только одна.

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

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

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

Я никогда не видел репозиторий с интерфейсом в конструкторе

Понимаете сколько будет интерфесов?

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

Думаю не стоит кидаться в крайности

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

так и живет мир Java и все корпоративное ПО, кажется что много мусора, по факту работают десятилетия без сбоев

Я никогда не видел репозиторий с интерфейсом в конструкторе

Это значит что шаблон репозиторий нарушет DIP

Я никогда не видел репозиторий с интерфейсом в конструкторе

иначе это не репозиторий. посмотри реализацию JPA

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

Ага. Давай еще принцип yagni вспомним тогда.

так и живет мир Java и все корпоративное ПО, кажется что много мусора, по факту работают десятилетия без сбоев

Я не хочу страдать, как страдают джавитсы))

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

Под каждую дтошку тоже будешь интерфейс создавать?

так и живет мир Java и все корпоративное ПО, кажется что много мусора, по факту работают десятилетия без сбоев

Без сбоев, зато ценой тысяч интрефейсов

Ага. Давай еще принцип yagni вспомним тогда.

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

Мой вопрос - что хуже - нарушать DIP и порождать тысячи интерфейсов? Какое из зол выбрать?

Так можно дойти до абсурда и никогда не использовать new в коде, т.к. это прямая зависимость.

Презентер тоже получает сам объект, а не интерыейс в конструкторе

Без сбоев, зато ценой тысяч интрефейсов

интерфейсы дешевые, они ничего не стоят. Более того это контракт который позволяет изменять реализацию не ломая совместимость, это более чем оправданная стоимость, а то, сколько там файлов в проекте не имеет вообще никакого значения

Презентер тоже получает сам объект, а не интерыейс в конструкторе

Значит он также нарушет DIP

Так можно дойти до абсурда и никогда не использовать new в коде, т.к. это прямая зависимость.

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

интерфейсы дешевые, они ничего не стоят. Более того это контракт который позволяет изменять реализацию не ломая совместимость, это более чем оправданная стоимость, а то, сколько там файлов в проекте не имеет вообще никакого значения

Больше сущностей богу сущностей?

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

Бред. Пока только одна реализация изменения элементарные. При появлении второй сделать и заменить тайпхинт на интерфейс тоже элементарно.