Синглтон создает объект один раз, определенным образом инициируя внутреннее состояние объекта. Если ваш статический класс тоже позволяет настроить внутреннее состояние один единственный раз при первом обращении, то это и есть синглтон, просто чуть иначе реализованный.
Синглтон может быть реализован (условно, конечно) и в процедурном коде, без ООП.
Допустим удалённо отключили АВ, psexec«ом подсунули keylogger как у автора в статье — все пароли шустро перегнали себе.
В реальности будет keylogger настроенный именно на KeyPass со всеми хитростями. И пароли шустро перегонят к себе. Почему вы расчитываете на использование взломщиком исключительно примитивных инструментов широкого профиля?
Нет смысла расчитывать на сценарий, когда взломщик at the other end of airtight hatch как частенько говорит Раймонд Чен.
Да, если защита хитра, это займет больше времени или помешает злоумышленнику. Но только если он пользуется чем-то универсальным, скажем, обычным логгером. Если он нацелен именно на пароли, хранимые этой утилитой, то и софт его будет заточен под ее хитрости.
Вы не можете передавать/внедрять аргументы в конструктор. Поскольку при первом вызове синглтона реально исполняется только конструктор и вы не можете знать заранее, какой код первым обратится к синглтону, то во всём потребляющем коде нужно использовать один и тот же набор аргументов для передачи в конструктор, что во многих случаях почти невыполнимо, а вначале вообще бессмысленно. В результате синглтон делает бесполезным основной механизм инстанцирования в ООП-языках.
Это весьма странная претензия. Сиглтон используется тогда, когда объект, который им инстанцируется, максимально универсален. Если нам при вызове из точки А надо настраивать объект (передавая параметры в коснтруктор) вот так, а при вызове из точки Б — иначе, то синглтон здесь неприменим, нам надо 2 инстанса с разными «настройками».
Вы не можете имитировать (mock away) синглтон при тестировании компонентов, использующих его
Это зависит от конкретного языка и фреймворка для тестирования.
То есть, как бы вы ни пытались изолировать синглтон в инкапсулированной части кода, любой другой внешний код может привести к побочным эффектам и багам в синглтоне. А без надлежащей инкапсуляции выхолащиваются сами принципы ООП.
Потому что сиглтон-объект не должен иметь не-потокобезопасного внутреннего state'а, ни побочных эффектов.
Если у вас когда-либо был сайт или приложение, разросшееся настолько, что синглтону DatabaseConnection неожиданно понадобилось подключение ко второй, отличной от первой базе данных, значит, вы в беде. Придётся заново пересмотреть саму архитектуру и, возможно, полностью переписать значительную часть кода.
Точно так же будет и с не-синглтоном: вам придется написать какой-нибудь ConnectionList или ConnectionPool, и получать из него конкретный DatabaseConnection, который будет «синглтоном», или обычным объектом в зависимости от конкретных требований.
Это опять же странная претензия — «если нам потребуется что-то сильно изменить, нам надо будет что-то сильно изменить».
Есть такая штука: разбиение метода на два и более.
Если вам хочется назвать метод более чем 3-мя словами, то либо у вас словесный понос, либо ваш метод делает слишком много одновременно и нарушает хотя бы принцип единственной ответственности (single responsibility).
Не в этом дело.
Это редкие случаи, но вполне реальные. Я сейчас не буду искать по коду эти редкие случаи, вот синтетический пример: у вас есть метод, извлекающий из коллекции элемент по некоему идентификатору целочисленного типа. И еще один метод, извлекающий элемент по целочисленному идентификатору, но другому.
Соответственно, у ва сбудет метод ExtractItemByID (например), и, условно, ExtractItemByOriginalID
Если разбивать методы дроблением до совершенно малых, то теряется логика работы, как хорошо их ни назови. Более того, придется называть наоборот, более многословно, чтобы пояснить, что же именно вот этот абстрактный оторванный от жизни кусок делает; тогда как в норме это была бы часть другого, более крупного метода и не нуждалась бы в пояснениях ни через комментарии, ни через название в силу наличия контекста.
Когда требуется делать сокращения (например, полное имя идентификатора состоит из слов так 5-6), пишу пояснение в том месте, где происходит объявление. Чтобы человек, читающий код, понимал мою «логику сокращений».
А потом то, что написал правообладатель, и что MacIn выше назвал «мусором»:
Для статьи вида «смотрите какой странный код попадается» это действительно мусор. Здесь обсуждается алгоритм и его некорректное применение. Авторство кода автор хабрастатьи не оспорил, вы загоняетесь и передергиваете. Если вас смущает распространение кода, помеченного как proprietary и confidential, то тогда непонятна претензия по поводу отсутствия этой пометки в статье: что, от того что вставят p&c, пропадет распространение confidential кода? Тут уж точно противоречие — вы определитесь с тем, что именно вас смущает.
Абсолютно. Автор статьи на хабре не приписывал себе авторство кода, ссылка на полную версию (под оригиналом я имел в виду неурезанную версию) присутствует.
Это не кусок, это и есть весь код по ссылке. За исключением копирайта.
Потому что он — ненужный для статьи мусор. Это частный случай, когда модуль короток и весь — чистый шик и блеск. Было бы это 10 строк из 1000 — было бы то же самое.
Dura lex, sed lex. Какими «мусорными» бы законы не были, их надо соблюдать.
Автор статьи не приписал себе авторство и оставил ссылку на оригинал. Все корректно.
Нет никакого противоречия. Вы пишете статью, демонстрируя что-то кодом. Зачем вам весь код, особенно мусорные шапки, которые только отвлекают? Незачем. Вы взяли кусок, оставили ссылку на автора и оригинальный репозиторий — авторские права соблюдены: никто себе авторство кода не приписал.
или, что хуже, чужих opensource-проектов, создавая совершенно ненужные риски их владельцам. What has been seen cannot be unseen.
Если они скопипастят код прямо с хабра, да еще такой, то поделом.
Не только в этом.
Картина маслом (лет 8 назад, вроде не поменялось ничего): въезжаешь ты в РФ на машине. Срок временного ввоза автомашины — 14 дней, если будешь дольше, надо оформлять продление временного ввоза на срок не более срока визы.
Теперь внимание: приходишь в таможню, как обычно, работает 1 окно с 13:15 до 14:00 строго по четвергам, учитывая, что сегодня — пятница. Ждешь неделю, та-дам — да, это гостребование. Да, вы должны. Но мы с физиками не работаем, ищите таможенного брокера. Вон там есть фирма по соседству, обычно они делают. Ну и фирмочка на пустом месте поднимает тысячи 2 рублей, за вычетом пошлины.
Дело не в партии, даже один предмет — уже повод. Просто на деле на это никто не смотрит.
Вот я свободный человек, поехал за границу, приглянулся ноут. Ну тогда пусть обкладывают меня налогом и за шлепанцы. На трусы-то я чеков тоже с собой не вожу. И как это они меня «поймают»?
ЕМНИП, есть разграничение на т.н. личные вещи, в которые входят как раз трусы-зубные пасты-щлепанцы и такие вещи, как оргтехника. Ну, раньше так было по крайней мере.
По поводу размера партии частенько бывают подзаконные акты, которые указывают в цифрах. У нас, например, шоколад нормируется — до Х плиток и Х кг — личное, свыше — товарная партия. И если ты любишь шоколад прям вот не можешь и ввозишь 10 плиток — всем пофиг на то, что ты — сладкоежка, будешь платить налог, растамаживать или сдашь под опись на границе.
Или писал не программист, а то ли математик, то ли железячник.
Знаете, как в анекдоте про математиков — как вскипятить чайник? Если чайник пустой, налить в него воды, включить плиту и т.д. А если чаник полный? Тогда вылить воду и тем самым задача сводится к уже известной, решение которой приведено выше.
Синглтон может быть реализован (условно, конечно) и в процедурном коде, без ООП.
Можно формировать пароли по какому-то алгоритму, но разные, по контексту. взламываться они будут так же как и совершенно различные.
В реальности будет keylogger настроенный именно на KeyPass со всеми хитростями. И пароли шустро перегонят к себе. Почему вы расчитываете на использование взломщиком исключительно примитивных инструментов широкого профиля?
Да, если защита хитра, это займет больше времени или помешает злоумышленнику. Но только если он пользуется чем-то универсальным, скажем, обычным логгером. Если он нацелен именно на пароли, хранимые этой утилитой, то и софт его будет заточен под ее хитрости.
Это весьма странная претензия. Сиглтон используется тогда, когда объект, который им инстанцируется, максимально универсален. Если нам при вызове из точки А надо настраивать объект (передавая параметры в коснтруктор) вот так, а при вызове из точки Б — иначе, то синглтон здесь неприменим, нам надо 2 инстанса с разными «настройками».
Это зависит от конкретного языка и фреймворка для тестирования.
Потому что сиглтон-объект не должен иметь не-потокобезопасного внутреннего state'а, ни побочных эффектов.
Точно так же будет и с не-синглтоном: вам придется написать какой-нибудь ConnectionList или ConnectionPool, и получать из него конкретный DatabaseConnection, который будет «синглтоном», или обычным объектом в зависимости от конкретных требований.
Это опять же странная претензия — «если нам потребуется что-то сильно изменить, нам надо будет что-то сильно изменить».
Не в этом дело.
Это редкие случаи, но вполне реальные. Я сейчас не буду искать по коду эти редкие случаи, вот синтетический пример: у вас есть метод, извлекающий из коллекции элемент по некоему идентификатору целочисленного типа. И еще один метод, извлекающий элемент по целочисленному идентификатору, но другому.
Соответственно, у ва сбудет метод ExtractItemByID (например), и, условно, ExtractItemByOriginalID
Если разбивать методы дроблением до совершенно малых, то теряется логика работы, как хорошо их ни назови. Более того, придется называть наоборот, более многословно, чтобы пояснить, что же именно вот этот абстрактный оторванный от жизни кусок делает; тогда как в норме это была бы часть другого, более крупного метода и не нуждалась бы в пояснениях ни через комментарии, ни через название в силу наличия контекста.
Допустим, некая функция извлекает элемент определенным образом, так что просто ExtractItem недостаточно внятное название.
Для статьи вида «смотрите какой странный код попадается» это действительно мусор. Здесь обсуждается алгоритм и его некорректное применение. Авторство кода автор хабрастатьи не оспорил, вы загоняетесь и передергиваете. Если вас смущает распространение кода, помеченного как proprietary и confidential, то тогда непонятна претензия по поводу отсутствия этой пометки в статье: что, от того что вставят p&c, пропадет распространение confidential кода? Тут уж точно противоречие — вы определитесь с тем, что именно вас смущает.
Потому что он — ненужный для статьи мусор. Это частный случай, когда модуль короток и весь — чистый шик и блеск. Было бы это 10 строк из 1000 — было бы то же самое.
Автор статьи не приписал себе авторство и оставил ссылку на оригинал. Все корректно.
Если они скопипастят код прямо с хабра, да еще такой, то поделом.
Картина маслом (лет 8 назад, вроде не поменялось ничего): въезжаешь ты в РФ на машине. Срок временного ввоза автомашины — 14 дней, если будешь дольше, надо оформлять продление временного ввоза на срок не более срока визы.
Теперь внимание: приходишь в таможню, как обычно, работает 1 окно с 13:15 до 14:00 строго по четвергам, учитывая, что сегодня — пятница. Ждешь неделю, та-дам — да, это гостребование. Да, вы должны. Но мы с физиками не работаем, ищите таможенного брокера. Вон там есть фирма по соседству, обычно они делают. Ну и фирмочка на пустом месте поднимает тысячи 2 рублей, за вычетом пошлины.
Дело не в партии, даже один предмет — уже повод. Просто на деле на это никто не смотрит.
ЕМНИП, есть разграничение на т.н. личные вещи, в которые входят как раз трусы-зубные пасты-щлепанцы и такие вещи, как оргтехника. Ну, раньше так было по крайней мере.
По поводу размера партии частенько бывают подзаконные акты, которые указывают в цифрах. У нас, например, шоколад нормируется — до Х плиток и Х кг — личное, свыше — товарная партия. И если ты любишь шоколад прям вот не можешь и ввозишь 10 плиток — всем пофиг на то, что ты — сладкоежка, будешь платить налог, растамаживать или сдашь под опись на границе.
Знаете, как в анекдоте про математиков — как вскипятить чайник? Если чайник пустой, налить в него воды, включить плиту и т.д. А если чаник полный? Тогда вылить воду и тем самым задача сводится к уже известной, решение которой приведено выше.