Вы не поверите. Я не только Википедию читал, но и ещё с десяток статей по теме.
Но вы похоже не поняли о чем статья и о чем проект.
Вы мне раз за разом пытаетесь объяснить как правильно реализовать LSP.
Задача же проекта показать проблему, то есть пример нарушения LSP, и привести пример решения конкретной проблемы, то есть решение которое не будет нарушать LSP. Как ваше решение, так и моё не нарушает LSP, что и требуется.
Код решат разные задачи потому и правильное решение будет разным.
Вообще-то вы очень сильно поспешили с переводом.
Там куча косяков. Большую часть я поправил, но например реализация того же LSP не правильная.
А про использование SECONDS_IN_A_DAY я вообще молчу.
Но ваши доводы — оторваны от реальности и не имеют никакого отношения даже теоретически к этим 86 миллионам.
Не согласен с вами. Я как раз пытался продемонстрировать доводы максимально приближенные к реальности.
Если вас они не устраивают, ок. Тогда я не вижу смысла продолжать дискуссию.
Или может вы предложите свои доводы, которые вы считаете более приближенными к реальности? Тогда нам будет о чем поговорить
Конечно конфиденциальная. Это же персональные данные. По номеру же можно идентифицировать владельца машины.
Это как если бы номер вашего паспорта передавался в открытом виде.
Шифрование сетевого трафика уже давно существует
Несомненно, но не стоит забывать что мы говорим о госструктурах.
Они не одобрят всякие там ваши OpenSSL и прочее.
Конечно, я думаю, что уже есть какие-то алгоритмы которые могут использоваться в госструктурах или они могут воспользоваться нароботками коллег по цеху.
Ну и не забываем что на шифровку и дешифровку пакетов нужно время и процессорные ресурсы.
Мы уже привыкли к мощным серверам с 32мя ядрами и терабайтами оперативы и забываем как это разработка на компьютере размером меньше пачки сигарет и питающейся от 12V.
Я лишь хочу сказать, что не все так просто как кажется на первый взгляд и $86 миллионов могут быть вполне оправданными.
Ну конечно можно локально кешировать.
Можно даже агрегировать номера и отправлять их одним пулом на сервер, скажем раз в минуту.
Тогда в одном пуле будет от 0 и до 60 номеров.
Но у на соответственно появляется необходимость в ресурсах для кеша.
Это накладывает свои требования на оборудование.
Это может быть оперативная память, но мы например должны шифровать номера так как это конфиденциальные данные.
И это не избавляет нас от проблемы, что одна итерация работы программы должна занимать менее 1 секунды.
Так же не стоит забывать что устанавливаем мы камеры на машины и соответственно доступ к серверу у нас будет по беспроводной сети. А пакеты ещё и шифровать надо, так как пересылаем мы персональные данные. И связь соответственно должна быть стабильной.
Это накладывает ещё кучу ограничения и требований на ПО и оборудование.
А на счёт встречки.
Как вы собираетесь определять, что на конкретном кадре, два номера — один на встречке, а второй нет?
Если номер в каком-то углу то это значит, что это может быть припаркованные машина, а может быть вы едете по многополосной трассе.
Можно конечно попытаться привязаться к GPS, но это не надёжно и требует кучу ресурсов.
Можно сравнивать кадры. Например, если номер есть только на одном из двух соседних кадров то это значит что это либо встречке, либо гонщик, либо некорректно распознан номер.
А если мы в пробке то встречку мы будем видеть дольше.
В общем, отбрасывает встречку себе дороже, да и зачем.
У меня сходу возникли сомнения.
Автор распознает номер машины на статическом кадре видео.
Это работает. Окей.
А как на счёт потокового видео?
То есть, условно каждую секунду брать кадр из видеопотока и анализировать его.
Каждую секунду отправлять запрос на сервер.
А машин на кадре может быть несколько.
Если брать кадры реже, то мы рискуем пропустить какого-то гонщика.
Ну и скорость распознавания кадра и получение ответа от сервера должно занимать меньше секунды иначе будет накапливаться очередь и программа просто не сможет работать.
Это работает для камер которые фиксируют скоростные нарушения потому что они делают снимок по датчику движения, а во времени распознавания номера они вообще не ограничены.
Небольшое пояснение на счёт транзакций.
Если вы изучаете DDD, то, я думаю, вы это знать, но я все же поясню. Вдруг кто не вкурсе.
В примере который описал я под ваши задачи, Транзакция существует только в рамках Истории транзакций. Перевод средств из Фонда одного Желания в Фонд другого это бизнес транзакция. Не объект транзакция. В результате перевода средств будут созданы 2 объекта Транзакции в Истории транзакций одного и второго Фондов. Тоесть История транзакций напоминает Event Sourcing. В коде, перевод средств может иметь вид:
$fund1->trasfer($money, $fund2);
Всё остальное делается внутри. Вклад тоже является Транзакцией только в Истории транзакций.
Если у нас существует сущность Кошелёк или Счёт, то мы можем делать вклад используя их. Что-то тип:
$fund->invest($money, $account);
Здесь кстати не очень понятно. Возможно лучше делать вклад через кошелек:
$account->invest($money, $fund);
Если Вклады появляются из неоткуда, как у вас, то лучше делать VO на мой взгляд.
Вы не поверите. Я не только Википедию читал, но и ещё с десяток статей по теме.
Но вы похоже не поняли о чем статья и о чем проект.
Вы мне раз за разом пытаетесь объяснить как правильно реализовать LSP.
Задача же проекта показать проблему, то есть пример нарушения LSP, и привести пример решения конкретной проблемы, то есть решение которое не будет нарушать LSP. Как ваше решение, так и моё не нарушает LSP, что и требуется.
Код решат разные задачи потому и правильное решение будет разным.
Ну и авторам больше по нраву другой пример.
рука_лицо.джпег! при том что вынесение одной в подтип другой является нарушением LSP, о чем и говорит весь раздел
Если вам не нравится пример, предложите лучше, а не критикуйте.
Это открытый проект.
Спасибо за замечание. Уже убрал интерфейс
Shape.Пример с прямоугольником и квадратом самый популярны при описании принципа LSP.
В PR код завязан на конкретные типы потому, что квадрат и прямоугольник это разные типы. В этом и суть LSP
И актуализируйте пожалуйста перевод до текущей версии. Перевод сильно отстал.
Это сделано для демонстрации проблемы LSP
Есть пример с
immutableклассами.уже используется интерфейс
Travelerможно вопрос, а часто вы сайтики на марсе запускаете?
Мне и моим голлегам проще читать цифры вида 3600 и 86400, хотя авторы со мной не согласны
В этом и суть. По моему где-то даже высказывались о бессмысленности этого правила
там
globalдолжно было бытьУже пофиксили
Автор оригинала содрал код отсюда и даже не особо заморачивался с переводом в PHP код (1, 2, 3, 4).
может дополните мою правку?
Вообще-то вы очень сильно поспешили с переводом.
Там куча косяков. Большую часть я поправил, но например реализация того же LSP не правильная.
А про использование
SECONDS_IN_A_DAYя вообще молчу.Если уж сделали перевод, поделитесь с сообществом.
Не согласен с вами. Я как раз пытался продемонстрировать доводы максимально приближенные к реальности.
Если вас они не устраивают, ок. Тогда я не вижу смысла продолжать дискуссию.
Или может вы предложите свои доводы, которые вы считаете более приближенными к реальности? Тогда нам будет о чем поговорить
Конечно конфиденциальная. Это же персональные данные. По номеру же можно идентифицировать владельца машины.
Это как если бы номер вашего паспорта передавался в открытом виде.
Несомненно, но не стоит забывать что мы говорим о госструктурах.
Они не одобрят всякие там ваши OpenSSL и прочее.
Конечно, я думаю, что уже есть какие-то алгоритмы которые могут использоваться в госструктурах или они могут воспользоваться нароботками коллег по цеху.
Ну и не забываем что на шифровку и дешифровку пакетов нужно время и процессорные ресурсы.
Мы уже привыкли к мощным серверам с 32мя ядрами и терабайтами оперативы и забываем как это разработка на компьютере размером меньше пачки сигарет и питающейся от 12V.
Я лишь хочу сказать, что не все так просто как кажется на первый взгляд и $86 миллионов могут быть вполне оправданными.
Ну конечно можно локально кешировать.
Можно даже агрегировать номера и отправлять их одним пулом на сервер, скажем раз в минуту.
Тогда в одном пуле будет от 0 и до 60 номеров.
Но у на соответственно появляется необходимость в ресурсах для кеша.
Это накладывает свои требования на оборудование.
Это может быть оперативная память, но мы например должны шифровать номера так как это конфиденциальные данные.
И это не избавляет нас от проблемы, что одна итерация работы программы должна занимать менее 1 секунды.
Так же не стоит забывать что устанавливаем мы камеры на машины и соответственно доступ к серверу у нас будет по беспроводной сети. А пакеты ещё и шифровать надо, так как пересылаем мы персональные данные. И связь соответственно должна быть стабильной.
Это накладывает ещё кучу ограничения и требований на ПО и оборудование.
А на счёт встречки.
Как вы собираетесь определять, что на конкретном кадре, два номера — один на встречке, а второй нет?
Если номер в каком-то углу то это значит, что это может быть припаркованные машина, а может быть вы едете по многополосной трассе.
Можно конечно попытаться привязаться к GPS, но это не надёжно и требует кучу ресурсов.
Можно сравнивать кадры. Например, если номер есть только на одном из двух соседних кадров то это значит что это либо встречке, либо гонщик, либо некорректно распознан номер.
А если мы в пробке то встречку мы будем видеть дольше.
В общем, отбрасывает встречку себе дороже, да и зачем.
У меня сходу возникли сомнения.
Автор распознает номер машины на статическом кадре видео.
Это работает. Окей.
А как на счёт потокового видео?
То есть, условно каждую секунду брать кадр из видеопотока и анализировать его.
Каждую секунду отправлять запрос на сервер.
А машин на кадре может быть несколько.
Если брать кадры реже, то мы рискуем пропустить какого-то гонщика.
Ну и скорость распознавания кадра и получение ответа от сервера должно занимать меньше секунды иначе будет накапливаться очередь и программа просто не сможет работать.
Это работает для камер которые фиксируют скоростные нарушения потому что они делают снимок по датчику движения, а во времени распознавания номера они вообще не ограничены.
В общем, все самое сложное автор не сделал.
Небольшое пояснение на счёт транзакций.
Если вы изучаете DDD, то, я думаю, вы это знать, но я все же поясню. Вдруг кто не вкурсе.
В примере который описал я под ваши задачи, Транзакция существует только в рамках Истории транзакций. Перевод средств из Фонда одного Желания в Фонд другого это бизнес транзакция. Не объект транзакция. В результате перевода средств будут созданы 2 объекта Транзакции в Истории транзакций одного и второго Фондов. Тоесть История транзакций напоминает Event Sourcing. В коде, перевод средств может иметь вид:
Всё остальное делается внутри.
Вклад тоже является Транзакцией только в Истории транзакций.
Если у нас существует сущность Кошелёк или Счёт, то мы можем делать вклад используя их. Что-то тип:
Здесь кстати не очень понятно. Возможно лучше делать вклад через кошелек:
Если Вклады появляются из неоткуда, как у вас, то лучше делать VO на мой взгляд.
Но это все чисто рассуждения на тему.