За ней скрывается фреймворк, который детально описан в стандарте PMI (PMBoK).
В PM Book ничего не расписано, никаких frameworks там нету.
Там только набор «Best Practice» и первым абзацем там написано:
Руководство PMBOK® выделяет ту часть Свода знаний по управлению проектами, которая обычно считается хорошей практикой.
«Хорошая практика» не означает,однако, что описываемые знания должны всегда одинаковым образом применяться ко всем проектам; организация команда управления проектом самостоятельно определяет применимость этих знаний к тому или иному проекту
1.1 Цель Руководства PMBOK®
Повсеместное признание, которое завоевывает управление проектами, является показателем того, что применение соответствующих знаний, процессов, навыков, инструментов и методов может иметь решающее значение для проекта. Руководство PMBOK® выделяет ту часть Свода знаний по управлению проектами, которая обычно считается хорошей практикой. «Обычно считается» означает, что описываемые знания и практики применимы к большинству проектов в большинстве случаев, причем относительно их значения и пользы существует консенсус. «Хорошая практика» означает, в целом существует согласие относительно того, что правильное применение этих знаний, навыков, инструментов и методов способно повысить вероятность успеха для широкого диапазона различных проектов. «Хорошая практика» не означает, однако, что описываемые знания должны всегда одинаковым образом применяться ко всем проектам; организация команда управления проектом самостоятельно определяет применимость этих знаний к тому или иному проекту.
А фазы, что вы указали для RUP присутсвуют в любом проекте, вопрос в каком виде.
Вам повезло, что заказчик уже побегал по граблям и согласился на вменяемый бизнес-анализ, что позволило вам адекватно оценить риски и принять меры к их понижению (через грамотное планирование, в первую очередь).
RUP тут, играл такую же весомую роль, как бумага на которой печатался контракт :)
Поэтому рекомендую освоить нотации IDEFx на основе Structured Analysis and Design Technique (книга на русском).
IDEFx штука не плохая, но… несколько неудобная и ракообразная, на мой взгляд.
Многое из того что вы описываете является просто проявлениями культуры и социальных отношений. Не всё то что является социальным поведением или обучением — импринтинг.
Возможно, пока это просто побочный эффект. Если предположить, что сам канал передачи в состоянии развития, например к телепатии.
Или наоборот, канал получился настолько хорош, что самая важная функция, до периода размножения выполнив свою основную работу усвоения критической информации, после остается «открыта» для усвоения и генерации другой информации.
Если цель выживание не отдельной особи, а некой группы, то после усвоения основной информации этот канал выгодно использовать для повышения выживаемости группы ускорив передачу информации типа «широковещательная передача» повысив скорость реакции на новые раздражители в процессе жизни сообщества или отдельного человека.
Просто метод Resolve используется вместо фабрики и возвращает готовый собранный объект, котороый просто может быть использован в точке File->New/Open.
В этом прелесть контейнеров IoC :) И следствие, как Вы, правильно заметили: Рай для unit-тестирования.
А все остальные этим НЕ занимаются, в том числе НЕ вызывают конструкторы своих зависимостей и НЕ вызывают никаких методов Resolve.
Я такое никогда не утверждал, возможно, вы не корректно поняли.
Я так-же упоминал, что дергают конструкторы или контейнеры внутри себя при разрешении зависимостей или могут использовать экземпляры классов созданные вне контейнеров в точке конфигурации.
Поэтому и упомянул «Посмотрите как нибудь исходники контейнеров за фасад «магии».»
По какой-то причине, вы настойчиво указываете «наверх» приложения, где-то в районе бизнес-логики и выше. Я же предлагал попробовать посмотреть «под капот»: внутрь IoC контейнеров которые реализуют DI, внутрь тех библиотек, которые предоставляют классы для IoC контейнеров, внутрь тех библиотек, которые просто запускают приложение внутри ОС и т.д.
Там немного другие приоритеты к требованиям.
Те же требования к производительности, к памяти, к 100% предсказуемости поведения приложения когда и что будет создано и уничтожено. Или по вашему «абстрации» абсолютно бесплатная штука?
А предлагал посмотреть на фундамент здания, а вы мне упорно показываете планировку квартиры в этом здании.
Свая здания и ножка стола в квартие делают одно и тоже, но приоритет требований к ним разный.
Этот тезис противоречит DI по построению. Согласно DI класс не занимается композицией своих зависимостей, в том числе никогда не создает их сам.
Мы подразумеваем одно и то-же под DI?
Dependency injection
In software engineering, dependency injection is a technique whereby one object supplies the dependencies of another object. Dependency_injection
Forms of Dependency Injection
The basic idea of the Dependency Injection is to have a separate object, an assembler, that populates a field in the lister class with an appropriate implementation for the finder interface, resulting in a dependency diagram along the lines of Figure 2 injection
Обычный класс, спроектированный в соответствии с DI, никакими контейнерами не пользуется, а получает свои зависимости в параметрах конструктора.
В общем случае этот принцип называется
InversionOfControl
Inversion of Control is a common phenomenon that you come across when extending frameworks. Indeed it's often seen as a defining characteristic of a framework.
А DI — это механизм в рамках реализаци IoC. Наверное, стоит их разделять :)
Вроде нет такого «религиозного канона» :) Куда хочешь, туда и передавай свои зависисмости: хочешь через конструктор (Constructor Injection), хочешь через свойства или методы(Setter Injection/ Interface Injection).
Другое дело, что через конструктор контролировать чуть проще, так контейнеры и должны обеспечивают корректную передачу/инъекцию.
Настолько узкого, что вы до сих пор не привели ни одного примера, где синглтон был бы лучшей альтернативой.
Никто не спрашивал :)
Работа с эксклюзивными ресурсами или критическими к порядку операций и глобальным состоянием внешнего ресурса/сервиса.
Вы будете привязывать свою служебную низкоуровневую библиотеку к какому-то удобному и популярному сейчас контейнеру? А потом будете в бизнес-приложении пытаться разрулить это «фарш»? Или вы свое бизнес приложение будете подстравивать под весь зоопарк контейнеров которые используют служебные библиотеки?
Сложно придумать способ побольнее «выстрелить себе в ногу».
Это вообще не DI, а известный антипаттерн Service Locator.
Посмотрите как нибудь исходники контейнеров за фасад «магии».
И этот вопрос должен быть решен на уровне контекста исполнения, а не класса.
Технически такие экземпляры классов и находятся на уровне контекста исполнения :) без промежуточных «подпорок».
Но весь смысл DI в том, чтобы избавить клиентский код от отвественности за инстанциирование объектов.
И да и нет.
Дело в том, что инициализировать сам DI можно как указав тип и класс, так и уже созданный экземпляр класса. Для самого механизма DI это в общем случае без разницы.
Что-то типа:
DI.Init(ITargetTypeInterface, ClassType, LifeCyrcleScope.Singleton);
и
DI.Init(ITargetTypeInterface, new ClassType(), LifeCyrcleScope.Singleton);
а после просто дергать 1. ITargetTypeInterface temp = DI.Resolve(ITargetTypeInterface)
или
2. ITargetTypeInterface temp = new ClassType()
...
temp.Fn(bla bla bla);
Вот п2 вы не можете проконролировать, без «Решение в том, что клиентский код даже не знает что писать после new. У него физически нет доступа к имплементации интерфейса.» и/или «Review»
Это специфические решение. Для узкого круга задач.
Если делаете библиотеку, то API на интерфейсах однозначно проще и универсальнее.
Это не отрицается. Вопрос не в наличи интерфесов или абстрактных классах, а в количестве экземплятров класса в каком-то контексте исполнения.
В любом случае существует пространство в коде, где будет доступно new() для класса, что бы получить интерфейс. Не важно в каком именно. По всему приложению, или классе конфигурирования DI, в ресолвере, в отдельной служебной библиотеке и т.д.
И в этом пространстве нет способа запретить использовать new() однократно и соответветсенно насоздавать кучу экземпляров.
Решение в том, что клиентский код даже не знает что писать после new. У него физически нет доступа к имплементации интерфейса.
Фактически, изоляция new() переносится с уровня класса и одного метода, на уровень библиотеки. Вместо одной точки «накосячить» в классе ( и то минимально), мы размазываем возможность «накосячить» по всей библиоткеке или приложению.
А после — привлекать каких-то тестеров и специфические тесты, ревьюверов, организовать дополнительный «check list» и т.д. что бы это все вручную «предотвращать».
Заболел человек корью, его спрашивают: «Прививку делал от кори?». Ответы записывают, потом публикуют цифры. Всё.
… слов нет.
Дальше следуют вопросы типа:
— а когда делали?
— а кто делал?
— а какая прививка? штамм/название/производитель
и эти данные должны быть валидируемы.
К сожалению. если бы у каждого на руках был личная мед-карта электронная с заверенной зелекронной подписью больницы записями — ваш подход был бы очень корректен.
Но пока чисто, организационно, это невозможно.
По построению: никто, кроме точки сборки, не имеет даже ссылок на библиотеку со столь оберегаемым классом.
Т.е никаких технических решение вы не предлагаете, как гарантировать уникальность экземляра класса в рамках какого-то контекста исполнения. Для этого вам нужны какие-то дополнительные администативные мероприятия, выходящие за рамки чисто технического решения.
Вас не смущает, что вы не можете решить техническую задачу, техническими средствами?
Возможно Ваше решение не подходит к задаче? Или вы просто пытаетесь «ремонтировать» то, что работает, просто не поняв назначение?
Как по мне, так это похоже на человека с молотком, которому везде мерещятся гвозди и он первый раз в жизни увидев шуруп, решил просто посильнее молотком ударить. Ну это тоже вариант решения.
Т.е. В приложении у вас получается: куча интерфейсов, наличие публичного конструктора классов, иначе DI механизм просто не заработает, обязательное использование DI.
Возвращаемся к вопросам выше:
как применение DI гарантирует, что нигде кроме DI не будет вызван new () для класса, который должен быть в единственном экземпляре в рамках одного контекста (одного потока, нескольких потоков, процесса) ?
Какими конкретно техническими приемами буду обеспечены гарантии, не зависимо от архитектуры решения (язка программирования, платформы, применяемых инструментариев) ?
Если у вас уже есть универсальных ограничитель числа экземпляров для любого класса, зачем еще какой-то дополнительный «запрет»?
Банально: new Singleton() в ненужном месте должен вызывать ошибку уровня компилятора и принудительно от программиста требовать использовать иных методов.
Это, банально, дешевле и быстрее, чем гонять кучу тестов а потом искать «плавающие» баги.
Я больше скажу — такие классы давно уже есть. Не в курсе конкретно про iOS но свои аналоги Lazy и DI-контейнеры на львиной доле популярных платформ 99% существуют и активно используются.
От спасибо… порадовали старика, а то маразм забывать стал :)
Контейнер может как-то защитить от банального вызова «new» не там где нужно?
Т.е вы полагаете что DI и контейнеры как-то «магически» создают классы заведомо правильно? программист не может накосячить в жизненном цикле? или сам контейнер не может накосячить?
Страшно далека от любой другой функциональности класса.
А какая еще функциональность у этого класса?
Находится на заведомо неверном уровне абстракции: количество экземпляров — вопрос использования класса другим кодом, а не его проектирования.
Т.е вы предлагаете сделать специальный класс, который будет обеспечивать требуемое количество экземпляров в количестве одной штуки? Допустим.
Осталось решить проблему — Запретить создавать более чем одного экземпляра.
Требует каждый раз думать о зависимостях и многопоточности, плюс копипастить вместо использования готовых инструментов.
Если бы многопоточность была самой большой проблемой в этом :). Это Вы еще многопроцессность забыли.
Т.е формально, Singleton разбирвается на следующий перечень задач:
Создание экземпляра класса как такового (new… )
Запрет/контроль создания экземпляров класса
Инициализация экземпляра класса (constructor )
Предоставление экземпляра класса (GetInstance() )
Безопастность уничтожения экземпляра класса (delete… / IDispose / Finally / ~ destructor / & etc)
Безопастность создания экземпляра класса для многпоточного и многопроцессного применения
Безопастность инициализации экземпляра класса для многопоточного и многопроцессного применения
Безопастность уничтожения экземпляра класса для многопоточного и многопроцессного применения
Судя по вашей логике — понятие Single у Вас это атомарные функции? Может стоит «без фанатизма»?
Небольшое дополнение:
Не очень понятно откуда это письмо «Письмо Роспотребнадзора от 27.06.2005 № 0100/4853-05-32 «ОБ ИТОГАХ ПРОВЕДЕНИЯ МАССОВОЙ ИММУНИЗАЦИИ НАСЕЛЕНИЯ РОССИЙСКОЙ ФЕДЕРАЦИИ ПРОТИВ ДИФТЕРИИ В 2004 ГОДУ» взялось.
На сайте роспотребнадзора материалы по дифиерии от 2012 года и приказ от 1998 года как самые ранние.
Можно ознакомиться с интересным документом
За последние 10 лет число поствакцинальных осложнений (ПВО) снизилось существенно:
За последние 10 лет число поствакцинальных осложнений (ПВО) снизилось существенно: если в 2006-2012 гг. число их составляло около 500-600 ежегодно, то 2015 году зарегистрировано 202 случая, а за 10 месяцев 2016 года — 164 неблагоприятных события в поствакцинальном периоде. Причем, в пересчете на количество сделанных прививок (более 110,6 млн. ежегодно)
частота возникновения ПВО в 2015 г. составила всего 1 на 550 тыс.прививок.
В PM Book ничего не расписано, никаких frameworks там нету.
Там только набор «Best Practice» и первым абзацем там написано:
Повсеместное признание, которое завоевывает управление проектами, является показателем того, что применение соответствующих знаний, процессов, навыков, инструментов и методов может иметь решающее значение для проекта. Руководство PMBOK® выделяет ту часть Свода знаний по управлению проектами, которая обычно считается хорошей практикой. «Обычно считается» означает, что описываемые знания и практики применимы к большинству проектов в большинстве случаев, причем относительно их значения и пользы существует консенсус. «Хорошая практика» означает, в целом существует согласие относительно того, что правильное применение этих знаний, навыков, инструментов и методов способно повысить вероятность успеха для широкого диапазона различных проектов. «Хорошая практика» не означает, однако, что описываемые знания должны всегда одинаковым образом применяться ко всем проектам; организация команда управления проектом самостоятельно определяет применимость этих знаний к тому или иному проекту.
А фазы, что вы указали для RUP присутсвуют в любом проекте, вопрос в каком виде.
Вам повезло, что заказчик уже побегал по граблям и согласился на вменяемый бизнес-анализ, что позволило вам адекватно оценить риски и принять меры к их понижению (через грамотное планирование, в первую очередь).
RUP тут, играл такую же весомую роль, как бумага на которой печатался контракт :)
IDEFx штука не плохая, но… несколько неудобная и ракообразная, на мой взгляд.
Возможно, пока это просто побочный эффект. Если предположить, что сам канал передачи в состоянии развития, например к телепатии.
Или наоборот, канал получился настолько хорош, что самая важная функция, до периода размножения выполнив свою основную работу усвоения критической информации, после остается «открыта» для усвоения и генерации другой информации.
Если цель выживание не отдельной особи, а некой группы, то после усвоения основной информации этот канал выгодно использовать для повышения выживаемости группы ускорив передачу информации типа «широковещательная передача» повысив скорость реакции на новые раздражители в процессе жизни сообщества или отдельного человека.
Просто метод Resolve используется вместо фабрики и возвращает готовый собранный объект, котороый просто может быть использован в точке File->New/Open.
В этом прелесть контейнеров IoC :) И следствие, как Вы, правильно заметили: Рай для unit-тестирования.
Я такое никогда не утверждал, возможно, вы не корректно поняли.
Я так-же упоминал, что дергают конструкторы или контейнеры внутри себя при разрешении зависимостей или могут использовать экземпляры классов созданные вне контейнеров в точке конфигурации.
Поэтому и упомянул «Посмотрите как нибудь исходники контейнеров за фасад «магии».»
По какой-то причине, вы настойчиво указываете «наверх» приложения, где-то в районе бизнес-логики и выше. Я же предлагал попробовать посмотреть «под капот»: внутрь IoC контейнеров которые реализуют DI, внутрь тех библиотек, которые предоставляют классы для IoC контейнеров, внутрь тех библиотек, которые просто запускают приложение внутри ОС и т.д.
Там немного другие приоритеты к требованиям.
Те же требования к производительности, к памяти, к 100% предсказуемости поведения приложения когда и что будет создано и уничтожено. Или по вашему «абстрации» абсолютно бесплатная штука?
А предлагал посмотреть на фундамент здания, а вы мне упорно показываете планировку квартиры в этом здании.
Свая здания и ножка стола в квартие делают одно и тоже, но приоритет требований к ним разный.
Мы подразумеваем одно и то-же под DI?
Dependency_injection
injection
В общем случае этот принцип называется
Вроде нет такого «религиозного канона» :) Куда хочешь, туда и передавай свои зависисмости: хочешь через конструктор (Constructor Injection), хочешь через свойства или методы(Setter Injection/ Interface Injection).
Другое дело, что через конструктор контролировать чуть проще, так контейнеры и должны обеспечивают корректную передачу/инъекцию.
Никто не спрашивал :)
Работа с эксклюзивными ресурсами или критическими к порядку операций и глобальным состоянием внешнего ресурса/сервиса.
Вы будете привязывать свою служебную низкоуровневую библиотеку к какому-то удобному и популярному сейчас контейнеру? А потом будете в бизнес-приложении пытаться разрулить это «фарш»? Или вы свое бизнес приложение будете подстравивать под весь зоопарк контейнеров которые используют служебные библиотеки?
Сложно придумать способ побольнее «выстрелить себе в ногу».
Посмотрите как нибудь исходники контейнеров за фасад «магии».
Технически такие экземпляры классов и находятся на уровне контекста исполнения :) без промежуточных «подпорок».
Задачи противоположные по смыслу:
DI — обязанность создавать экземпляры.
Singleton — запрет создания экземпляров.
Если будет написано:
import/include PuperDI;
import/include MyCode;
DI di = new PuperDI.DI();
di.Init (..., MyCode.MySingleton, ...)
... = PuperDI.DI.Resolve(MyCode.MySingleton).Fn();
будет меньше зависимостей чем от:
import/include MyCode;
... = MyCode.MySingleton.GetInstance().Fn();
?
Вы серьезно полагаете, что на DI свет клином сошелся и если его не использовать, то небо на замлю упадет?
Рассматривайте Singleton как ответственный за запрет кому либо создавать свои экземпляры.
Есть разница между «не нужно знать» и «не иметь возможности»
Весь мир состоит только в клиентском коде или есть другие слои? :)
И да и нет.
Дело в том, что инициализировать сам DI можно как указав тип и класс, так и уже созданный экземпляр класса. Для самого механизма DI это в общем случае без разницы.
Что-то типа:
DI.Init(ITargetTypeInterface, ClassType, LifeCyrcleScope.Singleton);
и
DI.Init(ITargetTypeInterface, new ClassType(), LifeCyrcleScope.Singleton);
а после просто дергать
1. ITargetTypeInterface temp = DI.Resolve(ITargetTypeInterface)
или
2. ITargetTypeInterface temp = new ClassType()
...
temp.Fn(bla bla bla);
Вот п2 вы не можете проконролировать, без «Решение в том, что клиентский код даже не знает что писать после new. У него физически нет доступа к имплементации интерфейса.» и/или «Review»
Это специфические решение. Для узкого круга задач.
Это не отрицается. Вопрос не в наличи интерфесов или абстрактных классах, а в количестве экземплятров класса в каком-то контексте исполнения.
В любом случае существует пространство в коде, где будет доступно new() для класса, что бы получить интерфейс. Не важно в каком именно. По всему приложению, или классе конфигурирования DI, в ресолвере, в отдельной служебной библиотеке и т.д.
И в этом пространстве нет способа запретить использовать new() однократно и соответветсенно насоздавать кучу экземпляров.
Фактически, изоляция new() переносится с уровня класса и одного метода, на уровень библиотеки. Вместо одной точки «накосячить» в классе ( и то минимально), мы размазываем возможность «накосячить» по всей библиоткеке или приложению.
А после — привлекать каких-то тестеров и специфические тесты, ревьюверов, организовать дополнительный «check list» и т.д. что бы это все вручную «предотвращать».
Это тоже решение. Оно имеет право на жизнь.
Значит не сталкивались.
«Ревью» разве не административное решение?
Я не очень понимаю, как дальше рассматривать «не существующую проблему» и ее решения.
… слов нет.
Дальше следуют вопросы типа:
— а когда делали?
— а кто делал?
— а какая прививка? штамм/название/производитель
и эти данные должны быть валидируемы.
К сожалению. если бы у каждого на руках был личная мед-карта электронная с заверенной зелекронной подписью больницы записями — ваш подход был бы очень корректен.
Но пока чисто, организационно, это невозможно.
Т.е никаких технических решение вы не предлагаете, как гарантировать уникальность экземляра класса в рамках какого-то контекста исполнения. Для этого вам нужны какие-то дополнительные администативные мероприятия, выходящие за рамки чисто технического решения.
Вас не смущает, что вы не можете решить техническую задачу, техническими средствами?
Возможно Ваше решение не подходит к задаче? Или вы просто пытаетесь «ремонтировать» то, что работает, просто не поняв назначение?
Как по мне, так это похоже на человека с молотком, которому везде мерещятся гвозди и он первый раз в жизни увидев шуруп, решил просто посильнее молотком ударить. Ну это тоже вариант решения.
Возвращаемся к вопросам выше:
Не будем далеко зазить в дебри. Возмем классику
на куче языков и на любой вкус.
Т.е у вас везде и всегда будут интерфейсы. Допустим.
Из этого возникает вопрос: кто и когда будет вызвать new()?
Не могли бы вы пояснить а «копипасты» чего? Откуда и куда? Сколько не пользовал Singleton ничего никуда не копировал. Может мы о разных говорим?
Банально: new Singleton() в ненужном месте должен вызывать ошибку уровня компилятора и принудительно от программиста требовать использовать иных методов.
Это, банально, дешевле и быстрее, чем гонять кучу тестов а потом искать «плавающие» баги.
От спасибо… порадовали старика, а то маразм забывать стал :)
Контейнер может как-то защитить от банального вызова «new» не там где нужно?
Т.е вы полагаете что DI и контейнеры как-то «магически» создают классы заведомо правильно? программист не может накосячить в жизненном цикле? или сам контейнер не может накосячить?
ну ну…
А какая еще функциональность у этого класса?
Т.е вы предлагаете сделать специальный класс, который будет обеспечивать требуемое количество экземпляров в количестве одной штуки? Допустим.
Осталось решить проблему — Запретить создавать более чем одного экземпляра.
Если бы многопоточность была самой большой проблемой в этом :). Это Вы еще многопроцессность забыли.
Т.е формально, Singleton разбирвается на следующий перечень задач:
Судя по вашей логике — понятие Single у Вас это атомарные функции? Может стоит «без фанатизма»?
Не очень понятно откуда это письмо «Письмо Роспотребнадзора от 27.06.2005 № 0100/4853-05-32 «ОБ ИТОГАХ ПРОВЕДЕНИЯ МАССОВОЙ ИММУНИЗАЦИИ НАСЕЛЕНИЯ РОССИЙСКОЙ ФЕДЕРАЦИИ ПРОТИВ ДИФТЕРИИ В 2004 ГОДУ» взялось.
На сайте роспотребнадзора материалы по дифиерии от 2012 года и приказ от 1998 года как самые ранние.
Можно ознакомиться с интересным документом
частота возникновения ПВО в 2015 г. составила всего 1 на 550 тыс.прививок.
Ну и этот доумент