С нормальным государством в случае нарушения договора оферты можно успешно судиться.
Каждый клиент является еще и акционером с правом голоса, поэтому совет директоров, как правило, всякую дичь творить не может (а если и может, то очень недолго).
А уж если гендиректор конторы облил все здание бензином, поджег и заперся у себя в кабинете - то, наверное, не стоит бегать со своим маленьким ведерком и здание тушить. Правильнее будет зафиксировать потери и распрощаться со своей ничего уже не стоящей акцией.
Мне в этих философских рассуждениях немного непонятна сакрализация государства как такового. Почему государство должно быть для гражданина чем-то большим, чем провайдером по предоставлению услуг (медицинских, правовых, охранных, и т.д.)?
Вот плачу я за интернет - и покуда он у меня есть, мне абсолютно фиолетово в крапинку на "целостность" организации, его предоставляющей. Ровно так же и провайдер думает (точнее не думает) про меня.
Аналогичная история и с государством: есть договор оферты в виде законодательной базы, есть абонентская плата за пользования услугами - налоги. И не нужны никакие брачные танцы в виде взаимной "заинтересованности" - достаточно обычных здоровых рыночных отношений.
Так что если качество предоставляемых услуг не соответствует заявленному уровню, то логичнее искать варианты, как провайдера поменять.
9 центов за КВт*ч - это "конские цены"? И 165К за новую (!) трешку на >90 квадратов - много?
А вот то, что безумно жарко, дико скучно и аборигены бесят своим сига-сига - это да, тут ни почти бесплатная недвижимость, ни дешевое электричество не радуют.
Интересный вопрос, задумался. Сейчас мне кажется, что между IT и ЧКГ не так много общего, как изначально представлялось.
Постановка задачи в случае ЧГК предполагает наличие правильного ответа, что, в ряде ситуаций является жирной подсказкой (те же вопросы на школу). IT же, с другой стороны, - это инженерия, умение найти компромисс там, где 100% решения может не существовать; и потому рабочие навыки натягивания совы на глобус костылями в ЧГКшечке, скорее, мешают.
Да и IT в условиях дефицита времени - это какое-то очень неправильное IT.
А вот что хорошо тренируется и помогает в работе - это умение слышать "щелчок". Щелкает ответ - и ты понимаешь, что да, это оно, решение найдено. Так же и в коде - правильно построенная архитектура защелкивается, и наступает гармония и удовлетворенность проделанной работой.
Еще один резон играть в ЧГК - это смена контекста. Когда пилишь неделями один и тот же проект, надо иногда "прочищать чакры", чтобы посмотреть на проблему с другой стороны. И вот игра, как своеобразный вантуз для головы, подходит на эту роль достаточно хорошо.
Точка, из которой луч попадает в вершину, может являться результатом каких-то других вычислений. То есть в совсем общем случае я бы не гарантировал совпадения хотя бы одной из координат побитово (хотя в вашем продакшен случае это вполне может быть именно так).
А в случае обхода полигона надо тогда добавить шаг фильтрации, который будет выкидывать отрезки, длина которых сравнима с дельтой.
Про последний вопрос: видимо, тут разница в понимании того, как может быть задан полигон. Вы подразумеваете, что он задается подряд идущими сегментами: (A, B), (B, C), (C, D), ..., (Z, A). Но в общем случае полигон может быть задан как попало: (C, B), (A, B), ..., (A, Z), (D, C).
Массив отрезков, в общем случае, полигоном не является.
Портить координаты дельтой, действительно, не хорошо. Должно быть достаточно ввести некий 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();
}
Для обитателей рф это, наверное, дико, но:
С нормальным государством в случае нарушения договора оферты можно успешно судиться.
Каждый клиент является еще и акционером с правом голоса, поэтому совет директоров, как правило, всякую дичь творить не может (а если и может, то очень недолго).
А уж если гендиректор конторы облил все здание бензином, поджег и заперся у себя в кабинете - то, наверное, не стоит бегать со своим маленьким ведерком и здание тушить. Правильнее будет зафиксировать потери и распрощаться со своей ничего уже не стоящей акцией.
Мне в этих философских рассуждениях немного непонятна сакрализация государства как такового. Почему государство должно быть для гражданина чем-то большим, чем провайдером по предоставлению услуг (медицинских, правовых, охранных, и т.д.)?
Вот плачу я за интернет - и покуда он у меня есть, мне абсолютно фиолетово в крапинку на "целостность" организации, его предоставляющей. Ровно так же и провайдер думает (точнее не думает) про меня.
Аналогичная история и с государством: есть договор оферты в виде законодательной базы, есть абонентская плата за пользования услугами - налоги. И не нужны никакие брачные танцы в виде взаимной "заинтересованности" - достаточно обычных здоровых рыночных отношений.
Так что если качество предоставляемых услуг не соответствует заявленному уровню, то логичнее искать варианты, как провайдера поменять.
Например, "повторить"? :)
А почему кому-то это должно быть принципиально?
9 центов за КВт*ч - это "конские цены"?
И 165К за новую (!) трешку на >90 квадратов - много?
А вот то, что безумно жарко, дико скучно и аборигены бесят своим сига-сига - это да, тут ни почти бесплатная недвижимость, ни дешевое электричество не радуют.
Ну так 3.1 и 6 - слегка разные версии того же Core.
А вот 4.8 и 6 - это суть вообще разные фреймворки. Мы так один проект среднего размера примерно полгода переезжали.
Интересный вопрос, задумался. Сейчас мне кажется, что между IT и ЧКГ не так много общего, как изначально представлялось.
Постановка задачи в случае ЧГК предполагает наличие правильного ответа, что, в ряде ситуаций является жирной подсказкой (те же вопросы на школу). IT же, с другой стороны, - это инженерия, умение найти компромисс там, где 100% решения может не существовать; и потому рабочие навыки натягивания совы на глобус костылями в ЧГКшечке, скорее, мешают.
Да и IT в условиях дефицита времени - это какое-то очень неправильное IT.
А вот что хорошо тренируется и помогает в работе - это умение слышать "щелчок". Щелкает ответ - и ты понимаешь, что да, это оно, решение найдено. Так же и в коде - правильно построенная архитектура защелкивается, и наступает гармония и удовлетворенность проделанной работой.
Еще один резон играть в ЧГК - это смена контекста. Когда пилишь неделями один и тот же проект, надо иногда "прочищать чакры", чтобы посмотреть на проблему с другой стороны. И вот игра, как своеобразный вантуз для головы, подходит на эту роль достаточно хорошо.
"В какой квартире карточку получали - вот туда и идите!" (c) (tm)
Точка, из которой луч попадает в вершину, может являться результатом каких-то других вычислений. То есть в совсем общем случае я бы не гарантировал совпадения хотя бы одной из координат побитово (хотя в вашем продакшен случае это вполне может быть именно так).
А в случае обхода полигона надо тогда добавить шаг фильтрации, который будет выкидывать отрезки, длина которых сравнима с дельтой.
Про последний вопрос: видимо, тут разница в понимании того, как может быть задан полигон. Вы подразумеваете, что он задается подряд идущими сегментами: (A, B), (B, C), (C, D), ..., (Z, A). Но в общем случае полигон может быть задан как попало: (C, B), (A, B), ..., (A, Z), (D, C).
Нельзя :)
Во-первых, в реальной жизни полное равенство двух double - штука маловероятная. Собственно, поэтому тут везде дельта.
Во-вторых, а что такое "начало отрезка"?
И пока вы не ответили, спрошу еще: а что мешает иметь два отрезка, заданные как (A, B) и (A, C)?
Если слегка поревьювить:
Почему точки отрезка (Segment) мутабельные?
Массив отрезков, в общем случае, полигоном не является.
Портить координаты дельтой, действительно, не хорошо.
Должно быть достаточно ввести некий tolerance для сравнения вещественных чисел.
Ну и само это сравнение вынести в отдельный метод, не размазывая по коду.
Кстати, как эта "порча" должа помочь избежать двойного зачета точки, если портятся абсолютно все точки полигона?
Наверное, в статье есть много интересных, полезных и здравых мыслей.
Но вот это вот "юмор внутри команды перетекает в троллинг, а троллинг – в травлю" в самом начале отбивает всякое желание читать дальше.
Извините, но это самое что ни на есть классическое "Сегодня он играет джаз, а завтра Родину продаст".
Да, для того, чтобы не обидеться на едкую шутку, нужен мозг. Но, вроде, у индивидов, идентифицирующих себя программистами, он должен в каком-то количестве присутствовать.
И давайте не забывать Стругацких: "Саваоф Баалович стал всемогущ. Он мог всё. И он ничего не мог. Потому что граничным условием уравнения Совершенства оказалось требование, чтобы чудо не причиняло никому вреда. Никакому разумному существу. Ни на Земле, ни в иной части Вселенной. А такого чуда никто, даже сам Саваоф Баалович, представить себе не мог."
Рассказывать про контейнеры и облака, делая фоточки экрана вместо скриншотов... Киберпанк, который мы заслужили. (:
PS. Еще и с битыми пикселями.
То есть вы вот такой пример предполагаете?
Так в этом случае оно даже не соберется в большинстве ЯП, потому что Box<Animal> не является супертипом для Box<Dog>. Чтобы оно заработало, вам надо явно указать вариантность.
А если "починить" проблему тем, что
то рано или поздно столкнемся с проблемой явного приведения типов при использовании, о которой я написал выше.
Как я понимаю автора, революции в программировании не случилось, есть эволюционное развитие.
И "один запрос на LINQ" внутри себя как раз и разворачивается в "if, циклы while и операторы присваивания".
В принципе, вам ничто не мешает взять какой-нибудь достаточно древний ЯП и забабахать LINQ на нем. В зависимости от древности и дубовости языка вам, конечно, придется пободаться с лямбдами и переизобретением expression trees - но на что-то принципиально нереализуемое вы вряд ли наткнетесь.
Да пример просто немножко странный, поэтому, кмк, идею он раскрывает не очень: технически, вы пытаетесь сделать анбоксинг значения супертипа с явным приведением его к одному из подтипов - и на основании этого делаете вывод, что LSP не работает. Хотя за такой код надо просто линейкой по рукам бить:
А мне ваше мнение интересно.
вообще никак к ООП не относятся.
строго говоря, к оригинальной идее ООП весьма перпендикулярны. Кроме того, не могли бы вы пояснить, как SOLID завязан на эту триаду?
Смущает. Но это то же самое, что говорить, будто молоток - это плохой инструмент, только потому что кто-то им палец отшиб.
А в комментариях затем разбирается ошибка в рассуждениях автора.
А что не так с LSP? Как по мне, в этой статье самое изящное изложение этого принципа из всех, что я слышал.
И во что у вас ООП мутировал, интересно?
Скорее, наоборот: нельзя не оскорбиться, если за это несложное действие маячит крайне внушительная сумма.
Как бы кто что ни говорил, но выгорать за достойную зарплату всё-таки лучше, чем за маленькую. :)