Значение делегировать: ДЕЛЕГИРОВАТЬ — это… Что такое ДЕЛЕГИРОВАТЬ?

ДЕЛЕГИРОВАТЬ — это… Что такое ДЕЛЕГИРОВАТЬ?

Настройка делегирования в Skype для бизнеса Online и устранение неполадок — Skype for Business Online

• Статья
• 08/28/2021
• Чтение занимает 4 мин

• Применяется к:

  Skype for Business

Оцените свои впечатления

Да Нет

Хотите оставить дополнительный отзыв?

Отзывы будут отправляться в корпорацию Майкрософт. Нажав кнопку «Отправить», вы разрешаете использовать свой отзыв для улучшения продуктов и служб Майкрософт. Политика конфиденциальности.

Отправить

В этой статье

Важно!

Поддержка Skype для бизнеса Online прекратится 31 июля 2021 г. Если до этой даты пользователи Skype для бизнеса Online не будут переведены в Microsoft Teams, для них будет автоматически запланирован переход с помощником. Если вы хотите самостоятельно обновить организацию до Teams, настоятельно рекомендуем начать планирование пути обновления уже сегодня. Необходимо помнить, что успешный переход требует и технической подготовки, и подготовки пользователей, поэтому для подготовки перехода на Microsoft Teams обязательно воспользуйтесь нашим руководством по обновлению.

В этой статье объясняется, как настроить и устранить неполадки Skype для бизнеса делегирования в Интернете. В этой статье вы можете получить рекомендации по настройке, рекомендациям и шагам по устранению неполадок.

Рекомендации и требования

Рекомендации по делегирования

Настройка и получение правильной работы делегирования зависят от следующих рекомендаций:

• Вы должны использовать клиент Skype для бизнеса 2015 с последними обновлениями или клиент Skype для бизнеса 2016.

• Необходимо использовать клиент Outlook 2013 с последними обновлениями или Outlook 2016 клиента.

• Убедитесь, что у компьютеров представителя и делегатов есть один профиль Outlook, который является основным или профилем по умолчанию. Этот профиль должен содержать только одну учетную запись.

• Skype для бизнеса представителем должно быть пользователь Online. Кроме того, Exchange Server почтовые ящики для каждой учетной записи должны быть либо в сети, либо оба они должны быть локально.

• Как представитель, так и представитель должны использовать один и тот же основной Outlook.

• Значение атрибута EnableExchangeDelegateSync должно иметь значение true в клиентской политике. Вы можете проверить этот параметр, задав командлет Get-CSClientPolicy в модуле Skype для бизнеса Online PowerShell.

• Как представитель, так и представитель должны быть одновременно Skype для бизнеса и Outlook на разных рабочих станциях.

• Общие почтовые ящики не поддерживаются для делегирования Skype для бизнеса в Интернете. Это потому, что у общего почтового ящика нет списка управления доступом к отправителю.

Skype для бизнеса версии клиента

Требования к лицензированию

Enterprise Сценарий лицензирования E3

Enterprise Сценарий лицензирования E5

Настройка и проверка делегирования

Чтобы настроить делег Skype для бизнеса в Интернете, выполните следующие действия:

Для Windows клиентов

Вкладка «Переад вызовы»

1. Выберите > Инструменты > Параметры Переад Параметры.

2. Выберите Изменить участников-делегатов.

3. Выберите Добавить, выберите делегата, который вы хотите добавить, а затем выберите ОК.

Вкладка «Не переадваровка зовите»

1. В Outlook выберите Учетная > запись Параметры > делегировать доступ > добавить.

2. Найдите и добавьте имя человека, который будет делегатом.

3. Выберите меню Календарь, а затем — Редактор (может читать, создавать и изменять элементы).

Для клиентов Mac — Lync

Вкладка «Переад вызовы»

• Если у клиента нет вкладки «Переадстройка зовов» со ссылкой Изменить участников-делегатов, а представитель находится на компьютере Mac, то для того чтобы настроить делегирование, представитель должен войти на Windows на компьютере на базе Windows. Это потому, что клиенты Mac не могут устанавливать подключения MAPI, и это необходимо для Skype для бизнеса делегирования Outlook.

Проверка успешности

Если настройка прошла успешно, делегат должен увидеть сообщение Вы были добавлены в качестве делегата < Имя>, а также о том, что создана группа «Люди, которые управляют звонками для». Делегат должен увидеть, что создана группа Делегаты.

Примечание

Разрешения делегирования обычно появляются в течение 30 минут после настройки. Однако этот процесс может занять до 24 часов.

Устранение неполадок

Распространенные проблемы

• Проблема 1 Запись представителя по-прежнему будет отображаться в группе Люди, которые управляют звонками, после того как представитель удалил делегата из Outlook клиента.

  • Разрешение 1 В клиенте Skype для бизнеса щелкните правой кнопкой мыши делегата в группе Представители и выберите удалить из группы.

• Проблема 2 После предоставления делегатского доступа через клиента Outlook ни подтверждение, ни группа «Люди, управление звонками для которых я» не отображаются для делегата.

  • Разрешение 2 Удалите делегирование из Outlook, подождите около 15 минут для репликации, а затем снова добавьте представителя.

Другие распространенные проблемы

• Делегирования не работают, если превышено пороговое значение в 25 представителей и 25 делегатов.

• Клиент Skype для бизнеса Basic не поддерживается.

  Примечание

  Если вы установите клиент Skype для бизнеса Basic, делегирования будут удаляться и разрываться.

• Если значение СОСТОЯНИЕ MAPI не ОК, убедитесь, что значения SIP и SMTP совпадают.

  Примечание

  Состояние MAPI отображается как ОК после первого Skype для бизнеса и Outlook.

• Создание группы безопасности и добавление для нее разрешений делегирования не поддерживается.

• MapI недоступен. См. сообщение об ошибке MAPI в Skype для бизнеса 2016.

• Почтовый Exchange Online будет недоступн через Skype для бизнеса клиента. В этом случае запустите проверку Outlook подключения, чтобы убедиться, что он прошел.

Настройка Skype для бизнеса Online

Разрешение на добавление контактов Skype пользователям Skype для бизнеса

Получить ключ делегирования пользователя | Microsoft Docs

• Статья
• 08/25/2021
• Чтение занимает 4 мин

Оцените свои впечатления

Да Нет

Хотите оставить дополнительный отзыв?

Отзывы будут отправляться в корпорацию Майкрософт. Нажав кнопку «Отправить», вы разрешаете использовать свой отзыв для улучшения продуктов и служб Майкрософт. Политика конфиденциальности.

Отправить

Спасибо!

В этой статье

Get User Delegation KeyОперация получает ключ, который можно использовать для подписания подписки на делегирование безопасности пользователя (подписанный URL-адрес). SAS делегирования пользователя предоставляет доступ к ресурсам в службе Blob-объектов с помощью учетных данных Azure Active Directory (Azure AD). Эта Get User Delegation Key операция доступна в версии 2018-11-09 и более поздних версиях.

Запрос

Построение Get User Delegation Key выполняется следующим образом. Требуется использование протокола HTTPS. Замените myaccount именем своей учетной записи хранения.

URI службы эмулированного хранилища

При построении запроса к службе локального хранилища укажите локальное имя узла и порт службы BLOB-объектов 127.0.0.1:10000, затем имя учетной записи локального хранилища.

дополнительные сведения см. в разделе использование Emulator служба хранилища Azure для разработки и тестирования.

Параметры URI

В URI запроса могут быть заданы следующие дополнительные параметры.

Заголовки запросов

В следующей таблице перечислены обязательные и необязательные заголовки запросов.

Текст запроса

Далее приведен формат текста запроса.

<?xml version="1.0" encoding="utf-8"?>  
<KeyInfo>  
    <Start>String, formatted ISO Date</Start>
    <Expiry>String, formatted ISO Date </Expiry>
</KeyInfo>  

В следующей таблице описываются элементы текста запроса.

Ответ

Ответ включает код состояния HTTP и набор заголовков ответа.

Код состояния

Успешная операция возвращает код состояния 200 (ОК).

Сведения о кодах состояния см. в разделе состояние и коды ошибок.

Заголовки откликов

Ответ для этой операции включает следующие заголовки. Ответ может также включать дополнительные стандартные заголовки HTTP. Все стандартные заголовки соответствуют спецификации протокола HTTP/1.1.

Текст ответа

Текст ответа имеет следующий формат:

<?xml version="1.0" encoding="utf-8"?>
<UserDelegationKey>
    <SignedOid>String containing a GUID value</SignedOid>
    <SignedTid>String containing a GUID value</SignedTid>
    <SignedStart>String formatted as ISO date</SignedStart>
    <SignedExpiry>String formatted as ISO date</SignedExpiry>
    <SignedService>b</SignedService>
    <SignedVersion>String specifying REST api version to use to create the user delegation key</SignedVersion>
    <Value>String containing the key signature</Value>
</UserDelegationKey>

В следующей таблице описаны элементы текста ответа.

Авторизация

Субъект безопасности, запрашивающий ключ делегирования пользователя, должен иметь соответствующие разрешения. Субъект безопасности Azure AD может быть пользователем, группой, субъектом-службой или управляемым удостоверением.

чтобы запросить ключ делегирования пользователя, участнику безопасности должно быть назначено действие Microsoft. служба хранилища/сторажеаккаунтс/блобсервицес/женератеусерделегатионкэй . следующие встроенные роли RBAC включают действие Microsoft. служба хранилища/сторажеаккаунтс/блобсервицес/женератеусерделегатионкэй либо явно, либо как часть определения с подстановочным знаком:

так как Get User Delegation Key операция действует на уровне учетной записи хранения, действие Microsoft. служба хранилища/сторажеаккаунтс/блобсервицес/женератеусерделегатионкэй должно быть ограничено уровнем учетной записи хранения, группой ресурсов или подпиской. если участнику безопасности назначена любая из перечисленных выше встроенных ролей или пользовательская роль, включающая действие Microsoft. служба хранилища/сторажеаккаунтс/блобсервицес/женератеусерделегатионкэй на уровне учетной записи хранения, группы ресурсов или подписки, субъект безопасности сможет запросить ключ делегирования пользователя.

если участнику безопасности назначена роль, которая разрешает доступ к данным, но ограничивается уровнем контейнера, можно дополнительно назначить роль делегирования больших двоичных объектов служба хранилища этому субъекту безопасности на уровне учетной записи хранения, группы ресурсов или подписки. роль делегирования больших двоичных объектов служба хранилища предоставляет субъекту безопасности разрешения на запрос ключа делегирования пользователя.

дополнительные сведения о ролях RBAC для служба хранилища Azure см. в разделе авторизация с помощью Azure Active Directory.

Remarks

Используйте ключ делегирования пользователя, чтобы создать SAS для делегирования пользователей. Включите поля, возвращаемые в ответе, Get User Delegation Key в маркере SAS для делегирования пользователя. Дополнительные сведения о создании SAS для делегирования пользователей см. в разделе Создание SAS для делегирования пользователей.

Ключ делегирования пользователя не может использоваться для прямого доступа к ресурсам в службе BLOB-объектов.

См. также

Технология делегирования: как правильно делегировать. Мнение Дениса Вертелецкого.: Денис Вертелецкий. | HR

В психологии существует такое понятие, как состояние потока, то есть полной поглощенности деятельностью. Это характеризуется концентрацией на вызове, ощущением контроля над ситуацией и четким осознанием целей. 

Для вхождения в это состояние необходимо, чтобы при выполнении определенной задачи, знания и навыки соответствовали уровню ее сложности. Если сложность чрезмерна, возникает чувство беспокойства и даже страха. Избыток навыков ведет к апатии и скуке. В обоих случаях об эффективности не может быть и речи.

Как же сделать так, чтобы команда работала на максимуме, и при этом каждый был мотивирован и доволен? Ответ очевиден – постоянно обеспечивать подчинённым состояние потока. Одним из самых практичных инструментов для этого является делегирование.

Зачем использовать делегирование

Многие скажут, что всегда проще сделать все самому, и будут правы. Но нужно понимать, что делегирование используется не для того, чтобы управленцу стало легче «здесь и сейчас». Его предназначение в другом.

Первое – стимулировать каждого члена команды развиваться, расширять картину мира и зону ближайшего развития.

Второе – дать возможность руководителю прощупать потенциал сотрудников и понять, кто реально чего стоит: один будет землю рыть двумя лопатами, другой подойдет к задаче без энтузиазма, третий вообще спустит все на тормозах.

Третье – повысить доверие к управленцу: делегирование полномочий трактуется членами команды как вера в них. 

Четвертое – удерживать классных специалистов в компании, не давать им повода присматриваться к другим работодателям: возможность «поиграть мышцами» перед коллегами и оправдать доверие босса многого стоит.

Уровни делегирования

Делегирование – это про тактику маленьких шагов. Важно, чтобы делегируемая задача лежала в зоне ближайшего развития сотрудника. В своей книге «Менеджмент 3.0» Юрген Апелло выделяет 7 уровней делегирования: 

На первом – Tell – управленец прямо говорит подчиненному, что и как необходимо сделать. 

На втором – Sell – продает идею, объясняя, почему следует действовать именно таким образом. 

На третьем – Consult – советуется с исполнителем, но решение все же принимает сам. 

На четвертом – Agree – согласовывает одно из предложений, выдвинутых подчиненным.

На пятом – Advise – дает рекомендации, но принятие решения оставляет за исполнителем. 

На следующем уровне – Inquire – просит проинформировать о принятом решении. 

На высшем – Delegate – отдает полномочия и более не вмешивается. 

Искусство менеджера заключается в том, чтобы правильно определить, к кому из подчиненных какие уровни применимы, и кто с чем справится в конкретной ситуации. Допустим, еще вчера руководитель работал с одним из сотрудников на топовом восьмом уровне. А сегодня вызов по задаче столь серьёзен, что с тем же исполнителем необходимо применить делегирование уровня консультирования.

Совет менеджеру: действенным инструментом является визуализация карты текущего уровня делегирования, на котором находится каждый из членов команды. По сути, такая таблица – индивидуальный наглядный план развития сотрудников, позволяющий эффективно и последовательно наращивать их самостоятельность.

Этапы делегирования

Для начала пример. Лучше всех на интуитивном уровне делегированием занимаются мамы, когда учат ребенка, скажем, пользоваться ложкой. Существует этапность: сначала малыша держат за руку, затем руку убирают, затем отходят – так ребёнок начинает есть самостоятельно, затем уходят из комнаты; дают ребенку пошалить в пределах нового вида деятельности; возвращаются и корректируют поведение. Так и в бизнесе.

Итак, вы хотите делегировать решение какой-то задачи. Для начала важно определить, что находится в зоне ближайшего развития сотрудника, и какой тип делегирования следует применить для решения этой конкретной задачи. Далее, изложив задачу сотруднику, необходимо выяснить, как он эту задачу понял. Пока руководитель и сотрудник не придут к единому пониманию задачи, переходить к следующему этапу бессмысленно.

Когда синхронизация понятий завершена, можно переходить к разделу «чего ради», то есть сформировать заинтересованность. Когда сотрудник понял, в чем его выгода, можно переходить к определению сроков и контрольных точек.

Последнее имеет большое значение, ведь если формат и частота таких точек заранее не определены, исполнитель будет либо нервничать из-за избыточного контроля, либо обижаться из-за отсутствия внимания и поддержки со стороны руководителя.

Также следует определить Definition of Done – уровни выполнения задачи (приемлемый, высокий, идеальный). А также обозначить минимальный и максимальный результат. Далее исполнитель формирует план действий, руководитель наделяет его полномочиями, и человек приступает к работе.

В каждой контрольной точке исполнитель должен получить от руководителя обратную связь – позитивную или негативную. Первая еще более мотивирует, вторая – дает возможность подкорректировать свои действия и не налететь на рифы неожиданно в самом конце. 

На финальном этапе управленец принимает работу, дает ей оценку (возвращаемся к Definition of Done) и исчерпывающую обратную связь – без этих трех действий делегирование не работает, – а затем забирает полномочия. Если после решения задачи полномочия у человека не забираются, а остаются на постоянной основе, – это уже не делегирование, а распределение функциональных обязанностей.

PROs &CONs делегирования

Есть мнение, что, начав делегировать, руководитель моментально становится свободней. Но это иллюзия. Если делегирование применяется к подчиненному впервые, полноценный процесс потребует от менеджера гораздо больше времени и усилий. Если же делегирование – новый инструмент для самого управленца, затраты времени вырастают в разы, потому как обучаться будут оба: один правильно делегировать, другой – выполнять нетипичные для себя задачи. 

Делегирование – не низко висящий фрукт. Это игра в долгую. Это длительные инвестиции в себя и в команду. Но в перспективе это однозначно принесет дивиденды в виде роста ценности руководителя, продуктивности и вовлеченности команды, а также долгожданного высвобождения времени руководителя на осознанное бездействие. Последнее дает возможность вынырнуть из ежедневных рабочих процессов, наблюдать и анализировать новые тренды на рынке и, следовательно, повышает шансы выбрать правильный вектор дальнейшего развития бизнеса.

Китайская поговорка гласит: самое лучшее время посадить дерево было 20 лет назад, следующее лучшее время – сегодня. Иными словами, сажать древо делегирования следует прямо сейчас. И за это вы из, скажем, 2021 года точно поблагодарите себя сегодняшнего.

Если Вы заметили орфографическую ошибку, выделите её мышью и нажмите Ctrl+Enter.

Статьи, публикуемые в разделе «Мнения», отражают точку зрения автора и могут не совпадать с позицией редакции LIGA.net

Управлять DNS-записями — Яндекс.Коннект. Справка

DNS-записи (или ресурсные записи DNS) содержат служебную информацию о доменном имени, например адрес почтового шлюза или IP-адрес сайта, который находится на домене.

Настройте для вашего домена DNS-записи, необходимые для работы Яндекс.Почты.

Управлять DNS-записями можно на сайте провайдера DNS-хостинга — компании, которая предоставляет DNS-серверы для вашего домена. Если вы делегировали домен на серверы Яндекса, управляйте DNS-записями домена с помощью DNS-редактора Коннекта.

Чтобы настроить DNS-записи домена:

1. Авторизуйтесь в Яндекс.Коннекте как администратор.

2. На главной странице Яндекс.Коннекта на карточке сервиса Вебмастер нажмите значок .

3. На карточке домена нажмите ссылку Управление DNS.

4. Чтобы изменить DNS-запись, нажмите значок . Чтобы создайте новую запись, нажмите кнопку Добавить DNS-запись.

   При создании DNS-записи в поле Хост следует указывать:

   • Символ @, если вы настраиваете запись для основного домена, например yourdomain.tld.

   • Часть имени поддомена, которая отделена от имени основного домена точкой, например:

     • для поддомена bar.yourdomain.tld в поле Хост укажите bar;

     • для поддомена foo.bar.yourdomain.com в поле Хост укажите foo.bar .

Подробнее о настройке DNS-записей:

Делегирование как инструмент руководителя / Хабр

В сфере управления людьми (куда многие из нас, айтишников, зачастую приходят внезапно), существует масса инструментов и подходов. Некоторые из них базовые, другие — идут следом. Но так или иначе огромное количество начинающих менеджеров открывают для себя инструментарий управления методом проб и ошибок.

Делегирование — один из базовых инструментов руководителя, о котором большинство знает. Но обращаются к нему часто слишком поздно, считая, что «ещё не пришло время делегировать — других дел полно». К сожалению, это может привести к не очень хорошим результатам.

В статье я расскажу, что такое делегирование, зачем оно нужно и когда надо начинать делегировать, как делегировать правильно и где можно наломать дров, как это всё соотносится с ситуационным менеджментом и как необходимо действовать. В конце я поделюсь собственным ноу-хау в области делегирования, надеюсь, что каждому читателю это будет полезно.

Добро пожаловать под кат!

Меня зовут Илья Агеев, я работаю в Badoo уже почти восемь лет, руковожу большим департаментом, ответственным за контроль качества. В данный момент у меня в подчинении находятся почти 80 человек. Данная статья — расшифровка моего доклада c Techleads Meetup, который организовала компания Badoo 19 мая 2018 года. Она будет полезна широкой аудитории, независимо от того, руководите вы сейчас или нет. 

Итак, поехали!

Для начала дадим определение делегированию. В этом нам, как и во многих других случаях, поможет «Википедия». 

Делегирование — процесс передачи части функций руководителя другим управляющим или сотрудникам для достижения конкретных целей организации.
Wikipedia

Так и запомним.

История про Генри Форда

Когда речь заходит о делегировании, в первую очередь мне вспоминается история про Генри Форда. Не знаю, правда это или нет (вполне возможно, что это просто байка), но история красивая. 

Однажды Генри Форд решил отправить всех менеджеров всех уровней в двухнедельный круиз по Карибскому морю. Отговорки не принимались — все отправились в путешествие в добровольно-принудительном порядке. Когда менеджеры вернулись, то одних ждало повышение, а других — увольнение. 

На чём основывался Форд? На качестве работы департаментов, которые временно остались без руководителей. Те руководители, чьи подразделения продолжили работать в нормальном режиме, были награждены. Если же в отсутствие руководителя у сотрудников всё валилось из рук, работа не шла и процессы ломались, значит, руководитель не сумел наладить работу и таких управленцев следовало уволить. 

Делегировать легко!

В общем-то, в делегировании нет ничего сложного. Я уверен, что большинство читателей постоянно сталкивается с делегированием и так или иначе ежедневно использует этот инструмент в своей работе. 

Тем не менее иногда случаются казусы из-за неправильного применения инструмента делегирования. Видимо, потому что всё кажется слишком очевидным, понятным и исходящим из самого здравого смысла. 

Я думаю, многие видели эту картинку из Сети, на которой все всё «делегировали», а работает в итоге только Вася:

И эту, на которой в отдельных подразделениях рабочие процессы выстроены, но компания в целом явно движется куда-то не туда:

И ещё вот такую, на которой всё выглядит структурно правильно, все находятся на своих местах, но при этом люди чувствуют себя, мягко говоря, не очень:

Почему же так происходит? Почему возникают подобные ошибки в управлении? Давайте копать глубже.

Возвращаемся к определению делегирования и внимательно его читаем. Что бросается в глаза в первую очередь? 

Делегирование — процесс передачи части функций руководителя другим управляющим или сотрудникам для достижения конкретных целей организации.
Wikipedia

Делегирование — это передача части функций руководителя… Обыватель сразу думает: «О, круто! Хочу функции руководителя! Начальник — он вон какой крутой! Сидит в своём кабинете, секретарь ему носит кофе. Начальник принимает решения, кого брать на работу, а кого — увольнять. Вершит судьбы людей! Я тоже так ХОЧУ!»

Но на деле передачей полномочий дело не ограничивается. И наверняка руководитель, помимо того, что пьёт кофе, делает что-то ещё. Спойлер: много чего ещё.

Ответственность

Обратимся к умным людям и посмотрим, что они думают про делегирование. К примеру,

, французский горный инженер, теоретик и практик менеджмента, один из основателей «классической школы» управления, считает так:

Полномочия не должны рассматриваться отдельно от ответственности […]. Ответственность есть следствие полномочий.

И если хорошенько подумать, то становится понятно, что главное при делегировании — ответственность. Всё остальное — полномочия, право принятия решений, ресурсы, люди, процессы — идёт следом и служит только цели реализации делегированной ответственности. 

Дать полномочия без ответственности можно, но это может привести к плачевным последствиям. А дать ответственность без полномочий означает поставить исполнителя в безвыходное положение, ведь он не сможет реализовать делегированную ответственность.

Таким образом, мы приходим к выводу, что ответственность и полномочия для её реализации должны делегироваться только вместе. При этом полномочий должно быть делегировано ровно столько, сколько нужно для реализации ответственности. Дашь меньше полномочий — есть огромный риск, что дело сделано не будет. Дашь больше — есть риск превышения полномочий.

Кстати, в англоязычной «Википедии» определение делегирования содержит слово «ответственность» (responsibility). Странно, что в русскоязычном варианте оно потерялось.

Зачем нужно делегировать?

В одном из источников, которые я изучал в процессе подготовки своего доклада, я обнаружил вот такой список причин для делегирования:

• решение сложных задач, которые не могут решить другие;
  
• повышение мотивации сотрудников;
  
• повышение доверия в коллективе;
  
• проверка исполнительности подчинённых.
  

Для меня он выглядят немного странным, особенно последний пункт. Поэтому я оставлю этот список без комментариев, а вместо него предложу свой список причин для делегирования.

Профессиональный рост сотрудников. Очевидно, что если вы не будете делиться со своими подчинёнными частью работы, которую выполняете каждый день, то они никогда не научатся её делать. То же самое относится к вам как к руководителю: если вы не будете делегировать, то никогда этому не научитесь. Отказываясь от делегирования, вы тормозите как свой рост и рост ваших сотрудников, так и рост компании в целом. 

Свежий взгляд и постоянное развитие. Это жизненно необходимые условия как для вас, так и для всей компании. Существует несколько практик, например:

• кайдзен — японская практика (и философия, как многое у японцев) непрерывного развития процессов, людей и всего, что вокруг этого вертится;
  
• цикл Деминга (plan-do-check-act, PDCA) — циклически повторяющийся процесс принятия решений, используемых в управлении качеством;
  
• continuous improvement management (CIM) — практики постоянных улучшений в теории ограничений Голдратта.
  

Все мы люди. Никто не застрахован от болезни, неотложных дел и иных форс-мажоров. У всех может быть отпуск. Наконец, нас могут уволить. И делегирование — это прямой путь к минимизации рисков как для компании в целом, так и для вашего департамента в частности.

Когда можно начинать делегировать?

Наверное, многие задаются этим вопросом. «Я менеджер, у меня в подчинении один человек. Могу ли я начать делегировать?» Или «Я менеджер, у меня в команде пять человек. Надо ли ждать, когда их будет шесть?» 

Давайте поговорим про верхний предел. Британский учёный Робин Данбар умудрился математически вычислить, что размер участка коры головного мозга у высших приматов, который называется неокортекс, линейно коррелирует с количеством социальных связей, которые они могут поддерживать. Для людей такой предел — примерно 150 связей. Это значение ещё называют числом Данбара. 

В это количество входят ваши родственники, друзья детства, соседи, коллеги, дети, жёны/мужья и ваши сотрудники, с которыми вы ежедневно встречаетесь на работе. 150 социальных связей — физиологический предел, у кого-то он чуть больше, у кого-то — чуть меньше. 

Говорят, Александр Македонский знал в лицо каждого своего воина, но, скорее всего, это только красивая легенда.

Есть ли какое-то реалистичное число — количество людей, с которым комфортно работать? Опять на помощь приходит физиология. Американский психолог Джордж Миллер вывел такую закономерность: наша кратковременная память (оперативная) может оперировать только семью (± 2) значениями в единицу времени. Этот феномен получил название «магическое число семь плюс-минус два», или «кошелёк Миллера».

Это наблюдение коррелирует с опытом многих из нас. Так, 6–12 человек — это оптимальный размер отдела. Если людей больше, становится гораздо сложнее управлять ими. Тем более если у вас есть новички или процессы ещё не настроены должным образом.

Тем не менее мой опыт показывает, что иногда и большим количеством людей можно неплохо оперировать. Один из моих сотрудников, который руководит отделом, находящимся в моей зоне ответственности, имеет 20 человек в непосредственном подчинении и неплохо с ними справляется. Но я думаю, что это скорее исключение, нежели правило.

Так когда же начинать делегировать? На самом деле, ждать не надо. Начинать можно, даже если вы один. Как только вам делегировали кусочек ответственности, сразу же появляются все причины и риски, о которых мы говорили ранее. Следовательно, риски стоит минимизировать.

Поэтому давайте поговорим о том, как нужно и как не нужно передавать полномочия и ответственность. 

Ошибки при делегировании

Для начала рассмотрим, какие ошибки допускают менеджеры при делегировании.

1. Первая и самая очевидная ошибка — это отсутствие делегирования. Делегируйте, не ждите. «Подходящий» момент может никогда не наступить. 
   
2. Делегирование группе без назначения ответственного. Когда мы говорим про делегирование, то в первую очередь говорим про ответственность. Если вы делегируете ответственность группе людей, то ответственным должен быть кто-то один. Когда за что-то отвечают все, по факту не отвечает никто.
   
3. Делегирование без учёта возможностей исполнителя. Ответственность и средства для её реализации надо давать ровно в таком количестве, которое необходимо для решения задачи. Если дадите меньше, то задача просто не будет решена. 
   
4. Делегирование чужих задач. Если ответственность возложена не на вас, то как вы можете её передавать кому-то другому или разделять с кем-то другим?
   
5. Делегирование мелких задач без указания цели. Когда сотрудник не понимает общей цели, даже если он очень старается и выполняет то, что вы попросили его сделать, не факт, что он вовремя придёт туда, куда вам нужно. Обратное тоже верно.
   
6. Делегирование целей без инструктирования. Так бывает, когда вы говорите, куда нужно прийти, но не говорите как. 
   
7. Делегирование без указания сроков. Если вы поручаете сотруднику какую-то задачу и не обозначаете конечную цель, шаги, сроки, очень вероятно, что задача не будет решена.
   
8. Делегирование без указания приоритетов. См. пункт 7.
   
9. Делегирование неинтересных задач. Наверняка среди вас есть люди, которые оказывались в ситуации, когда руководитель те задачи, которые ему не нравятся, скидывает на других. Не надо так.
   
10. Отсутствие обратной связи или контроля. Это когда вы даёте задачу и не проверяете, как человек с ней справляется.
    
11. Перфекционизм и нетерпеливость. Очень серьёзная и очень частая ошибка при делегировании. Это когда вы знаете, что можете сделать лучше, и постоянно подходите к человеку, указываете на недочёты. По сути, вы просто мешаете ему и добиться результата сейчас, и успешно решать подобные задачи в будущем.
    
12. Наконец, полная передача ответственности. Делегирование — это не полная передача ответственности, а только её разделение с тем человеком, которому вы делегируете задачу. Несмотря на то, что он отвечает перед вами за исполнение, сроки, качество, с вас самих ответственность никто не снимал. В итоге вы всё равно будете отвечать перед своим руководством. 
    

У многих начинающих менеджеров сразу возникает вопрос, который сам по себе является большой ошибкой: «Если всё то, за что меня ценят и любят, я делегирую, то я ведь перестану быть незаменимым. Зачем же я тогда буду нужен компании? Меня можно будет уволить».

Здесь важно помнить о двух вещах. Первое: как менеджер вы обязаны заботиться о рисках. Если вышло так, что вы единственный человек, который может сделать что-то в рамках определённых задач, то вы взяли компанию «в заложники». Значит, вы враг собственной компании. Так делать ни в коем случае нельзя. Второе: чем больше вы будете делегировать, тем больше будете приобретать. Появятся новые задачи, на которые у вас раньше не было времени. Ведь вам было некогда даже голову поднять от рутины и посмотреть вокруг, задуматься о том, что в компании могут существовать проблемы иного масштаба и что есть важные стратегические задачи, которые тоже нужно решать.
 

Правила делегирования

Как же делать правильно? Давайте рассмотрим это также по пунктам.

1. Делегируйте. Не ждите, используйте любую возможность, уменьшайте риски. Заботьтесь о росте своих сотрудников и компании.
   
2. Подберите исполнителя под задачу. Человек, которому вы делегируете полномочия и ответственность, должен подходить для решения задачи как по своим профессиональным качествам, так и по вовлечённости.
   
3. Сформулируйте цель, определите результат, подтвердите сроки. 
   
4. Обозначьте права и обязанности. Предоставьте исполнителю все ресурсы, необходимые для решения задачи.
   
5. Мотивируйте.
   
6. Убедитесь, что человек, которому вы делегируете обязанности, всё понял правильно. 
   
7. Поддерживайте и контролируйте сотрудника в процессе исполнения.
   
8. Не забывайте про автоматизацию. Это очень важный момент. Часто при делегировании менеджеры думают однобоко, только о людях. На самом деле делегировать можно любому ресурсу. Самый простой пример — календарь, автоматизированный инструмент, которому вы делегируете работу по запоминанию и планированию ваших встреч, который ещё и напоминает вам о событиях, как личный секретарь.
   

Исполнители

Мы выяснили, что хорошо и что плохо, с чего начать и как действовать в разных ситуациях. А требуется ли что-то от сотрудников, чтобы менеджер мог делегировать им полномочия?

В теории менеджмента есть две концепции передачи полномочий и ответственности. 

Первая — это так называемая классическая концепция, когда полномочия и ответственность передаются сверху вниз. Сюда относятся приказы, чёткие указания, пошаговый инструктаж. Как в армии: начальник приказал катать квадратное или носить круглое — будь добр выполнять, не задумываясь о том, почему нужно делать именно так.

Вторая — это концепция принятия полномочий и ответственности, которую сформулировал Честер Бернард, президент отделения Bell Telephone Company в Нью-Джерси. Согласно ей, полномочия могут передаваться сверху вниз и обратно, то есть подчинённый может принять полномочия и ответственность, а может и не принять. В рамках этой концепции необходимо убедить человека сделать то, что вам нужно, «продать» идею.

Как же действовать правильно? Правда, как всегда, где-то посередине.

Желания и возможности

На помощь нам приходит модель ситуационного лидерства, которую сформулировали два американца: Пол Херси, этолог и предприниматель, и Кен Бланшар, автор книг и эксперт по менеджменту. В 1960-х годах они написали общий труд Management of organizational behaviour, в котором сформулировали модель, которая учитывает мотивацию и опыт сотрудника.

Авторы утверждают, что нет единственно правильного стиля руководства, который подходит абсолютно всем в любой ситуации. Наоборот, согласно модели, стиль руководства находится в зависимости от конкретной задачи и конкретного исполнителя.

Здесь модель представлена крупными мазками, конечно, в ней могут быть и переходные состояния. Но для общего понимания этой градации вполне достаточно.

• «Хочу — не могу». Это люди, у которых сильная мотивация, но мало опыта для решения задачи. Обычно это новички, которые только начали работать после получения диплома, они прямо жаждут что-нибудь сделать. Метод работы с ними — инструктаж. Ставьте перед ними чёткие цели, учите их, разъясняйте какие-то моменты, контролируйте. Мотивировать их практически не нужно.
  

• «Не хочу — не могу». Здесь подходящий стиль руководства — наставничество. Такие люди не умеют и не хотят по каким-то причинам. Это самая сложная категория, потому что таких сотрудников нужно не только обучать, но и постоянно мотивировать. Перед ними надо ставить чёткие цели, давать им чёткие приказы, указания, постоянно пошагово контролировать, но при этом не забывать объяснять причины принятия тех или иных решений, «продавать» идеи и способы решения задач. Таким образом мы учим таких сотрудников выполнять задачи, которые стоят перед отделом и компанией в целом.
  
• «Не хочу — могу». Правильный стиль руководства — вовлечение. К этой категории относятся люди, у которых большой опыт, но почему-то пропала мотивация. Такое бывает с сотрудниками, которые давно работают в компании и «выгорели». Их нужно мотивировать, «продавать» им идеи, убеждать их выполнить задачу. Упор при взаимодействии с ними необходимо делать на их мотивации.
  
• «Хочу — могу». Самая лёгкая группа для делегирования полномочий. Стиль руководства тут так и называется — делегирование. Перед такими людьми можно ставить нечёткие цели и практически не обращать внимания на то, как решается задача. Их не надо ни поддерживать, ни мотивировать. Но это не значит, что делегировать можно только этим людям. 
  

В последнем случае делегировать легче всего, но на самом деле делегировать обязанности можно любому участнику коллектива, только затраты ресурсов

будут разные. 

Наверное, вам хотелось бы, чтобы все ваши сотрудники были из группы «Хочу — могу», но суровая правда жизни такова, что это бывает далеко не всегда и работа с основной массой вашего коллектива требует много сил. Особенно с теми, кто и не хочет, и не может.

Поэтому часто мы думаем: «Мне самому надо сначала очень хорошо поработать и постараться, прежде чем что-то кому-то делегировать. А потом ещё придётся постоянно его контролировать, убеждаться в том, что он делает правильно». Обычно такие мысли возникают, если вы линейно оцениваете задачу или имеющиеся в вашем распоряжении ресурсы, если вам кажется, что вы и только вы можете раздавать своим сотрудникам задачи, объяснять, мотивировать и контролировать их. Это большая ошибка. 

Ресурсов у вас как у менеджера куда больше. Ведь во всех этих ежедневных задачах вам могут помочь ваши же сотрудники. 

Давайте посмотрим на схему немного в другом разрезе. Что нам необходимо делать для сотрудников, у которых мотивация либо экспертиза относительно конкретных задач не на самом высоком уровне?

Таких сотрудников нужно обучать, мотивировать, а тех, которые относятся к категории «Не хочу — не могу», — и обучать, и мотивировать одновременно. Да и контроль никто не отменял.

Что, если мы, к примеру, попробуем построить процесс обучения и автоматизировать средства контроля, чтобы уменьшить количество работы? 

Это, кстати, очень важный момент. Когда вы строите какой-либо процесс, нужно ориентироваться в первую очередь на исполнителей, которых необходимо мотивировать, контролировать и обучать. Те, в кого вкладываться нужно по минимуму, могут справиться, даже если процесса как такового нет.

Что же касается делегирования задач, то давайте начнём с самого простого. Почему бы нам не построить этот процесс таким образом, чтобы люди, для взаимодействия с которыми требуется минимум усилий, помогали обучать тех, у кого высокая мотивация, но пока нет навыков? Ведь необходимая для профессиональной работы экспертиза у этой группы сотрудников имеется.

Такие специалисты могут помочь в создании процесса онбординга сотрудников, в обучении новичков необходимым навыкам работы в коллективе и т. д. Здесь необходимы специальная документация и пошаговые инструкции, чтобы такие задачи отнимали минимум времени в будущем как у вас, так и у других экспертов в отделе. 

Или такие люди могут помочь в мотивировании группы «Не хочу»? Про мотивацию и «выгорание» мы говорили на очередном Techleads Meetup в Badoo 15 июня 2019 года. Многие из вещей, которые там обсуждались, тоже можно делегировать. 

И даже тех, у кого мотивация пропала, но есть экспертиза, тоже можно задействовать в процессе обучения. Многие с удовольствием бы делились опытом, тем самым повышая свою вовлечённость в общее дело. Горящие глаза коллег, которые смотрят на эксперта и слушают с раскрытым ртом то, о чем он говорит, очень неплохо мотивируют. 

Уверяю вас, что мотивация повысится у многих из тех, кто почувствовал, что нужен команде, что его опыт необходим не только для выполнения рутинной работы, что другие сотрудники начинают его ещё больше уважать, любить и ценить за помощь в решении ежедневных задач. Они могут легко перейти из группы «Не хочу — могу» в группу «Хочу — могу». 

А дальше всё просто, ведь процессы делегирования можно выполнять параллельно. Просто привлекаем подчинённых к решению задач, которые вы раньше предпочитали решать в одиночку. 

И мы плавно подошли к тому, что делегирование — это такая же менеджерская функция, как и любая другая. Как ни удивительно, но её тоже можно делегировать.

А можно как-то проще?

Наверное, у кого-то из вас возникла мысль, что всё сложно.

».

Такое лекало действительно есть. Это то самое ноу-хау, о котором я говорил в самом начале.

Представьте, что прямо сейчас вам звонит шеф, владелец компании, самый высокий босс и говорит: «Вася, выходи из здания. Там стоит машина. Она тебя отвезёт в аэропорт. Там ждёт частный самолёт. Он тебя отвезёт на остров в Карибском море, где ты проведёшь сколько-то времени. Твоих близких мы уже предупредили. Но на работу ты сообщить никак не можешь».

Спросите себя, что у вас в отделе или в компании сломается? Представьте, что вы отсутствуете день, три дня, неделю, месяц, год. Представьте, что вы на всю жизнь уехали в круиз. Таким образом у вас получится приоритизированный список вещей, которые обязательно нужно делегировать.

Заключение

Надеюсь, что мне удалось донести до читателя тезис о том, что делегирование — это не сложно. Да, это можно делать неправильно. Но как делать это правильно, мы теперь тоже разобрались.

Хочу лишь напомнить, что делегирование и всё вышесказанное не единственная стратегия работы с людьми. Это не панацея. В арсенале менеджера гораздо больше инструментов. Смотрите шире и по максимуму используйте ресурсы, которые у вас есть.

Спасибо за внимание!

— Ссылки на источники, использовавшиеся для подготовки доклада:

https://studopedia.org/14-71669.htm l 
https://ru.wikipedia.org/wiki/Делегирование_полномочий 
http://helpiks.org/3-32518.html 
https://ru.wikipedia.org/wiki/Кайдзен 
https://www.cfin.ru/management/people/labor_law/authority_delegation.shtml 
https://studfiles.net/preview/908897/ 
https://sites.google.com/a/avlc.ru/spm/courses/plan/modul_08 
https://studfiles.net/preview/908897/ 
https://cyberleninka.ru/article/n/plyusy-i-minusy-delegirovaniya-polnomochiy 
https://en.wikipedia.org/wiki/The_Magical_Number_Seven,_Plus_or_Minus_Two 

8.3. Сущность и значение делегирования в организации

Делегирование — средство, при помощи которого руководство предприятия устанавливает отношения между различными уровнями и отделами для распределения полномочий.

В более широком смысле, делегирование – это передача полномочий лицу, которое принимает на себя ответственность за их исполнение.

Делегирование имеет свои преимущества и недостатки⁴¹.

Причины нежелания руководителей делегировать полномочия:

• Заблуждение «я сделаю это лучше».

• Отсутствие способности руководить (неспособность понять системность работ и процессов в организации и правильно распределить полномочия).

• Отсутствие доверия к подчиненным.

• Боязнь риска, связанного с ненадлежащим выполнением работ.

Причины уклонения подчиненных от делегирования:

• Подчиненный считает, что легче спросить босса.

• Подчиненный боится критики за совершенные ошибки.

• У подчиненного отсутствует уверенность в себе.

• У подчиненного отсутствуют информация и ресурсы.

• У подчиненного нет дополнительных временных и прочих ресурсов для выполнения работ.

• Подчиненный не получает дополнительных стимулов при принятии дополнительной ответственности.

Основными понятиями в теории делегирования являются ответственность и полномочия.

Ответственность — обязательство выполнять имеющиеся задачи и отвечать за их удовлетворительное разрешение.

Полномочия — ограниченное право использовать ресурсы организации и направлять усилия некоторых ее сотрудников на выполнение определенных задач. Полномочия делегируются должности, а не индивиду, занимающему должность в данный момент.

Виды полномочий:

• Линейные полномочия — это полномочия, которые передаются непосредственно от начальника к подчиненному.

• Аппаратные (штабные) полномочия — полномочия, распределяемые в команде руководителя для наиболее эффективного построения процесса принятия управленческих решений.

Существует две противоположные концепции организационных полномочий:

• Классическая концепция организационных полномочий — изначальная концепция, считавшая, что у руководителя появляются полномочия тогда, когда он получает их от высшего руководства.

• Концепция принятия организационных полномочий — связывает процесс приобретения полномочий с признанием их со стороны подчиненных.

Распределение полномочий и ответственности на предприятии закрепляется с помощью системы должностных инструкций.⁴²

9. Контроль как функция управления

9.1. Сущность и смысл контроля в системе управления43

Контроль — это процесс обеспечения достижения организацией своих целей. Целями осуществления контроля в организации являются:⁴⁴

• Фиксация достижения целей

• Предупреждение возникновения кризисных ситуаций⁴⁵

• Поддержание успеха

• Повышение управляемости организации

Характеристики эффективного контроля:

• Стратегическая направленность контроля

• Ориентация на результаты

• Соответствие делу

• Своевременность контроля

• Гибкость контроля

• Простота контроля

• Экономичность контроля.

9.2. Виды контроляи их характеристики46

По времени осуществления контроль подразделяют на предварительный, текущий и заключительный.

Предварительный контроль

Осуществляется до выполнения работ. Цель предварительного контроля — определить и закрепить основные правила и направления поведения организации и ее элементов в процессе выполнения работ. Примерами предварительного контроля могут служить:

• разработка бюджета мероприятия,

• установление нормативов выработки,

• установление стандартов качества,

• установление норм товарных запасов,

• разработка должностной инструкции.

Текущий контроль

Осуществляется непосредственно в ходе выполнения работ. Цель текущего контроля — своевременно отреагировать на возникающие проблемы⁴⁷.

Заключительный контроль

Осуществляется после проведения работ с целью аккумуляции и анализа информации о достигнутых результатах. Заключительный контроль:

• дает руководству информацию, необходимую для планирования дальнейшего развития предприятия,

• играет важную роль в процессе мотивации персонала.

404 | Микро Фокус

в Swift (как сделать)

Автор: Aasif | Обновлено 3 декабря 2021 г., 10:35 | 6 мин чтения

Делегирование, также известное как шаблон делегата, часто используется в практической разработке iOS.Это обязательный элемент в наборе инструментов разработчика iOS, и сегодня мы собираемся выяснить, как работает делегирование.

В этом руководстве вы узнаете:

• Что такое делегирование, как оно работает и почему оно полезно
• Как работать с протоколами делегирования в iOS SDK
• Альтернативы шаблона делегирования и их использование

Делегирование — это шаблон проектирования, который позволяет классу передавать (или «делегировать») некоторые из своих обязанностей экземпляру другого класса.

Это довольно сложно, поэтому давайте разберемся…

Подумайте о делегировании в реальном мире. Представьте, что мы с вами — часть команды, которая доставляет шоколадное печенье на мероприятие. Вы отвечаете за выпечку печенья, а приготовление теста для печенья поручаете мне. Когда я закончу, я отдаю вам тесто для печенья, чтобы вы могли испечь из него печенье.

Выделяются несколько ключевых моментов:

• Вы отвечаете за создание файлов cookie и делегируете мне создание теста для файлов cookie.
• Вы могли бы сказать, что создание файлов cookie — это ваша ответственность, и вы передаете часть этого ответственность перед мной
• И это происходит двумя способами: я даю вам тесто для печенья, как только я закончу свою делегированную задачу

В программировании на Swift это не сильно отличается! Один класс делегирует задачу другому классу, передавая часть своих обязанностей.Это позволяет делегату настраивать базовый класс, как мы скоро узнаем.

Давайте посмотрим на пример на Swift. Сначала мы определяем структуру Cookie. Примерно так:

struct Cookie {
var size: Int = 5
var hasChocolateChips: Bool = false
}
А затем мы определяем класс под названием Bakery. Как это:

class Bakery
{
func makeCookie ()
{
var cookie = Cookie ()
cookie.size = 6
cookie.hasChocolateChips = true
}
}
Смотрите, что происходит? В классе Bakery есть функция makeCookie (), которая создает файл cookie со структурой Cookie и устанавливает некоторые из его свойств, например размер.

На этом этапе мы хотим продавать печенье 3 разными способами:

1. В магазине пекарни
2. На веб-сайте пекарни
3. Оптовая продажа дистрибьюторам печенья

Пекарня не отвечает за продажу печенья, а производство куки является. Итак, нам нужен способ доставки файлов cookie после их выпечки без кодирования всего этого в классе Bakery. Вот тут-то и появляется делегация!

Во-первых, мы определяем протокол, который инкапсулирует обязанности, которые мы передаем.Примерно так:

протокол BakeryDelegate {
func cookieWasBaked (_ cookie: Cookie)
}
Этот протокол BakeryDelegate определяет одну функцию cookieWasBaked (_ :). Эта функция делегата будет вызываться всякий раз, когда будет запечен файл cookie.

Во-вторых, мы добавляем делегирование в класс «Пекарня». Как это:

class Bakery
{
var делегат: BakeryDelegate?

func makeCookie ()
{
var cookie = Cookie ()
cookie.size = 6
cookie.hasChocolateChips = true

делегат? .cookieWasBaked (cookie)
}
}
В классе Bakery изменились две вещи:

1. Добавлено свойство делегата типа BakeryDelegate
2. Вызывается функция cookieWasBaked (_ 🙂 для делегата в makeCookie () с делегатом? .cookieWasBaked (cookie) с кодом

Это еще не все. Проверьте это:

• Тип свойства делегата — это протокол, который мы определили ранее. Вы можете присвоить любое значение свойству делегата, если оно соответствует протоколу BakeryDelegate.
• Свойство делегата является необязательным, и мы используем необязательную цепочку при вызове этой функции cookieWasBaked (_ :). Когда делегат равен нулю, функция не вызывается.

Итак, резюмируя: вы определили протокол BakeryDelegate, который определяет некоторые обязанности, которые делегирует Bakery, и вы реализовали передачу в makeCookie ().

В-третьих, давайте создадим настоящий класс делегата! Как это:

class CookieShop: BakeryDelegate
{
func cookieWasBaked (_ cookie: Cookie)
{
print («Ура! Был испечен новый файл cookie с размером \ (cookie.size) ”)
}
}
CookieShop использует протокол BakeryDelegate и соответствует этому протоколу, реализуя функцию cookieWasBaked (_ :).

И, наконец, вот как собрать код:

let shop = CookieShop ()

let bakery = Bakery ()
bakery.delegate = shop

bakery.makeCookie ()
// Результат: Ура! Был создан новый файл cookie размером 6
Вот что происходит:

• Сначала вы создаете объект CookieShop и назначаете его константе магазина.
• Затем вы создаете объект Bakery и назначаете его константе bakery.
• Затем вы назначаете магазин bakery.delegate. Это делает магазин представителем пекарни.
• Наконец, когда пекарня делает печенье, это печенье передается в магазин, который может продать его счастливому покупателю.

И это делегирование! Пекарня поручает продавать печенье магазину и отказывается от него, когда он его готовит.

Сила делегирования заключается в том простом факте, что пекарне не нужно знать, где в конечном итоге попадают ее файлы cookie.Он может предоставить их любому классу, который принимает протокол BakeryDelegate!

Пекарне не нужно знать о реализации этого протокола, только то, что она может при необходимости вызывать функцию cookieWasBaked (_ :).

Почему магазин не вызывает makeCookie () напрямую, когда ему нужен файл cookie для продажи? Ответ кроется в характере делегирования и в том, какой класс контролирует. Вы узнаете, как это сделать в следующем разделе.

Делегирование — один из наиболее распространенных шаблонов проектирования при разработке iOS.Создать приложение для iOS без делегирования практически невозможно.

Краткий обзор классов в iOS SDK, которые используют делегирование:

• Класс UITableView использует протоколы UITableViewDelegate и UITableViewDataSource для управления взаимодействием с табличным представлением, отображением ячеек и изменением макета табличного представления
• CLLocationManager использует CLLocationManagerDelegate сообщать в приложение данные о местоположении, например GPS-координаты iPhone
• UITextView использует UITextViewDelegate для сообщения об изменениях в текстовом представлении, таких как вставленные новые символы, изменения выбора и прекращение редактирования текста

Когда вы посмотрите на эти три протокола делегирования, вы быстро увидите одну общую закономерность: каждое из делегированных событий инициируется классом вне вашего контроля, пользователем, операционной системой или ее оборудованием.

Давайте посмотрим:

• Координаты GPS предоставляются чипом GPS и делегируются вашему коду всякий раз, когда чип фиксирует положение GPS
• В табличном представлении используется механизм для отображения ячеек на экране, и вам необходимо предоставить эти ячейки, когда они необходимы в соответствии с табличным представлением.
• Текстовое представление реагирует на произвольный ввод пользователя и соответственно вызывает функции делегирования.

Помните пример Bakery из предыдущего раздела? В этом примере мы сами вызвали makeCookie ().Это будет набор цепочки событий, которые приводят к тому, что пекарня предоставляет магазин cookie.

При практической разработке iOS пекарня будет печь печенье самостоятельно. Это вне нашего контроля, поэтому нам нужен делегат, чтобы реагировать на эти события.

Этот простой принцип показывает необходимость делегирования, поскольку он позволяет подключаться к событиям и действиям, которые вы не можете контролировать.

Представьте, что вы не можете изменить код в классе Bakery, так же как вы не можете изменить код в классе CLLocationManager.Вы не можете указать ему, чтобы он запекал cookie, точно так же, как вы не можете указать CLLocationManager получить GPS-координаты пользователя. Вам нужно будет запустить процесс запекания файлов cookie, запустить службу геолокации, а затем дождаться поступления данных. Вы подключаетесь к этим данным, используя делегирование.

В следующем разделе мы рассмотрим реальный пример.

Давайте посмотрим на пример. Вы делаете простой контроллер представления для заметок. Он включает текстовое представление, и это текстовое представление использует делегирование.

Как это:

класс NoteViewController: UIViewController, UITextViewDelegate
{
var textView: UITextView =

func viewDidLoad ()
{
textView.delegate = self
}
} UIViewController, мы определяем код UIV, определяемый выше. подкласс под названием NoteViewController. Он принимает протокол UITextViewDelegate и настраивает простое текстовое представление с помощью свойства textView. Вы можете предположить, что этот textView правильно инициализирован в init ().

В функции viewDidLoad () вы назначаете self свойству делегата textView.Иными словами, текущий экземпляр NoteViewController является делегатом текстового представления.

Обычно, но не всегда рекомендуется использовать контроллер представления в качестве делегата определенного класса. Это может привести к длинным классам контроллера представления. Ниже я привел несколько альтернатив.

Согласно протоколу UITextViewDelegate, теперь мы можем реализовать ряд функций делегирования для ответа на события, происходящие в текстовом представлении. Вот некоторые из этих функций:

• textViewDidBeginEditing (_ 🙂
• textViewDidEndEditing (_ 🙂
• textView (_: shouldChangeTextIn: replaceText 🙂
• textViewDidChange (_ 🙂

начинается редактирование текста и начинается редактирование текста. заканчивается, например, мы можем выделить текстовое представление, чтобы показать пользователю, что происходит редактирование.Когда вызывается textViewDidChange (_ :), мы можем обновить счетчик, который показывает количество символов в текстовом представлении.

Что интересно, textView (_: shouldChangeTextIn: replacementText 🙂 может предоставлять возвращаемое значение типа Bool. Эта функция делегата вызывается перед вводом одного или нескольких символов в текстовое представление. Если вы вернете true, запись разрешена, а если вы вернете false, запись не разрешена. Вы можете использовать это для:

• Ограничить количество текста, которое можно ввести
• Заменить определенные слова, фразы или символы чем-то другим
• Запретить пользователям копировать текст в текстовое представление

Это показывает, что класс делегатов может предоставить данные обратно в класс, который вызывает функцию делегата (т.е., текстовое представление или пекарня для печенья), что делает его улицей с двусторонним движением.

Давайте посмотрим, как передача данных от делегата будет работать в предыдущем примере с BakeryDelegate.

Во-первых, мы настраиваем BakeryDelegate, чтобы включить в него другую функцию:

protocol BakeryDelegate {
func cookieWasBaked (_ cookie: Cookie)
funcolatedCookieSize () -> Int
}
И функцию makeCookie () класса Bakery. тоже изменения:

func makeCookie ()
{
var cookie = Cookie ()
cookie.size = делегат? .preferredCookieSize () ?? 6
cookie.hasChocolateChips = true

делегат? .CookieWasBaked (cookie)
}
Видите, как для делегата вызывается функция preferredCookieSize ()? Это дает делегату возможность настроить размер файла cookie. А когда делегат равен нулю, оператор объединения с нулем ?? Убедитесь, что размер по умолчанию равен 6.

Затем мы изменяем наш класс делегата, чтобы включить эту новую функцию, например:

class CookieShop: BakeryDelegate
{
func cookieWasBaked (_ cookie: Cookie)
{
print («Ура! Был испечен новый файл cookie с размером \ (cookie.size) ”)
}

funcolatedCookieSize () -> Int
{
return 12
}
}
Наконец, мы запускаем тот же код, что и раньше:

let shop = CookieShop ()

let bakery = Bakery ( )
bakery.delegate = shop

bakery.makeCookie ()
// Вывод: Ура! Выпечено новое печенье размером 12
. Вы увидите, что испеклось печенье размером 12. Это связано с тем, что функция-делегат preferredCookieSize () позволяет нам передавать данные обратно объекту Bakery с возвращаемым значением.

Такая функция, как primaryCookieSize (), довольно часто встречается в некоторых SDK для iOS. Протокол делегата табличного представления, например, определяет функции делегата, которые настраивают размер ячеек табличного представления, верхних и нижних колонтитулов.

Еще одна частая практика в iOS SDK — использование слов «did», «should» и «will» в именах делегированных функций. Они часто рассказывают вам о порядке операций и о том, в какой момент вызывается функция-делегат. Это до или после взаимодействия?

Некоторые примеры:

• tableView (_: willSelectRowAt 🙂 в UITableViewDelegate сообщает делегату, что строка представления таблицы собирается быть выбрана
• locationManager (_: didUpdateLocations 🙂 в CLLocationManagerDelegate сообщает делегату, что поступили обновления местоположения
• navigationController (_: willShow: animated 🙂 в UINavigationControllerDelegate сообщает делегату, что контроллер навигации собирается отобразить контроллер представления

Почему бы вам не попробовать пример кода из этого руководства? Воспользуйтесь песочницей Swift ниже, чтобы поиграть с делегированием.

struct Cookie {
var size: Int = 5
var hasChocolateChips: Bool = false
}

BakeryDelegate {
func cookieWasBaked (_ cookie: Cookie)
funcolatedCookieSize () -> Int
}

class Bakery
{
var делегат: BakeryDelegate?

func makeCookie ()
{
var cookie = Cookie ()
cookie.size = делегат? .preferredCookieSize () ?? 6
cookie.hasChocolateChips = true

делегат? .CookieWasBaked (cookie)
}
}

class CookieShop: BakeryDelegate
{
func cookieWasBaked (_ cookie: Cookie)
{
print («Ура! , с размером \ (cookie.size) ”)
}

func preferredCookieSize () -> Int
{
return 12
}
}

let shop = CookieShop ()

let bakery = Bakery ()
bakery.delegate = shop

bakery.makeCookie ()

Зачем вообще использовать делегирование? Кажется слишком сложным просто передавать данные в коде туда и обратно.

Несколько причин в пользу делегирования:

• Делегирование и шаблон делегирования — это упрощенный подход к передаче задач и взаимодействий от одного класса к другому.
• Вам нужен только протокол для передачи требований между классами. Это значительно снижает взаимосвязь между классами.
• И он разделяет обязанности класса, который генерирует взаимодействия, от класса, который реагирует на эти взаимодействия.

Короче говоря, делегирование — отличный способ «прицепиться» к событиям, которые происходят в коде, который вы не контролируете, без жесткой связи вашего кода или снижения возможности компоновки.

Убедительной альтернативой делегированию является создание подклассов. Вместо того, чтобы использовать делегата для получения обновлений местоположения GPS от CLLocationManager, вы просто подклассифицируете этот класс менеджера и отвечаете на обновления местоположения напрямую.

У этого есть серьезный недостаток: вы наследуете весь класс CLLocationManager для чего-то столь же простого, как получение небольшого количества данных о местоположении.Вам нужно будет переопределить некоторые его функции по умолчанию, которые вы должны либо вызвать напрямую с помощью super, либо полностью заменить.

И, наконец, создание подклассов создает тесно связанную иерархию классов, которая не имеет смысла, если ваш подкласс не аналогичен по своей природе классу, который вы подклассифицируете. Это маловероятно, если вы просто отвечаете на обновления местоположения по GPS.

Как насчет шаблона «Наблюдатель» в NotificationCenter в качестве альтернативы делегированию? Это может сработать: например, вы отреагируете на наблюдаемые изменения в объекте Location.

Шаблон Observable полезен, когда вашему коду необходимо взаимодействовать с несколькими компонентами с отношениями «один ко многим» или «многие ко многим». Один компонент в вашем приложении передает сигнал, на который реагируют несколько других компонентов. И кроме типа вещания и некоторых связанных данных, вы не можете формализовать требования к обмену данными, как это может сделать протокол.

Жизнеспособной альтернативой шаблону делегирования является простое использование замыканий.Вместо вызова функции делегата класс делегирования вызывает закрытие, которое заранее определено как свойство класса делегирования.

Все большее количество классов и компонентов iOS SDK теперь предлагает закрытие в качестве альтернативы делегированию и целевому действию, например Timer.

Использование функции закрытия для передачи обслуживания имеет те же преимущества, что и использование делегирования (гибкость, легкость, развязка). Использование закрытия в качестве делегата имеет один главный недостаток: ими сложно управлять и организовывать, если вы используете слишком много из них.Promises или async / await — полезный подход для управления множественными асинхронными замыканиями.

И последнее, прежде чем вы начнете … Типичная ошибка новичка — сделать контроллер представления делегатом всего. Вы не обязаны!

Некоторые альтернативы:

• Создайте отдельный класс делегата, контроллер, который отвечает за функции делегата
• Используйте расширения Swift для разделения кода, давая каждому набору функций делегата собственное расширение
• Абстрагирование нескольких функций делегата в один контроллер (или «менеджер») и использовать замыкания для ответа на детализированные данные, которые вам действительно нужны. полный класс или структура
• Делегирование полезно для отношений «один-на-один», тогда как шаблон наблюдателя больше подходит для отношений «один-ко-многим» и «многие-ко-многим».
• Делегирование является гибким, потому что оно не требует, чтобы делегирующий класс знал что-либо о делегате — только то, что он соответствует протоколу
• Замыкания являются жизнеспособной альтернативой делегированию, если базовый класс их поддерживает, при условии, что вы сохраните ваши замыкания простые
• Не делайте контроллер представления делегатом всего; используйте отдельный класс, расширения или вспомогательный класс для разделения функций делегирования

Делегирование сохранит свою важную роль в iOS SDK.Несмотря на то, что это довольно старый шаблон проектирования, он продолжает доказывать свою полезность в практической разработке для iOS.

Это тоже сложно понять. Делегирование затрагивает многие принципы хорошей архитектуры приложения, и легко потеряться, подключившись к той или иной функции. Надеюсь, теперь у вас есть более четкое представление о том, как работает делегирование, для чего оно предназначено и почему вы должны его использовать.

Создайте свое приложение сейчас

Аасиф Хан — SEO-специалист с более чем 10-летним опытом работы в индустрии цифрового маркетинга.Сегодня он является экспертом в области SEO, SMO, SEM, а также является одним из ведущих авторов блога Appy Pie. Он пишет о текущих тенденциях в индустрии цифрового маркетинга. Он любит заниматься в тренажерном зале, а также уделяет время хобби, например, игре в крикет и чтению книг.

Сделайте своих делегатов асинхронными из синхронных делегатов — блог Энтони Гиретти по .NET

Введение

Я хотел написать этот пост, потому что понял, что многие разработчики испытывают трудности с написанием асинхронных делегатов.Я часто вижу синхронные делегаты при проверке кода, которые можно преобразовать. Итак, в этом посте я покажу вам, как действовать, не вдаваясь в подробности о полезности асинхронизма, это не цель этого поста.

Синхронные делегаты

В C # есть 4 типа делегатов, у вас есть делегаты, которые:

• Вернуть результат
• Не возвращает результат

, но также делегирует who:

• Принимает один или несколько параметров.
• Не принимает никаких параметров.

Итак, это 4 способа написать делегата, теперь давайте посмотрим, как это выглядит:

1. Делегат, который не принимает никаких параметров и не возвращает никакого значения: Action
2. Делегат, принимающий один или несколько параметров и не возвращающий никакого значения: Action
3. Делегат, который не делает ‘ t принимает любой параметр и возвращает значение: Func
4. Делегат, который принимает один или несколько параметров и возвращает значение: Func

Давайте посмотрим на конкретный пример того, как это реализовано на практике:

Синхронный к асинхронному делегату

Правило получения синхронного делегата простое:
Не имеет значения, является ли это Action или Func, асинхронная версия всегда будет Func, возвращающей Task , который дает:

1. Асинхронный делегат, который не принимает никаких параметров и не возвращает никакого значения: Func
2. Асинхронный делегат, который принимает один или несколько параметров и не возвращает никакого значения: Func
3. Асинхронный делегат, который не принимает никаких параметров и возвращает значение: Func >
4. Асинхронный делегат, который принимает один или несколько параметров и возвращает значение: Func >

Пример:

Вот и все!

Я надеюсь, что это руководство помогло вам понять, как преобразовать ваших делегатов в асинхронных делегатов! Удачного программирования 🙂

Нравится:

Нравится Загрузка…

Мощный мир делегатов — Блог программирования Xojo

Delegates — одна из тех расширенных функций, которые вы можете найти в языке программирования Xojo, и это действительно мощная функция! Как только вы откроете для себя и поймете всю гибкость, которую вы можете получить от Delegtes, я почти уверен, что вы начнете их использовать!

Но что такое Делегат ? Мы можем определить его как определение типа данных для сигнатуры метода (или функции).То есть: когда вы определяете новый тип делегата, вам необходимо предоставить ему конкретный метод или сигнатуру функции. И здесь все начинается.

После того, как вы определили новый тип делегата, вы можете использовать его в своем коде, как и с любым другим типом данных. Так, например, вы можете добавить свойство к любому объекту (Windows, WebPage, iOSView, Class, subclass…) и определить его тип как только что созданный тип делегата.

Это означает, что во время выполнения кода вашего приложения вы можете изменить, например, значение свойства Delegate, чтобы оно сохраняло ЛЮБОЙ метод или функцию, соответствующие подписи делегата, а затем вы можете вызывать их! Главное здесь то, что с помощью делегатов вы можете динамически изменять код для выполнения.

Давайте посмотрим, как это работает, на простом примере: случайное рисование в экземпляр класса Graphic с использованием этого кода будет работать с любым экземпляром графики, который вы передаете в качестве параметра.

Создание делегата

Конечно, первым шагом является определение нашего типа данных Delegate. В новом проекте Desktop выберите Insert> Delegate и используйте панель Inspector, чтобы изменить его значения на:

• Имя делегата: FigureDelegate
• Параметры: г как Графика

Вуаля! Мы создали новый тип данных, который может указывать на любой метод, соответствующий этой сигнатуре.

Использование типа делегата

Как и любой из стандартных типов данных или созданных вами классов, вы можете создавать новые переменные или свойства, тип данных которых является нашим типом делегата. Например, добавьте новое свойство к элементу Window1 и измените его определение в инспекторе панелей так, чтобы оно выглядело так:

• Имя: Делегаты ()
• Тип: РисунокDelegate

Наше свойство Delegate будет массивом, хранящим значения FigureDelegates.

Создание методов сопоставления

Теперь давайте добавим несколько методов, соответствующих нашей сигнатуре делегата, чтобы мы могли добавить их в качестве значений в наш массив Delegates ().

Первый будет случайным образом рисовать линию в полученном графическом контексте в качестве параметра. Итак, добавьте новый метод в Window1 и используйте панель Inspector, чтобы изменить его значения на:

• Имя метода: DrawLine
• Параметры: г как Графика

И напишите следующий код в соответствующем редакторе кода:

 г.ClearRectangle (0,0; g.Width, g.Height)

Var rd As New random
Var x, y, w, h как двойное

g.PenSize = 2
g.DrawingColor = RGB (rd.InRange (0,255), rd.InRange (0,255), rd.InRange (0,255))

x = rd.InRange (0, ширина g)
y = rd.InRange (0, g.Height)
w = rd.InRange (0, ширина g)
h = rd.InRange (0, g.Height)

g. чертеж (x, y, w, h) 

Наш второй метод нарисует овалы; Итак, добавьте новый метод к элементу Window1 и измените его значения на:

• Название метода: DrawOval
• Параметры: г как Графика

И напишите следующий код в соответствующем редакторе кода:

 г.ClearRectangle (0,0; g.Width, g.Height)

Var rd As New random
Var x, y, w, h как двойное

g.PenSize = 2
g.DrawingColor = rgb (rd.InRange (0,255), rd.InRange (0,255), rd.InRange (0,255))

Var widthAvail как целое число
Var heightAvail как целое число

x = rd.InRange (0, ширина g)
y = rd.InRange (0, g.Height)
widthAvail = g.Width - x
heightAvail = g.Height - y
w = rd.InRange (0, widthAvail)
h = rd.InRange (0, heightAvail)
g.DrawOval (x, y, w, h) 

Затем добавьте третий метод. Этот нарисует веревку. После добавления в элемент Window1 используйте панель инспектора, чтобы изменить его значения на:

• Название метода: DrawText
• Параметры: г как Графика

И поместите следующий фрагмент кода в связанный редактор кода:

 г.ClearRectangle (0,0; g.Width, g.Height)

Статический t As Text = "Hello World!"
Var tc As Double = g.TextWidth (t) / 2

g.DrawText (t, g.Width / 2-tc, g.Height / 2-g.TextHeight / 2) 

Добавление методов к типу делегатов ()

Мы сказали, что тип данных Delegate указывает на метод или функцию; но как мы можем получить эту ценность? Действительно просто! Xojo предоставляет оператор AddressOf, который дает нам адрес памяти, в котором «живет» метод.

Добавьте Open Event Handler в элемент Window1 и добавьте следующий код в связанный редактор кода:

 Image = Новое изображение (ImageWell1.Ширина, ImageWell1.Height, 32)
Delegates.AddRow (AddressOf DrawLine)
Delegates.AddRow (AddressOf DrawOval)
Delegates.AddRow (AddressOf DrawText) 

Добавление экземпляра изображения

Нам понадобится графический контекст для рисования. Для этого мы добавим новое свойство к нашему элементу Window1, используя панель инспектора, чтобы изменить его значения на:

• Имя: Изображение
• Тип: Изображение

Макет пользовательского интерфейса

Теперь займемся пользовательским интерфейсом, чтобы увидеть, как все работает.

Выберите Window1, чтобы открыть редактор макета для окна приложения по умолчанию. Затем добавьте элементы управления ImageWell и PushButton из библиотеки в редактор макета. Измените их положение и размер ImageWell, чтобы они совпадали со следующим снимком экрана:

Наконец, добавьте обработчик событий действия к только что добавленной кнопке PushButton и напишите следующий фрагмент кода в соответствующем редакторе кода:

 Var rd как новый случайный
Var d как фигура Делегат

d = делегаты (rd.InRange (0, Delegates.LastRowIndex))

d.Invoke (image.Graphics)

ImageWell1.Image = Изображение 

Как видите, мы определили новую переменную FigureDelegate и присвоили ей случайное значение из нашего массива делегатов. Затем нам нужно только вызвать метод (или функцию), на который указывает тип данных Delegate, используя для него метод Invoke. Запустите пример приложения и посмотрите, как оно себя ведет.

Как видите, используя эту технику, вы можете использовать те же методы, например, для любого экземпляра изображения.

делегированных объектов недвижимости в Котлине | Baeldung на Котлине

Язык программирования Kotlin имеет встроенную поддержку свойств класса.

Свойства обычно подкрепляются непосредственно соответствующими полями, но это не всегда должно быть так — до тех пор, пока они правильно открыты для внешнего мира, они все равно могут считаться свойствами.

Этого можно достичь, обработав это в геттерах и сеттерах, или используя возможности делегатов.

Проще говоря, делегированные свойства не поддерживаются полем класса и делегируют получение и настройку другому фрагменту кода. Это позволяет абстрагировать делегированные функции и совместно использовать их между несколькими аналогичными свойствами — например, хранение значений свойств на карте вместо отдельных полей.

Делегированные свойства используются путем объявления свойства и делегата, который он использует. Ключевое слово на указывает, что свойство контролируется предоставленным делегатом, а не его собственным полем.

Например:

  class DelegateExample (map: MutableMap ) {
    имя переменной: Строка по карте
}  

Здесь используется тот факт, что MutableMap сам является делегатом, что позволяет вам рассматривать его ключи как свойства.

Стандартная библиотека Kotlin поставляется с набором стандартных делегатов, готовых к использованию.

Мы уже видели пример использования MutableMap для поддержки изменяемого свойства. Таким же образом вы можете поддерживать неизменяемое свойство с помощью карты Map , что позволяет обращаться к отдельным полям как к свойствам, но не изменять их.

Ленивый делегат позволяет вычислять значение свойства только при первом доступе, а затем кэшировать. Это может быть полезно для свойств, вычисление которых может быть дорогостоящим и которое может вам никогда не понадобиться — например, загружается из базы данных:

  class DatabaseBackedUser (userId: String) {
    val name: String by lazy {
        queryForValue ("ВЫБРАТЬ имя ИЗ пользователей, ГДЕ userId =: userId", mapOf (от "userId" до userId)
    }
}  

Наблюдаемый делегат позволяет запускать лямбду каждый раз, когда значение свойства изменяется, например, разрешая уведомления об изменениях или обновление других связанных свойств:

  class ObservedProperty {
    var name: строка делегатов.наблюдаемый ("<не задано>") {
        prop, old, new -> println ("Старое значение: $ old, Новое значение: $ new")
    }
}  

Начиная с Kotlin 1.4, также можно передавать права напрямую другому объекту. Например, если мы переименовываем свойство в классе API, мы можем оставить старое на месте и просто передать его новому:

  class RenamedProperty {
    var newName: String = ""

    @Deprecated ("Вместо этого используйте newName")
    var name: String by this :: newName
}  

Здесь каждый раз, когда мы обращаемся к свойству name , мы фактически вместо этого используем свойство newName .

  класс DatabaseDelegate <в R, T> (readQuery: String, writeQuery: String, id: Any): ReadWriteDelegate  {
    весело getValue (thisRef: R, свойство: KProperty <*>): T {
        вернуть queryForValue (readQuery, mapOf (от "id" до id))
    }

    весело setValue (thisRef: R, свойство: KProperty <*>, значение: T) {
        update (writeQuery, mapOf (от «id» к id, «value» к значению))
    }
}  

  class DatabaseUser (userId: String) {
    имя переменной: Строка от DatabaseDelegate (
      "ВЫБРАТЬ имя ИЗ пользователей, ГДЕ userId =: id",
      "ОБНОВЛЕНИЕ пользователей SET name =: value WHERE userId =: id",
      Идентификатор пользователя)
    var email: String от DatabaseDelegate (
      "ВЫБРАТЬ электронную почту ОТ пользователей, ГДЕ userId =: id",
      "ОБНОВЛЕНИЕ пользователей SET email =: value WHERE userId =: id",
      Идентификатор пользователя)
}  

  класс DatabaseDelegateProvider <код> <в R, T> (readQuery: String, writeQuery: String, id: Any)
    : PropertyDelegateProvider > {
    переопределить оператор fun provideDelegate (thisRef: T, prop: KProperty <*>): ReadWriteDelegate  {
        if (prop.returnType.isMarkedNullable) {
            вернуть NullableDatabaseDelegate (readQuery, writeQuery, id)
        } еще {
            вернуть NonNullDatabaseDelegate (readQuery, writeQuery, id)
        }
    }
}