Либо надо менять этот пункт — про отношение общества к меньшинствам и (особенно) к специалистам
Странное совмещение. К специалистам — верно, решения должны приниматься на основе доводов компетентных граждан. А в отношении меньшинств как таковых — с какой стати?
Это уже зависит от сложности взлома одного отдельного пароля. Если он достаточно криптостойкий, то можно исключить эту угрозу, как маловероятную. Как всегда — баланс между двумя величинами. Удобством и безопасностью в данном случае.
Полтора крипто-калеки не в счет. В массе — нет.
А так-то можно сказать, что и оружие, и наркотики в продаже есть. Ну, можно же достать, если постараться.
Для меня это выглядит как «надстройка», дополнительная задача, тогда как основная — знание библиотеки. Вещи вроде «javax.servlet.GenericServlet и, стало быть, у него не может быть только методов с HttpServletRequest'ом» — как раз оно самое. Сугубо imho.
Можно и не так — просто заранее создать битовую маску закраски. 320/8 = 40; 40*200 ~~ 8Кб. Маска создается с определенными условиями — скажем, в старших 4 и младших 4 битах должно быть от 1 до 2 единиц. Потом закрашиваем экран последовательно 3 раза подряд, каждый раз сдвигая эти маски. Если единица была в крайнем левом разряде, то к 3й закраске она будет в крайней правой позиции, что гарантированно закрасит все пиксели. А уж то, что некоторые закрасятся по нескольку раз — не имеет значения. Хотя, в принципе, это не сильно будет отличаться от предложенного метода со сдвиговым регистром, не считая заранее подготовленных данных. Но просто, как вариант навскидку, если неизвестно свойство сдвигового регистра с ОС генерировать последовательность по кругу.
Где как. У нас про собственно сдвиг речь шла только при изучении языка ассемблера x86, про сдвиговые регистры — на «организации ЭВМ», «архитектуре ЭВМ». Как таковая тема ГПСЧ не присутствовала.
Здорово, отличная идея, спасибо за статью.
В лоб пришло бы на ум все же использовать монте-карло — ГПСЧ с постепенным увеличением кол-ва генерируемых пар. Но это даже без прикидок очевидно слишком затратное по ресурсам решение.
С одной стороны — да, но с другой — советская форма демократии все же позволяет получать мнение с низов — всех во всех советах не обработаешь. Плюс не забываем про принцип отзыва своих депутатов.
Вы банду четырех читали? Это проблема синглтона как такового по определению. Он делает что-то полезное (1) и контролирует число своих экземпляров (2).
Это в общем случае тоже некорректно.
«Синглтон» — это, на минутку, шаблон проектирования. Шаблон по определению не может делать что-то полезное или что-то контролировать. Он лишь рамки, алгоритм, общие принципы, по которым будет написан участок кода.
Если мы хотим, чтобы некий класс X инстанцировался ровно единожды, и применяем шаблон синглтон для этого, то делать что-то полезное будет новый инстанс этого класса. А вот контроллировать число может и не класс X. Это может быть другой класс со статичным методом или вовсе функция, если язык позволяет. Заниматься «чем-то полезным» будет instance класса, создавать его (ровно единожды) — совсем другая сущность. И каждая из них будет иметь ровно single responsibility. А в целом это будет по-прежнему шаблон синглтон.
Универсальный объект, не позволяющий себя параметризовать самым простым способом? Ограничивающий число экземпляров единицей?
Это полная противоположность универсальности.
Отнюдь. Параметризация необязательно является необходимым качеством универсальности. Напротив, универсальный предмет одинаково применим к другим без дополнительного указания параметров. Например — молоток. В единственном экземпляре. Универсальный инструмент, можно применить как для забивания гвоздя, так и для отбивания пальца. При этом его не надо «параметризовать» — вот сейчас мы будем забивать гвоздь, а вот сейчас — бить по пальцу. Параметризовав его, мы создали бы не универсальный, а напротив, специализированный инструмент.
С требованиями по отсутствию состояния и многопоточной инициализации?
Я не говорил, что не должно быть состояния или многопоточной инициализации. Я сказал, что код должен быть потокобезопасным и не иметь побочных эффектов.
Видите ли, при использовании DI ничего сильно изменять не придется. Использование разных экземпляров в разных контекстах само по себе требует сильных изменений только в легаси или в коде недостаточно квалифицированного разработчика.
Это относится к разработке самого объекта, а не к синглтону как таковому.
monkey patch ради тестов — это тоже антипаттерн. С параметрами конструктора такой проблемы нет в принципе.
Во-первых, я не согласен с тем, что это антипаттерн. Во-вторых, почему monkey patch? Обычный mock можно применить и для тестирования синглтона. Зависит от конкретного языка.
Проблему инициализации можно решить множеством способов. Мы решали немного нестандартно — при первом инклюде файла. Он же подключается автолоудом и только один раз.
Это сильно завязано на особенности того или иного языка. А синглтон как паттерн — «интернационален».
Странное совмещение. К специалистам — верно, решения должны приниматься на основе доводов компетентных граждан. А в отношении меньшинств как таковых — с какой стати?
Это никак не противоречит упомянутому принципу общественного договора. Государство — плод такого договора.
А так-то можно сказать, что и оружие, и наркотики в продаже есть. Ну, можно же достать, если постараться.
Первая — отличная задачка на соображалку, вторая — на тупое запоминание документации.
В лоб пришло бы на ум все же использовать монте-карло — ГПСЧ с постепенным увеличением кол-ва генерируемых пар. Но это даже без прикидок очевидно слишком затратное по ресурсам решение.
Это в общем случае тоже некорректно.
«Синглтон» — это, на минутку, шаблон проектирования. Шаблон по определению не может делать что-то полезное или что-то контролировать. Он лишь рамки, алгоритм, общие принципы, по которым будет написан участок кода.
Если мы хотим, чтобы некий класс X инстанцировался ровно единожды, и применяем шаблон синглтон для этого, то делать что-то полезное будет новый инстанс этого класса. А вот контроллировать число может и не класс X. Это может быть другой класс со статичным методом или вовсе функция, если язык позволяет. Заниматься «чем-то полезным» будет instance класса, создавать его (ровно единожды) — совсем другая сущность. И каждая из них будет иметь ровно single responsibility. А в целом это будет по-прежнему шаблон синглтон.
Это совершенно разные фразы, а не «в точности то же самое».
Отнюдь. Параметризация необязательно является необходимым качеством универсальности. Напротив, универсальный предмет одинаково применим к другим без дополнительного указания параметров. Например — молоток. В единственном экземпляре. Универсальный инструмент, можно применить как для забивания гвоздя, так и для отбивания пальца. При этом его не надо «параметризовать» — вот сейчас мы будем забивать гвоздь, а вот сейчас — бить по пальцу. Параметризовав его, мы создали бы не универсальный, а напротив, специализированный инструмент.
Я не говорил, что не должно быть состояния или многопоточной инициализации. Я сказал, что код должен быть потокобезопасным и не иметь побочных эффектов.
Это относится к разработке самого объекта, а не к синглтону как таковому.
Во-первых, я не согласен с тем, что это антипаттерн. Во-вторых, почему monkey patch? Обычный mock можно применить и для тестирования синглтона. Зависит от конкретного языка.
Это сильно завязано на особенности того или иного языка. А синглтон как паттерн — «интернационален».