Кто мешает «гадить всем сразу», вызывая в разных потоках
Начинаем сначала:
The singleton pattern is a software design pattern that restricts the instantiation of a class to one object. This is useful when exactly one object is needed to coordinate actions across the system.
Определите какие границы вашей «the system» это процесс? Поток? запрос? Вот в этих рамках и ваяйте «restricts» и .«one object».
Файловый объект — в него не могут гадить все сразу, если требуется сохранить логческую целостность, иначе получается фарш.
Сокеты — не могут в него гадить все сразу, иначе логическая целостность будет нарушена с отправляющей стороны. и т.д.
Да, можно сказать, что «есть файловые дескрипторы, семафоры и т.д.». Но что мы видим? Тоже самое — экземпляры не создаются вызывающей стороной, они хранятся в недоступном вызывающей стороной месте, и есть API для управления экземплярами.
Есть же и другие способы ограничить количество экземпляров.
Какие? Пока все что показывалось, сводилось к «спрячем» инстанс и спрячем создание от вызывающей стороны. Сделаем менеджер доступа для вызывающей стороны и создания количества экземпляров.
Яркий пример, в многих книгах для чайников в синглтон заворачивают подключение к бд: и потом DB::getInstance и понеслась. Но потом появляется еще одна бд: то синглтон приходится выковыривать/рефакторить кучу кода.
Это называется — не предусмотрены точки расширения с точки зрения архитектуры.
Или ваш редактор уже может работать в виртуальной реальности или хотят бы может работать на паре платформ и паре CPU арихитектур? Нет? Код надо причесать под новые требования? Так у вас тоже косячексъ в архитектуре.
Если идиот забивает шуруп молотком в бетон, молоток то в чем виноват? В том что рядом оказался?
Почему-то вы ругаете инструмент, ссылаясь на последствия не корректного применения этого инструмента.
Вопрос в поставленной задаче и проектном ее решении, а не в конкретном варианте имплементации и тем более не корректном применении. Осталось только кривые шрифты приписать Singleton
Связь есть по времени.
В 1 день сделали прививку. Через 2 дня в роддоме младенец умирает. Это связь.
Логично. Человек прочитал про «вред прививок» и умер. через 10 лет. упал на лестнице и свернул шею или от рака.
Чтение статьи «вред прививок» сворачивает шею и вызывает рак. Связь есть по времени. Все логично…
Слушайте, если это добровольно, то зачем кричать про фальсифицированные прививки? Зачем они были нужны?
Выделили денег. Дежурная ТП захотела новую шубку или отдых на канарах, выела мозг своему мужу/любовнику, муж/любовник украл деньги на прививки. Бутылочки купили, водички налили, укольчик «прививкой» сделали, люди умерли. Зачем кричать про «фальфификацию» если все ясно и «виновата прививка», а не отсутсвие мозгов :)))
Когда я говорю про затраты работодателя — то имею в виду
1. Использование непроверенных методологий несет дополнительные риски. Их оценки я не увидел
2. Освоение этих технологий стоит денег. Ориентировочно — в районе одного человекомесяца.
3. Пока идет освоение — страдают другие проекты и этот не движется с места
С каких пор RUP не проверенная методолгия? начало 200х была известна.
Что значит «дополнительные риски»? Риски есть всегда, вопрос цены рисков, стратегии их обработки или отказа.
Что значит «освоени методологии»? или ты понимашеь что делаешь и зачем или нет. Ресурсам — задачи и сама мотодология им побоку в общем случае.
Не движется с места «куда»? Все работы играли ту или иную роль. Все работы играли на руку подрядчику. Все предварительные работы должны быть проведены или подрядчик просто попадает на штрафы из-за не выполненных условий договора.
Работа РМ — идентифицировать цели проекта, оценить риски, выбрать методолгию управления проектом и адаптировать под цели клиента. Уж после думать про всякие ресурсы/capacity management, communication plan и прочее.
Или вы полагаете, что нужно быть тупо подписать контракт без юридической защиты и без предварительной оценки? смешно.
Вас ранее просили дать конкретный пример, когда Singleton хорошо подходит.
Я упоминал, например взаимодействие с внешней системой, когда порядок действий и состояние важны. Например транзакционная система в многопоточной среде. Попробуйте реализацию журналирования и странзакциоонности для файловой системы, для примера.
У меня есть анти-пример.
Пичалька. Небольшой косяк имплементации, не предусмотрели «Feature Extensions» Если бы не было лень, было бы что-то типа:
// не будем придираться к shared_ptr/_com_ptr_t :)
IConfig *pConfig = Config::getInstance();
после вопрос «выпилить» не стоял бы так остро.
Но вопрос то не об этом.
Разберите Singleton на части и что там обнаружится?
Защищенное хранилище экземпляра класса, к каком-то контексте.
Механизм доступа к защищенному экземпляру класса
Логика, поверяющая наличие экземпляра класса в хранилище.
Создание экземпляра класса в контексте п1
Запрет создание экземпляра класса ЗА пределами контекста п1
Если рассмотрим предлагаемые ранее решения, вместо «плохого» Singleton в одном классе, то обнаружим, что:
пункт 1, переносится из класса, в какое-то другой клас или вспомогательной библиотеки. (опустим многопоточность и Thread-local storage)
пункт 2, переносится из класса, на уровень библиотеки классов
пункт 3, переносится из класса, на уровень вспомогательной библиотеки/контейнера
пункт 4, переносится из класса, на уровень вспомогательной библиотеки/контейнера
пункт 5, переносится из класса, на уровень хз?.. допустим вспомогательной библиотеки/контейнера.
Но вот незадача… Контейнер и библитека класса исполняются в контексте бизнес логики, иначе контейнер на сможет создать экземпляр класса.
Если задача, в том, что бы «prevents», то нужно их как-то изолировать друг от друга, что бы BL никак не могла напрямую создать экземпляр класса.
В конечном итоге, относительно контекста бизнес-логики, «навороченное решение» с контейнерами-фабриками-инъекциями-виски-стриптизершами выглядит точно также, как и «простое», делающее то-же самое.
Те-же яйца, только в профиль.
Пока я вижу, не смотря на все ухищрения, просто отрицание задачи/формулировки, для которой создан Singleton.
Изоляция компонентов хорошо? Да хорошо.
IoC / DI это хорошо? Да хорошо.
Хреновый дизайн плохо? да плохо.
Такое вот «абсолютно тоже самое с абсолютно одинаковым результатом».
Рассматривалось в контекте одноразововой ситуации «File->New».
Возвращает реализацию любого интерфейса, самостоятельно определяя подходящую фабрику среди зарегистрированных
Дайте я угадаю. Эту фабрику нужно будет предварительно создать через new или придется где-то дергать метод типа Resolve? Откуда ее экземпляр появится ?
Теперь для понимания реальных зависимостей класса вместо имени, интерфейсов и параметров конструктора (единицы строк, обычно две) надо читать весь его код (от десятков до десятков тысяч строк).
Что вы прицепились к бедному конструктору? Я уже показал что инъектить можно через «любую дырку» (хоть в private members, хотя и не одобряю такую практику). Религиозных «Шаблонных» запретов на это нет.
Во вторых — с какого перепугу лопатить «тысячи строк»? Если у вас такой CodeStyle — можно попробовать привести его в порядок.
Теперь обычные классы зависят от конкретного контейнера и не могут быть переиспользованы без него.
Что-то подобное я вам указывал выше насчет сервисных/низкоуровневых библиотек, и т.д.
Код в юнит тестах требует использования контейнеров и неочевидной их конфигурации, что самым пагубным образом сказывается на его качестве.
Это было просто «мысли в слух». И зачем же так грубо «использовать» контейнер, и люди, обычно, не идиоты и могут переиспользовать существющий функционал. Есть всякие обертки/адаптеры — так что это не та проблема, что требует космических усилий для разрешения.
Определитесь с понятием «Single responsibility», на какой контекст распростроняется? На атомарную функция? кусок функционала покрыващий некоторый набор требования?
Если вы вас так раздражает Singleton, давайте «померяем» вашими мерками IoС. Он окажется еще более «ужасен» — мало того, что обладает функционалом создавать экземпляры классов, «ковыряться» в чужих классах что бы инъектить, ковыряться" в чужих классах что бы дергать фабрики, должен приводит типы, так эта «зараза» еще и… следит за количеством экземпялов класса ?!
Одну ужасную штуку, мы заменили еще более ужасной! О ужас!
Пока я вижу один аргумент:
Трактовка «In software engineering, the singleton pattern is a software design pattern that restricts the instantiation of a class to one object. » — это просто не правильное желание разработчиков. Они были идиотами, сформулировав такую задачу и еще большими идиотами, что использовали такой вариант решения.
Да, нюанс «restricts» — создает массу проблем, но увы, его надо реализовать. Все решения — административное в виде «review» или «спрятать имплементация, показать интерефейс», не выполнимы на каком-то из уровней имплементации и решают поставленную задачу частично, переносится «Singleton» и «restricts» из самого класса в какое-то иное место в каком-то классе, наделяя его или не свойтственными функциями, тем самым нарушая SRP в другом классе.
Не важно, решает ли pattern задачу, и тем более не важно какой ценой. Главное не отступить от Религиозных Шаблонов Проектирования.
Только, похоже вы забыли одну маленькую деталь. Design Patterns — это не набор Канонов и Истина. Это просто… инженерный подход, для повторного использования решений уже известных проблем, похожий на бинарные библиотеки или исходный код. Только тут повторное использование на уровне Проблема-Проектное решение. Поэтому они и называются Design Patterns — шаблоны проектирования.
Software design pattern
In software engineering, a software design pattern is a general reusable solution to a commonly occurring problem within a given context in software design.
В Kanban, в его космическом варианте, выполненная задача не ждёт выполнения остальных задач для её релиза, она сразу идёт релизится.
Никакого космоса, это вполне реально. На мой взгляд, все сводится к двум вещам: как сделать задачку поменьше и как выкатить её побыстрее.
Имелось ввиду, что «родители» этих методологий разные, вышли они из разных «источников» и решали задачи в условиях разного приоритета одних и тех же требований. Вроде как не имеет смысла поставить ядерный реактор на подпорках в первой итерации а потом обкладывать бетоном.
ИТ — просто адаптировал под себя методологии, ища наиболее удобную и технологически реализуемую. Вот развитие и привело к «развертыванию по комиту». Но опять-же, скорость адаптации бизнеса и людей в нем- конечна, и менять по 3 раза в день логику и UI не самое разумное.
Берем фабрику и «обучаем» ее создавать нужные экземпляры классов.
Берем контейнер, конфигуриуем его создавать нужные экземпляры классов.
Хотим возвращает интерфейсы, хотим — классы. Не суть важно.
Оба механизма делают абсолютно тоже самое с абсолютно одинаковым результатом.
Только что бы согласно «концепции» иньектить интерфейс фабрики, вместо интерфейса контейнера? Отличие в концептуальной «чистоте ?» Если не видно разницы, зачем платить больше?
В пятой версии начиная со страницы 417 «Приложение А1 Стандарт управления проектом»
Далее идет расшифровка понятия «стандарт». Опять же в контексте — соблюдение повышает шансы успеха, но не гарантирует их.
Стандарт как ... руководящие принципы или характеристики продуктов, процессов и услуг, для общего и постоянного использования, соответствие которым не является обязательным
Международная организация по стандартизации (International Organization for Standartization, ISO) и другие организации определяют стандарт как «документ, одобренный признанным учреждением, устанавливающий правила, руководящие принципы или характеристики продуктов, процессов и услуг, для общего и постоянного использования, соответствие которым не является обязательным». (ISO/IEC 2:2004) [11]
Данный стандарт описывает суть процессов управления проектом с точки зрения интеграции процессов, их
взаимодействия и целей, которым они служат.
В классическом представления каждая фаза проекта соответствует одному типу работ.
Давно читал RUP. в «детстве» :) В начале 200х. Не сильно впечатлил. Но что вынес из всего этого — умей сам себе собрать «framemework» под проект. Да и Agile практики тогда начали развиваться, так что спланировать и скоординировать типы работ «в нахлест» и итерации проблем не было. Вопросы с инструментарием поддержать все это.
я Заказчиков, с которыми не везёт, не беру.
Мне, чаще приходилось разгребаться с «оставь надежду всяк сюда входящий» :)
Начинаем сначала:
The singleton pattern is a software design pattern that restricts the instantiation of a class to one object. This is useful when exactly one object is needed to coordinate actions across the system.
Определите какие границы вашей «the system» это процесс? Поток? запрос? Вот в этих рамках и ваяйте «restricts» и .«one object».
С 6:15 на видео можно глянуть технические детали.
Сокеты — не могут в него гадить все сразу, иначе логическая целостность будет нарушена с отправляющей стороны. и т.д.
Да, можно сказать, что «есть файловые дескрипторы, семафоры и т.д.». Но что мы видим? Тоже самое — экземпляры не создаются вызывающей стороной, они хранятся в недоступном вызывающей стороной месте, и есть API для управления экземплярами.
Какие? Пока все что показывалось, сводилось к «спрячем» инстанс и спрячем создание от вызывающей стороны. Сделаем менеджер доступа для вызывающей стороны и создания количества экземпляров.
Есть такое. Но у БД их сколько?
Это вы объясните строителя нового космодрома, строителям футбольного стадиона зенит, зимней олимпиаде в субтропиках и т.д. А то «мужики то не знают»…
Это называется — не предусмотрены точки расширения с точки зрения архитектуры.
Или ваш редактор уже может работать в виртуальной реальности или хотят бы может работать на паре платформ и паре CPU арихитектур? Нет? Код надо причесать под новые требования? Так у вас тоже косячексъ в архитектуре.
Если идиот забивает шуруп молотком в бетон, молоток то в чем виноват? В том что рядом оказался?
Почему-то вы ругаете инструмент, ссылаясь на последствия не корректного применения этого инструмента.
Вопрос в поставленной задаче и проектном ее решении, а не в конкретном варианте имплементации и тем более не корректном применении. Осталось только кривые шрифты приписать Singleton
Логично. Человек прочитал про «вред прививок» и умер. через 10 лет. упал на лестнице и свернул шею или от рака.
Чтение статьи «вред прививок» сворачивает шею и вызывает рак. Связь есть по времени. Все логично…
Выделили денег. Дежурная ТП захотела новую шубку или отдых на канарах, выела мозг своему мужу/любовнику, муж/любовник украл деньги на прививки. Бутылочки купили, водички налили, укольчик «прививкой» сделали, люди умерли. Зачем кричать про «фальфификацию» если все ясно и «виновата прививка», а не отсутсвие мозгов :)))
С каких пор RUP не проверенная методолгия? начало 200х была известна.
Что значит «дополнительные риски»? Риски есть всегда, вопрос цены рисков, стратегии их обработки или отказа.
Что значит «освоени методологии»? или ты понимашеь что делаешь и зачем или нет. Ресурсам — задачи и сама мотодология им побоку в общем случае.
Не движется с места «куда»? Все работы играли ту или иную роль. Все работы играли на руку подрядчику. Все предварительные работы должны быть проведены или подрядчик просто попадает на штрафы из-за не выполненных условий договора.
Работа РМ — идентифицировать цели проекта, оценить риски, выбрать методолгию управления проектом и адаптировать под цели клиента. Уж после думать про всякие ресурсы/capacity management, communication plan и прочее.
Или вы полагаете, что нужно быть тупо подписать контракт без юридической защиты и без предварительной оценки? смешно.
Я упоминал, например взаимодействие с внешней системой, когда порядок действий и состояние важны. Например транзакционная система в многопоточной среде. Попробуйте реализацию журналирования и странзакциоонности для файловой системы, для примера.
Пичалька. Небольшой косяк имплементации, не предусмотрели «Feature Extensions» Если бы не было лень, было бы что-то типа:
// не будем придираться к shared_ptr/_com_ptr_t :)
IConfig *pConfig = Config::getInstance();
pConfig->getBgColor();
pConfig->getDefaultMargins();
после вопрос «выпилить» не стоял бы так остро.
Но вопрос то не об этом.
Разберите Singleton на части и что там обнаружится?
Если рассмотрим предлагаемые ранее решения, вместо «плохого» Singleton в одном классе, то обнаружим, что:
Но вот незадача… Контейнер и библитека класса исполняются в контексте бизнес логики, иначе контейнер на сможет создать экземпляр класса.
Если задача, в том, что бы «prevents», то нужно их как-то изолировать друг от друга, что бы BL никак не могла напрямую создать экземпляр класса.
В конечном итоге, относительно контекста бизнес-логики, «навороченное решение» с контейнерами-фабриками-инъекциями-виски-стриптизершами выглядит точно также, как и «простое», делающее то-же самое.
Те-же яйца, только в профиль.
Пока я вижу, не смотря на все ухищрения, просто отрицание задачи/формулировки, для которой создан Singleton.
Изоляция компонентов хорошо? Да хорошо.
IoC / DI это хорошо? Да хорошо.
Хреновый дизайн плохо? да плохо.
Рассматривалось в контекте одноразововой ситуации «File->New».
Дайте я угадаю. Эту фабрику нужно будет предварительно создать через new или придется где-то дергать метод типа Resolve? Откуда ее экземпляр появится ?
Что вы прицепились к бедному конструктору? Я уже показал что инъектить можно через «любую дырку» (хоть в private members, хотя и не одобряю такую практику).
Религиозных«Шаблонных» запретов на это нет.Во вторых — с какого перепугу лопатить «тысячи строк»? Если у вас такой CodeStyle — можно попробовать привести его в порядок.
Что-то подобное я вам указывал выше насчет сервисных/низкоуровневых библиотек, и т.д.
Это было просто «мысли в слух». И зачем же так грубо «использовать» контейнер, и люди, обычно, не идиоты и могут переиспользовать существющий функционал. Есть всякие обертки/адаптеры — так что это не та проблема, что требует космических усилий для разрешения.
Определитесь с понятием «Single responsibility», на какой контекст распростроняется? На атомарную функция? кусок функционала покрыващий некоторый набор требования?
Если вы вас так раздражает Singleton, давайте «померяем» вашими мерками IoС. Он окажется еще более «ужасен» — мало того, что обладает функционалом создавать экземпляры классов, «ковыряться» в чужих классах что бы инъектить, ковыряться" в чужих классах что бы дергать фабрики, должен приводит типы, так эта «зараза» еще и… следит за количеством экземпялов класса ?!
Одну ужасную штуку, мы заменили еще более ужасной! О ужас!
Пока я вижу один аргумент:
Трактовка «In software engineering, the singleton pattern is a software design pattern that restricts the instantiation of a class to one object. » — это просто не правильное желание разработчиков. Они были идиотами, сформулировав такую задачу и еще большими идиотами, что использовали такой вариант решения.
Да, нюанс «restricts» — создает массу проблем, но увы, его надо реализовать. Все решения — административное в виде «review» или «спрятать имплементация, показать интерефейс», не выполнимы на каком-то из уровней имплементации и решают поставленную задачу частично, переносится «Singleton» и «restricts» из самого класса в какое-то иное место в каком-то классе, наделяя его или не свойтственными функциями, тем самым нарушая SRP в другом классе.
Не важно, решает ли pattern задачу, и тем более не важно какой ценой. Главное не отступить от
РелигиозныхШаблонов Проектирования.Только, похоже вы забыли одну маленькую деталь. Design Patterns — это не набор Канонов и Истина. Это просто… инженерный подход, для повторного использования решений уже известных проблем, похожий на бинарные библиотеки или исходный код. Только тут повторное использование на уровне Проблема-Проектное решение. Поэтому они и называются Design Patterns — шаблоны проектирования.
А куда вы включаете «критерии приемки», сценарии приемо-сдаточных испытаний?
Имелось ввиду, что «родители» этих методологий разные, вышли они из разных «источников» и решали задачи в условиях разного приоритета одних и тех же требований. Вроде как не имеет смысла поставить ядерный реактор на подпорках в первой итерации а потом обкладывать бетоном.
ИТ — просто адаптировал под себя методологии, ища наиболее удобную и технологически реализуемую. Вот развитие и привело к «развертыванию по комиту». Но опять-же, скорость адаптации бизнеса и людей в нем- конечна, и менять по 3 раза в день логику и UI не самое разумное.
Делается что-то вроде:
class MyDummyLogic
{
//@Inject
//[Inject]
public IIoc MyIoC{get;set;}
public void MyNewEntyty()
{
MyEntity entity = this.MyIoC.Resolve(MyEntity);
}
}
или
class MyDummyLogic
{
//@Inject
//[Inject]
public IMyFabric MyFabric{get;set;}
public void MyNewEntyty()
{
MyEntity entity = this.MyFabric.CreateEntity();
}
}
Откуда берутся глобалы-то? Зачем?
Берем контейнер, конфигуриуем его создавать нужные экземпляры классов.
Хотим возвращает интерфейсы, хотим — классы. Не суть важно.
Оба механизма делают абсолютно тоже самое с абсолютно одинаковым результатом.
Только что бы согласно «концепции» иньектить интерфейс фабрики, вместо интерфейса контейнера? Отличие в концептуальной «чистоте ?» Если не видно разницы, зачем платить больше?
Осталость выбрать между «не правильными» вариантами :)
Далее идет расшифровка понятия «стандарт». Опять же в контексте — соблюдение повышает шансы успеха, но не гарантирует их.
Данный стандарт описывает суть процессов управления проектом с точки зрения интеграции процессов, их
взаимодействия и целей, которым они служат.
Давно читал RUP. в «детстве» :) В начале 200х. Не сильно впечатлил. Но что вынес из всего этого — умей сам себе собрать «framemework» под проект. Да и Agile практики тогда начали развиваться, так что спланировать и скоординировать типы работ «в нахлест» и итерации проблем не было. Вопросы с инструментарием поддержать все это.
Мне, чаще приходилось разгребаться с «оставь надежду всяк сюда входящий» :)