Массив отрезков, в общем случае, полигоном не является.
Портить координаты дельтой, действительно, не хорошо. Должно быть достаточно ввести некий tolerance для сравнения вещественных чисел. Ну и само это сравнение вынести в отдельный метод, не размазывая по коду.
Кстати, как эта "порча" должа помочь избежать двойного зачета точки, если портятся абсолютно все точки полигона?
Наверное, в статье есть много интересных, полезных и здравых мыслей.
Но вот это вот "юмор внутри команды перетекает в троллинг, а троллинг – в травлю" в самом начале отбивает всякое желание читать дальше. Извините, но это самое что ни на есть классическое "Сегодня он играет джаз, а завтра Родину продаст".
Да, для того, чтобы не обидеться на едкую шутку, нужен мозг. Но, вроде, у индивидов, идентифицирующих себя программистами, он должен в каком-то количестве присутствовать.
И давайте не забывать Стругацких: "Саваоф Баалович стал всемогущ. Он мог всё. И он ничего не мог. Потому что граничным условием уравнения Совершенства оказалось требование, чтобы чудо не причиняло никому вреда. Никакому разумному существу. Ни на Земле, ни в иной части Вселенной. А такого чуда никто, даже сам Саваоф Баалович, представить себе не мог."
class Box<T> where T:Animal
{
public void Put(T animal)
{
...
}
}
void PutAnimal(Box<Animal> box)
{
box.Put(new Cat());
}
void Test()
{
PutAnimal(new Box<Dog>());
}
Так в этом случае оно даже не соберется в большинстве ЯП, потому что Box<Animal> не является супертипом для Box<Dog>. Чтобы оно заработало, вам надо явно указать вариантность.
А если "починить" проблему тем, что
class Box
{
public void Put(Animal animal)
{
...
}
}
то рано или поздно столкнемся с проблемой явного приведения типов при использовании, о которой я написал выше.
Как я понимаю автора, революции в программировании не случилось, есть эволюционное развитие.
И "один запрос на LINQ" внутри себя как раз и разворачивается в "if, циклы while и операторы присваивания".
В принципе, вам ничто не мешает взять какой-нибудь достаточно древний ЯП и забабахать LINQ на нем. В зависимости от древности и дубовости языка вам, конечно, придется пободаться с лямбдами и переизобретением expression trees - но на что-то принципиально нереализуемое вы вряд ли наткнетесь.
Да пример просто немножко странный, поэтому, кмк, идею он раскрывает не очень: технически, вы пытаетесь сделать анбоксинг значения супертипа с явным приведением его к одному из подтипов - и на основании этого делаете вывод, что LSP не работает. Хотя за такой код надо просто линейкой по рукам бить:
void SomeFunction(Box<Animal> box)
{
Animal animal = box.Unbox();
Dog dog = (Dog)animal; // wtf?
dog.Aport();
}
А теперь, пожалуйста, раз вы так хорошо разбираетесь в этой простыне, найдите пункт, что в случае правомерной обработки ПД согласно ст.6 контролер не обязан уведомлять об этом субъекта.
Допустим, у меня ежедневные бэкапы за неделю в том же дата-центре, ежемесячные отправяются в другой, а квартальные вообще лежат в сейфе на магнитной ленте (банальное backup-правило 3-2-1).
Допустим, 1-го января сделались все бэкапы. А 2-го января чувак отзывает разрешение на использование ПД. Из актуальной базы я данные-то потру, но: на ленте они еще будут доступны 3 месяца (и ничего не мешает восстановить этот бэкап в случае какого-то совсем epic fail инфраструктуры), а ежедневные бэкапы будут обрабатывать эти персональные данные, выполняя merge-трансформации инкрементов, что тоже "нарушение".
Ну то есть врача с общим залом ожидания все-таки нужно наказывать? А то вдруг одна из сидящих там бабок уедет в Зимбабве и начнет оттуда рассылать проктологический спам...
только если ваши ПД передаются третьим лицам
На самом деле нет. Вся кутерьма с соглашениями - когда мои данные начинают обрабатывать любым способом, даже не привлекая третьи лица.
закон не защитит вас от того, что какой-нибудь злой сотрудник...
Вы просто писали про выстраивание процессов согласно GDPR. А я привел бэкапы как пример того, что часть процессов просто-напросто невозможно выстроить.
А мне показалось, или тут с причинно-следственными связями чё-то не то? Рассылку спама и прочие радости мошенничества можно классифицировать как преступления, не привлекая GDPR. А вот GDPR - он как раз про то, как задолбаться авансом.
Т.е., утрируя, "раз для изготовления растительных наркотиков нужна вода - давайте-ка мы напишем закон по обращению воды в природе. И пусть все те, кто ей пользуются - обязаны каждый раз заключать новое соглашение".
Нельзя :)
Во-первых, в реальной жизни полное равенство двух double - штука маловероятная. Собственно, поэтому тут везде дельта.
Во-вторых, а что такое "начало отрезка"?
И пока вы не ответили, спрошу еще: а что мешает иметь два отрезка, заданные как (A, B) и (A, C)?
Если слегка поревьювить:
Почему точки отрезка (Segment) мутабельные?
Массив отрезков, в общем случае, полигоном не является.
Портить координаты дельтой, действительно, не хорошо.
Должно быть достаточно ввести некий tolerance для сравнения вещественных чисел.
Ну и само это сравнение вынести в отдельный метод, не размазывая по коду.
Кстати, как эта "порча" должа помочь избежать двойного зачета точки, если портятся абсолютно все точки полигона?
Наверное, в статье есть много интересных, полезных и здравых мыслей.
Но вот это вот "юмор внутри команды перетекает в троллинг, а троллинг – в травлю" в самом начале отбивает всякое желание читать дальше.
Извините, но это самое что ни на есть классическое "Сегодня он играет джаз, а завтра Родину продаст".
Да, для того, чтобы не обидеться на едкую шутку, нужен мозг. Но, вроде, у индивидов, идентифицирующих себя программистами, он должен в каком-то количестве присутствовать.
И давайте не забывать Стругацких: "Саваоф Баалович стал всемогущ. Он мог всё. И он ничего не мог. Потому что граничным условием уравнения Совершенства оказалось требование, чтобы чудо не причиняло никому вреда. Никакому разумному существу. Ни на Земле, ни в иной части Вселенной. А такого чуда никто, даже сам Саваоф Баалович, представить себе не мог."
Рассказывать про контейнеры и облака, делая фоточки экрана вместо скриншотов... Киберпанк, который мы заслужили. (:
PS. Еще и с битыми пикселями.
То есть вы вот такой пример предполагаете?
Так в этом случае оно даже не соберется в большинстве ЯП, потому что Box<Animal> не является супертипом для Box<Dog>. Чтобы оно заработало, вам надо явно указать вариантность.
А если "починить" проблему тем, что
то рано или поздно столкнемся с проблемой явного приведения типов при использовании, о которой я написал выше.
Как я понимаю автора, революции в программировании не случилось, есть эволюционное развитие.
И "один запрос на LINQ" внутри себя как раз и разворачивается в "if, циклы while и операторы присваивания".
В принципе, вам ничто не мешает взять какой-нибудь достаточно древний ЯП и забабахать LINQ на нем. В зависимости от древности и дубовости языка вам, конечно, придется пободаться с лямбдами и переизобретением expression trees - но на что-то принципиально нереализуемое вы вряд ли наткнетесь.
Да пример просто немножко странный, поэтому, кмк, идею он раскрывает не очень: технически, вы пытаетесь сделать анбоксинг значения супертипа с явным приведением его к одному из подтипов - и на основании этого делаете вывод, что LSP не работает. Хотя за такой код надо просто линейкой по рукам бить:
А мне ваше мнение интересно.
вообще никак к ООП не относятся.
строго говоря, к оригинальной идее ООП весьма перпендикулярны. Кроме того, не могли бы вы пояснить, как SOLID завязан на эту триаду?
Смущает. Но это то же самое, что говорить, будто молоток - это плохой инструмент, только потому что кто-то им палец отшиб.
А в комментариях затем разбирается ошибка в рассуждениях автора.
А что не так с LSP? Как по мне, в этой статье самое изящное изложение этого принципа из всех, что я слышал.
И во что у вас ООП мутировал, интересно?
Скорее, наоборот: нельзя не оскорбиться, если за это несложное действие маячит крайне внушительная сумма.
Как бы кто что ни говорил, но выгорать за достойную зарплату всё-таки лучше, чем за маленькую. :)
А вы когда переезжали? Если в 20-21, то есть шанс, что что-то оптимизировали в документообороте.
Либо от земли все-таки многое зависит. У нас на Баварщине так не забалуешь - только лично, только ножками.
Круто, спасибо.
А теперь, пожалуйста, раз вы так хорошо разбираетесь в этой простыне, найдите пункт, что в случае правомерной обработки ПД согласно ст.6 контролер не обязан уведомлять об этом субъекта.
Допустим, у меня ежедневные бэкапы за неделю в том же дата-центре, ежемесячные отправяются в другой, а квартальные вообще лежат в сейфе на магнитной ленте (банальное backup-правило 3-2-1).
Допустим, 1-го января сделались все бэкапы. А 2-го января чувак отзывает разрешение на использование ПД. Из актуальной базы я данные-то потру, но: на ленте они еще будут доступны 3 месяца (и ничего не мешает восстановить этот бэкап в случае какого-то совсем epic fail инфраструктуры), а ежедневные бэкапы будут обрабатывать эти персональные данные, выполняя merge-трансформации инкрементов, что тоже "нарушение".
Вау, я бы на это посмотрел, как кто-то пытается поменять договор с, допустим, Амазоном, ну или хотя бы Телекомом.
Боюсь только, что я столько попкорна не осилю.
Ну то есть врача с общим залом ожидания все-таки нужно наказывать? А то вдруг одна из сидящих там бабок уедет в Зимбабве и начнет оттуда рассылать проктологический спам...
На самом деле нет. Вся кутерьма с соглашениями - когда мои данные начинают обрабатывать любым способом, даже не привлекая третьи лица.
Вы просто писали про выстраивание процессов согласно GDPR. А я привел бэкапы как пример того, что часть процессов просто-напросто невозможно выстроить.
Да нет, конечно.
В действительности все гораздо, гораздо хуже. :)
А мне показалось, или тут с причинно-следственными связями чё-то не то? Рассылку спама и прочие радости мошенничества можно классифицировать как преступления, не привлекая GDPR. А вот GDPR - он как раз про то, как задолбаться авансом.
Т.е., утрируя, "раз для изготовления растительных наркотиков нужна вода - давайте-ка мы напишем закон по обращению воды в природе. И пусть все те, кто ей пользуются - обязаны каждый раз заключать новое соглашение".