Абсолютно аналогичная ситуация, но только с Win 8. Качаю по линку из этого поста, скачивается версия 14.10.2062.12521 (387201c). Абсолютно не похожа на альфу :)
Он то симпатичней, да, но в Coggle, по моему мнению, не очень удачно реализован механизм добавления новых узлов с клавиатуры, это можно сделать только находясь в режиме радактирования узла. Также механизм автоматического расположения узлов там, можно сказать, отсутствует и расположение узлов всё время приходится ровнять руками.
В итоге из бесплатных прешёл на MindMup, из платных Mindmeister
Если мы действительно решаем одноразовую задачу получить список и ничего более, то формально я соглашусь с тем что предложил VolCh. И на этом всё, делайте потом с этим списком что хотите и как хотите ;)
Если же мы пытаемся решать какую то более сложную задачу являющуюся частью более сложной системы то я всё же использовал бы более обобщенное решение. Хотя тоже проще чем то, что я предложил изначально.
я бы разбил задачу на две части.
1. Выборка детей из списка по некоему критерию. Тут возможно несколько решений, но я всё же вынес бы тот код который принимает решение о том попал ребёнок в список или нет в какую-то внешнюю сущность.
2. Пробежаться по полученному списку и раздать Подарки. Предыдущие оппоненты действительно убедили меня, что я слишком мало знаю о задаче, потому, на самом деле, делайте с этим результирующим списком что угодно :)
Ну и опять же, при желании оба этапа можно объединить :)
Дальнейшие рассуждения можно делать только получив больше информации.
Но, как по мне, единственное о чём это говорит, так это то, что я зря взялся выдавать какие-то решения имея столько общую постановку :) и ни разу не является аргументом в споре «все остальные» vs ООП (это в основном к выводу «Мы опять пришли к процедурному программированию»)
если мы рассматриваем одноразовое решение одноразовой задачи в результате которой получаем список показанный на мониторе, например, то никаких проблем, обходимся процедурным подходом.
хорошо, допустим мы сделаем так, как вы предлагаете, и оставим всё в одном классе но разобьём всё на кучку методов. Что вы будете делать когда вас попросят раздавать подарки не только на Новый Год но и, допустим, на Рождество и выбирать надо будет по абсолютно разным критериям?
И сразу про YAGNI. Эта задача, в том, вырванном из контекста виде, в каком нам её показали, понятное дело абсолютно прекрасно решается вообще без какого-либо ООП и прочего, но, раз уж мы договорились о том, что будем использовать для её решения ООП, давайте всё же предполагать что это часть какой-то большой системы которая претендует пережить один запуск.
ну и ещё одно ограничение вы забыли, как и многие кто предлагает решить это простым sql запросом ;) просили не выдавать два подарка ребёнку если оба его родителя являются сотрудниками. Это конечно скорее всего всё ещё решается в терминах sql, но я бы уже не стал назвать это простыми запросами.
Не соглашусь. Пока просто не соглашусь. Перед тем как вступать в дискуссию было бы очень интересно послушать по каким причинам всё это не удовлетворяет принципу YAGNI. И предлагаю начать с ВыбиралкиПодарка. Также было бы очень интересно если бы вы провели параллели с SOLID.
Можно попробовать взглянуть на проблему используя те идеи, что предлагает автор статьи и попытаться выделить ключевые концепции, помня, что объектами могут быть не только некие существительные, но и процессы/действия.
Получим примерно такой список сущностей с которыми нам придётся оперировать:
— самое очевидное это: Сотрудник, Ребёнок;
— раз мы дарим подарки то нам надо их как-то обозначить, соответсвенно появляется — Подарок;
— так как нам надо выбирать подарок для ребёнка основываясь на каких то правилах, которые могут в том числе и поменяться, то надо бы изолировать способ выбора подарка в отдельную сущность, например, ВыбиралкаПодарка. Всё что она делает — получает на вход Ребёнка и возвращает для него Подарок;
— так как нам надо как-то связать Подарок и Ребёнка, то появится, например, сущность ПодарочныйСертификат;
— так как нам необходим сам процесс раздачи подарков детям, то появится сущность которая перебирает этих самых Сотрудников и для каждого Ребёнка этого самого сотрудника с помощью ВыбиралкиПодарков выбирает этот самый Подарок. Назовём этот процесс РаспределительПодарков;
— но так как в чистой теории Подарки выбираются не из воздуха, то появляется некое ХранилищеПодарков из которого этот самый РаспределительПодарков будет таскать Подарки и скорее всего надо бы учесть что Подарки иногда могут и закончиться :(
— сам по себе процесс выбора Подарка с помощью ВыбиралкиПодарков и последующее получение Подарка из ХранилищаПодарков с последующей выдачей этого Подарка Ребёнку (т.е. созданием ПодарочногоСертификата) тоже весьма хороший кандидат на выделение в отдельную сущность, назовём его мммм… ВыдавательПодарочныхСертификатов :)
— если мы хотим быть справедливыми и выдать каждому Ребёнку по Подарку и никого при этому не забыть или никому не дать два, то нам надо ещё какая-нибудь структурка где мы будем хранить сведения о том кому чего дали. А если учесть что Подарки у нас в ХранилищеПодарков могут и кончиться, а потом опять появиться (мало ли завезли ещё) то она будет вообще полезной штуковиной.
Понятное дело что результатом работы РаспределителяПодарков будет список ПодарочныхСертификатов. Если надо сгенерировать только список то ХранилищеПодарков можно выкинуть.
По хорошему, согласно идеологии, нельзя применять лишь какие-то фичи из скрама, XP и т.п. Или идеология применяется в полном объёме или это не скрам.
А из текста складывается впечатление что внедрение у вас проходило по принципу «что запомнили то и применили» :) и без Scrum Master'а будет вам грустно похоже.
Поддержу рекомендации первых двух книг. Книга Фланагана вообще по моему единственная доступная на русском книга которая рассказывает о JavaScript именно как о языке.
По поводу метода CheckLogin. В первую очередь нельзя оставлять пустые cacth. Оставив пустой catch вы сами провоцируете ситуацию с которой же потом и боретесь.
В итоге из бесплатных прешёл на MindMup, из платных Mindmeister
Если мы действительно решаем одноразовую задачу получить список и ничего более, то формально я соглашусь с тем что предложил VolCh. И на этом всё, делайте потом с этим списком что хотите и как хотите ;)
Если же мы пытаемся решать какую то более сложную задачу являющуюся частью более сложной системы то я всё же использовал бы более обобщенное решение. Хотя тоже проще чем то, что я предложил изначально.
я бы разбил задачу на две части.
1. Выборка детей из списка по некоему критерию. Тут возможно несколько решений, но я всё же вынес бы тот код который принимает решение о том попал ребёнок в список или нет в какую-то внешнюю сущность.
2. Пробежаться по полученному списку и раздать Подарки. Предыдущие оппоненты действительно убедили меня, что я слишком мало знаю о задаче, потому, на самом деле, делайте с этим результирующим списком что угодно :)
Ну и опять же, при желании оба этапа можно объединить :)
Дальнейшие рассуждения можно делать только получив больше информации.
Но, как по мне, единственное о чём это говорит, так это то, что я зря взялся выдавать какие-то решения имея столько общую постановку :) и ни разу не является аргументом в споре «все остальные» vs ООП (это в основном к выводу «Мы опять пришли к процедурному программированию»)
И сразу про YAGNI. Эта задача, в том, вырванном из контекста виде, в каком нам её показали, понятное дело абсолютно прекрасно решается вообще без какого-либо ООП и прочего, но, раз уж мы договорились о том, что будем использовать для её решения ООП, давайте всё же предполагать что это часть какой-то большой системы которая претендует пережить один запуск.
Получим примерно такой список сущностей с которыми нам придётся оперировать:
— самое очевидное это: Сотрудник, Ребёнок;
— раз мы дарим подарки то нам надо их как-то обозначить, соответсвенно появляется — Подарок;
— так как нам надо выбирать подарок для ребёнка основываясь на каких то правилах, которые могут в том числе и поменяться, то надо бы изолировать способ выбора подарка в отдельную сущность, например, ВыбиралкаПодарка. Всё что она делает — получает на вход Ребёнка и возвращает для него Подарок;
— так как нам надо как-то связать Подарок и Ребёнка, то появится, например, сущность ПодарочныйСертификат;
— так как нам необходим сам процесс раздачи подарков детям, то появится сущность которая перебирает этих самых Сотрудников и для каждого Ребёнка этого самого сотрудника с помощью ВыбиралкиПодарков выбирает этот самый Подарок. Назовём этот процесс РаспределительПодарков;
— но так как в чистой теории Подарки выбираются не из воздуха, то появляется некое ХранилищеПодарков из которого этот самый РаспределительПодарков будет таскать Подарки и скорее всего надо бы учесть что Подарки иногда могут и закончиться :(
— сам по себе процесс выбора Подарка с помощью ВыбиралкиПодарков и последующее получение Подарка из ХранилищаПодарков с последующей выдачей этого Подарка Ребёнку (т.е. созданием ПодарочногоСертификата) тоже весьма хороший кандидат на выделение в отдельную сущность, назовём его мммм… ВыдавательПодарочныхСертификатов :)
— если мы хотим быть справедливыми и выдать каждому Ребёнку по Подарку и никого при этому не забыть или никому не дать два, то нам надо ещё какая-нибудь структурка где мы будем хранить сведения о том кому чего дали. А если учесть что Подарки у нас в ХранилищеПодарков могут и кончиться, а потом опять появиться (мало ли завезли ещё) то она будет вообще полезной штуковиной.
Понятное дело что результатом работы РаспределителяПодарков будет список ПодарочныхСертификатов. Если надо сгенерировать только список то ХранилищеПодарков можно выкинуть.
Вроде всё :)
А из текста складывается впечатление что внедрение у вас проходило по принципу «что запомнили то и применили» :) и без Scrum Master'а будет вам грустно похоже.