Ваше представление об MVP в корне неверно. Либо вы читали такие же некорректные статьи, либо некорректно интерпретировали. У вас даже на КДПВ нет ссылки от Model к View. Хотя и она неверна, т.к. связи должны быть односторонними, а в обратную сторону работа идёт через интерфейсы.
Так в Model вы и не знаете про View ни чего
Вы обманываете, т.к. эти ваши
edittext-а, а во втором из spinner-а
— это часть View.
каждая реализация оборачивает свои UI элементы в Model, представляя общий интерфейс доступа к данным.
Я не занимаюсь разработкой под Android, но в идеальном варианте ни Model, ни Presenter не имеют доступа ни то, что к View, но и к пакету android в принципе, т.е. они не знают, что работают под android'ом. И уж особенно нельзя нарушать правила разделения зависимостей между M, V и P — код в разных модулях и зависимости между ними настроены односторонне M<=P<=V, это принципиально.
MVP это про распределение обязанностей и зависимостей, в вашем случае реализация примера должна иметь следующий вид: Пакет Model:
класс с данными ExampleModel Пакет Presenter:
интерфейс ExampleView с методом updateResponse(String response)
класс ExamplePresenter'а с методами doRequest(String response) Пакет View:
класс-реализация интерфейса ExampleView
ExampleView дёргает ExamplePresenter.doRequest, ExamplePresenter устанавливает в ExampleModel данные запроса, и делает запрос на сервер, когда получает ответ, то устанавливает его в ExampleModel и дёргает метод интерфейса ExampleView.updateResponse.
Также важно выделять весь View в отдельный пакет и обращаться только через интерфейсы, т.к. это позволит делать unit тесты, подменив реализации на тестовые.
150 человек добавило эту статью в избранное — кто-то мог воспринять её серьёзно. Рекомендую удалить её пока, ознакомиться с темой более внимательно и написать действительно полезную статью. В качестве хорошей реализации MVP рекомендую ознакомиться с реализацией на www.mvcsharp.org (она на c#, но смысл от этого не меняется). Плюс там есть несколько статей на эту тему. Можете консультироваться, если будут вопросы.
Мне кажется, стоит совмещать оба подхода — то есть можно «побродить», а в некоторых местах — action point'ы, показывающие красивый рендер в полную силу. 3D перемещение даёт прочувствовать помещение, а рендереры — увидеть его правильно. В этом случае в голове будет совмещаться «топология» и картинка и будет более сильное впечатление от увиденного.
Квантовые эффекты ответственны за процесс фотосинтеза у растений:
Другой биологический процесс, в котором работает перепутывание(квантовая запутанность), — фотосинтез, с помощью которого растения преобразуют солнечный свет в химическую энергию. Свет высвобождает внутри клетки электроны, стремящиеся найти путь в одно и то же место — центр химической реакции, где они отдают свою энергию и запускают реакции, снабжающие энергией клетки растения. Классическая физика не в состоянии объяснить, как они делают это с почти стопроцентной эффективностью.
(Жизнь в квантовом мире)
В процессе фотосинтеза вырабатывается кислород. Вот какое влияние оказывают квантовые эффекты на макромир.
Если искать в макромире прямые аналоги явлений микромира, вроде туннельного эффекта или квантовой спутанности, то ничего, конечно, найдено не будет из-за того, что макрообъекты представляют собой огромные ансамбли квантов, непрерывно взаимодействующих между собой и окружающим миром (случается коллапс волновой ф-ции, декогеренция и т.д.)
Правильная похвала нужному человеку в нужное время правильными словами — это один из самых эффективных и дешевых мотивирующих факторов.
Про это очень хорошо написано в книге «Менеджер за одну минуту» Кеннета Бланшара. И не только про это, вообще хорошая книга про управление.
Не подлежат делегированию
— Выработка стратегии и политики
— Постановка целей
— Контроль результатов
— Критические задачи (с высокой степенью риска)
С этим не соглашусь.
Непосредственные исполнители должны участвовать в выработке стратегии и политики, просто потому что они потом будут действовать согласно этой стратегии. Политика, «спущенная» сверху, какой бы идеальной она не была — работать будет хуже, чем разработанная совместно с непосредственными исполнителями — просто потому что тогда непосредственный исполнитель будет понимать, что он собственно говоря сам все это придумал и поэтому это надо делать, а не потому что «на шефа опять блажь нашла».
Соответственно, постановку целей (в определенных пределах) также можно делегировать — чтобы в рамках общей стратегии (выработанной собственно с самими сотрудниками) сотрудники могли сами ставить и выбирать цели.
Контроль результатов, особенно контроль результатов деятельности отдела также можно давать сотрудникам. Предоставление сотрудникам доступа к отчетам и результатам деятельности всего отдела позволяет сотрудникам:
— лучше понимать что и зачем они делают
— сотрудники могут помогать вырабатывать стратегию на основе полученных данных
Также можно разработать систему мотивации, в которой каждый сотрудник будет заинтересован в результатах работы его отдела (подразделения) — например, дать каждому сотруднику % от прибыли его отдела в качестве премии — тогда все сотрудники будут контролировать результаты работы друг друга и отдела в целом, и вносить рацпредложения чтобы повысить прибыльность своего отдела (подразделения) и в результате — собственное вознаграждение. Подробнее про это можно почитать в книге «3 ключа к созданию новой структуры управления» — профессионалы излагают и объясняют это лучше чем я
Критические задачи с высокой степенью риска также нужно уметь делегировать, иначе получится аналог «Василия», начальник, который все делает сам. Что мы подразумеваем под «высокой степенью риска»? Начиная с какой степени риска надо впрягаться в исполнение задачи самому?
Ну и вообще, на самом деле я не соглашусь в целом с идеей статьи и с идеей алгоритма из 6 шагов. Если следовать алгоритму из вашей статьи то вся работа начальника будет сводится к изучению результатов деятельности сотрулников и поставновке им новых задач.
Я считаю, что алгоритм должен быть разным для разных сотрудников, в зависимости от компетенции и мотивированности этого сотрудника.
Если вкратце, управление можно разделить на два основных типа:
1. Командование
2. Поддержка
В статье описан как раз первый тип — командование, когда сотруднику четко сообщается — кто, что, когда и т.д.
Второй тип — поддержка — когда перед сотрудником не ставится четких целей, ставится только общая стратегия, и ему предлагается самостоятельно решать возникающие проблемы. Руководитель оказывает поддержку, помогает с разрешением сложных проблем и т.д., но не слишком вдается в детали и не пытается четко формулировать все цели, оставляя это право сотруднику.
Нужно только понимать, в какой ситуации какой тип управления необходимо применять.
У того же Бланшара это достаточно хорошо описано — фактически, каждый сотрудник в процессе работы проходит через 4 основные стадии:
1 этап. Когда человек только пришел на работу в компанию, он обычно достаточно хорошо мотивирован для работы, но имеет довольно низкую компетенцию, из-за того что он еще плохо знаком с вашей компанией и вашими продуктами, принципами работы и т.д.
На этом этапе требуется абсолютно директивное управление — если говорить вашими словами, то сотрудник должен получать все 6 пунктов (кто, что, почему, как, какими средствами и когда) — чтобы его компетенция повышалась.
2 этап. Человек проработал 2-3 месяца в вашей компании, его компетенция все еще не очень высока, но уже лучше чем было, а мотивация падает — он уже считает что «закрепился» в вашей команде.
Здесь человеку требуется некий наставительный тип управления — когда ему одновременно все еще ставятся четкие цели и задачи, но при этом он уже вовлекается в процесс планирования, обсуждения методов решения и т.д.
3 этап. Человек достаточно долго проработал в вашей компании, его уровень компетенции высок, но мотивация все еще невысока. На этом этапе можно начинать уходить от вашей концепции «6 пунктов» — благодаря высокой компетенции человек уже может самостоятельно решать «как, какими средствами».
При этом сотруднику все еще требуется поддержка — но не командование. Грубо говоря, вы с ним совместно обсуждаете вопросы «кто, почему и когда». Также он участвует в планировании (т.е. сам помогает ответить на вопрос «что»).
4 этап. Сотрудник становится профессионалом. Профессионал способен самостоятельно ответить на ваши вопросы «как, какими средствами, кто, почему, когда». При работе с профессионалом, от руководителя требуется только ответ на вопрос «что» — но и он может быть делегирован профессионалу.
Таким образом, если руководитель будет следовать этому алгоритму, а не вашему, то его работа в корне изменится — основной его задачей будет стратегическое планирование, в котором ему будут помогать профессионалы из его отдела, а также рост сотрудников — т.е. его целью будет постепенный перевод всех сотрудников из 1 этапа в 4.
Конечной целью руководителя является создание крепкого отдела матерых профессионалов, с которыми он сможет перестать каждый раз отвечать на ваши 6 вопросов.
Если коротко, то накопите немного денег на эксперимент, и купите своё собственное время по вашей стандартной ставке на пару недель. И в течении этой пары недель попытайтесь получить и сделать заказы по $20, $30, $40 и доведите эту границу до явных отказов. Так вы узнаете сколько вы стоите без риска(вы заранее сами купили своё время и риска потерять денег больше чем вы ранее отложили на это не получится). Таким образом за фиксированную заранее цену вы научитесь так делать. Покупайте себе билеты на такой аттракцион. Когда вы чётко знаете затраты которые вы понесёте и обладаете этими финансами заренее действовать проще.
<зануда mode>
Приведенную схему назвать блок-схемой алгоритма нельзя, т.к. она не соответствует:
ГОСТ 19.701-90. Схемы алгоритмов, программ, данных и систем. Условные обозначения и правила выполнения.
ГОСТ 19.002-80. Схемы алгоритмов и программ. Правила выполнения.
ГОСТ 19.003-80. Схемы алгоритмов и программ. Обозначения условные графические.
Изображенное на схеме также нельзя назвать алгоритмом, как минимум потому как:
1. Не обладает свойством детерминированности, когда каждое правило должно быть чётким и однозначным.
2. Не обладает свойством результативности, т.е. не приводит к конкретному конечному результату за конечное число шагов.
Данный рисунок можно отнести только к классу интеллект-карт (mind map).
</зануда mode>
Вы обманываете, т.к. эти ваши — это часть View.
Я не занимаюсь разработкой под Android, но в идеальном варианте ни Model, ни Presenter не имеют доступа ни то, что к View, но и к пакету android в принципе, т.е. они не знают, что работают под android'ом. И уж особенно нельзя нарушать правила разделения зависимостей между M, V и P — код в разных модулях и зависимости между ними настроены односторонне M<=P<=V, это принципиально.
MVP это про распределение обязанностей и зависимостей, в вашем случае реализация примера должна иметь следующий вид:
Пакет Model:
класс с данными ExampleModel
Пакет Presenter:
интерфейс ExampleView с методом updateResponse(String response)
класс ExamplePresenter'а с методами doRequest(String response)
Пакет View:
класс-реализация интерфейса ExampleView
ExampleView дёргает ExamplePresenter.doRequest, ExamplePresenter устанавливает в ExampleModel данные запроса, и делает запрос на сервер, когда получает ответ, то устанавливает его в ExampleModel и дёргает метод интерфейса ExampleView.updateResponse.
Также важно выделять весь View в отдельный пакет и обращаться только через интерфейсы, т.к. это позволит делать unit тесты, подменив реализации на тестовые.
150 человек добавило эту статью в избранное — кто-то мог воспринять её серьёзно. Рекомендую удалить её пока, ознакомиться с темой более внимательно и написать действительно полезную статью. В качестве хорошей реализации MVP рекомендую ознакомиться с реализацией на www.mvcsharp.org (она на c#, но смысл от этого не меняется). Плюс там есть несколько статей на эту тему. Можете консультироваться, если будут вопросы.
(Жизнь в квантовом мире)
В процессе фотосинтеза вырабатывается кислород. Вот какое влияние оказывают квантовые эффекты на макромир.
Если искать в макромире прямые аналоги явлений микромира, вроде туннельного эффекта или квантовой спутанности, то ничего, конечно, найдено не будет из-за того, что макрообъекты представляют собой огромные ансамбли квантов, непрерывно взаимодействующих между собой и окружающим миром (случается коллапс волновой ф-ции, декогеренция и т.д.)
Хотя не знаю, зачем она вам ;) Ведь вряд ли кто-то будет один в один повторять конструкцию. А для другой конструкции другой кросс.
Что касается усилка, то напишите в личку, я дам контакты, с кем можно связаться. Все-таки автор — не я.
Про это очень хорошо написано в книге «Менеджер за одну минуту» Кеннета Бланшара. И не только про это, вообще хорошая книга про управление.
С этим не соглашусь.
Непосредственные исполнители должны участвовать в выработке стратегии и политики, просто потому что они потом будут действовать согласно этой стратегии. Политика, «спущенная» сверху, какой бы идеальной она не была — работать будет хуже, чем разработанная совместно с непосредственными исполнителями — просто потому что тогда непосредственный исполнитель будет понимать, что он собственно говоря сам все это придумал и поэтому это надо делать, а не потому что «на шефа опять блажь нашла».
Соответственно, постановку целей (в определенных пределах) также можно делегировать — чтобы в рамках общей стратегии (выработанной собственно с самими сотрудниками) сотрудники могли сами ставить и выбирать цели.
Контроль результатов, особенно контроль результатов деятельности отдела также можно давать сотрудникам. Предоставление сотрудникам доступа к отчетам и результатам деятельности всего отдела позволяет сотрудникам:
— лучше понимать что и зачем они делают
— сотрудники могут помогать вырабатывать стратегию на основе полученных данных
Также можно разработать систему мотивации, в которой каждый сотрудник будет заинтересован в результатах работы его отдела (подразделения) — например, дать каждому сотруднику % от прибыли его отдела в качестве премии — тогда все сотрудники будут контролировать результаты работы друг друга и отдела в целом, и вносить рацпредложения чтобы повысить прибыльность своего отдела (подразделения) и в результате — собственное вознаграждение. Подробнее про это можно почитать в книге «3 ключа к созданию новой структуры управления» — профессионалы излагают и объясняют это лучше чем я
Критические задачи с высокой степенью риска также нужно уметь делегировать, иначе получится аналог «Василия», начальник, который все делает сам. Что мы подразумеваем под «высокой степенью риска»? Начиная с какой степени риска надо впрягаться в исполнение задачи самому?
Ну и вообще, на самом деле я не соглашусь в целом с идеей статьи и с идеей алгоритма из 6 шагов. Если следовать алгоритму из вашей статьи то вся работа начальника будет сводится к изучению результатов деятельности сотрулников и поставновке им новых задач.
Я считаю, что алгоритм должен быть разным для разных сотрудников, в зависимости от компетенции и мотивированности этого сотрудника.
Если вкратце, управление можно разделить на два основных типа:
1. Командование
2. Поддержка
В статье описан как раз первый тип — командование, когда сотруднику четко сообщается — кто, что, когда и т.д.
Второй тип — поддержка — когда перед сотрудником не ставится четких целей, ставится только общая стратегия, и ему предлагается самостоятельно решать возникающие проблемы. Руководитель оказывает поддержку, помогает с разрешением сложных проблем и т.д., но не слишком вдается в детали и не пытается четко формулировать все цели, оставляя это право сотруднику.
Нужно только понимать, в какой ситуации какой тип управления необходимо применять.
У того же Бланшара это достаточно хорошо описано — фактически, каждый сотрудник в процессе работы проходит через 4 основные стадии:
1 этап. Когда человек только пришел на работу в компанию, он обычно достаточно хорошо мотивирован для работы, но имеет довольно низкую компетенцию, из-за того что он еще плохо знаком с вашей компанией и вашими продуктами, принципами работы и т.д.
На этом этапе требуется абсолютно директивное управление — если говорить вашими словами, то сотрудник должен получать все 6 пунктов (кто, что, почему, как, какими средствами и когда) — чтобы его компетенция повышалась.
2 этап. Человек проработал 2-3 месяца в вашей компании, его компетенция все еще не очень высока, но уже лучше чем было, а мотивация падает — он уже считает что «закрепился» в вашей команде.
Здесь человеку требуется некий наставительный тип управления — когда ему одновременно все еще ставятся четкие цели и задачи, но при этом он уже вовлекается в процесс планирования, обсуждения методов решения и т.д.
3 этап. Человек достаточно долго проработал в вашей компании, его уровень компетенции высок, но мотивация все еще невысока. На этом этапе можно начинать уходить от вашей концепции «6 пунктов» — благодаря высокой компетенции человек уже может самостоятельно решать «как, какими средствами».
При этом сотруднику все еще требуется поддержка — но не командование. Грубо говоря, вы с ним совместно обсуждаете вопросы «кто, почему и когда». Также он участвует в планировании (т.е. сам помогает ответить на вопрос «что»).
4 этап. Сотрудник становится профессионалом. Профессионал способен самостоятельно ответить на ваши вопросы «как, какими средствами, кто, почему, когда». При работе с профессионалом, от руководителя требуется только ответ на вопрос «что» — но и он может быть делегирован профессионалу.
Таким образом, если руководитель будет следовать этому алгоритму, а не вашему, то его работа в корне изменится — основной его задачей будет стратегическое планирование, в котором ему будут помогать профессионалы из его отдела, а также рост сотрудников — т.е. его целью будет постепенный перевод всех сотрудников из 1 этапа в 4.
Конечной целью руководителя является создание крепкого отдела матерых профессионалов, с которыми он сможет перестать каждый раз отвечать на ваши 6 вопросов.
Как-то так.
Приведенную схему назвать блок-схемой алгоритма нельзя, т.к. она не соответствует:
ГОСТ 19.701-90. Схемы алгоритмов, программ, данных и систем. Условные обозначения и правила выполнения.
ГОСТ 19.002-80. Схемы алгоритмов и программ. Правила выполнения.
ГОСТ 19.003-80. Схемы алгоритмов и программ. Обозначения условные графические.
Изображенное на схеме также нельзя назвать алгоритмом, как минимум потому как:
1. Не обладает свойством детерминированности, когда каждое правило должно быть чётким и однозначным.
2. Не обладает свойством результативности, т.е. не приводит к конкретному конечному результату за конечное число шагов.
Данный рисунок можно отнести только к классу интеллект-карт (mind map).
</зануда mode>