You need to bug me more ...

[Lisa]

Мой комментарий был насчет вашего изначального поста, где вам сказали что нужно видеть bigger picture, а вы в ответ на это подписались на скрам. Скрам тут вообще никаким боком. Но дело ваше конечно.
Что касается хорошести программиста, который пишет простейший кусок кода и при этом не понимает почему он в нем использует конкретный дизайн, и ему для этого нужен архитектор и дизайн документ...

[Сабина]

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

По той же причине и strategy не нужен, если мы говорим об одном и том же стратежи.
Если интересно обсуждать, объясню на примере кода

Я про это http://en.wikipedia.org/wiki/Strategy_pattern
Конкретная имплементация выбирается в завтсимости от контекста ( на какую платформу задеплоено хозяйство)

[Сабина]

Мой комментарий был насчет вашего изначального поста, где вам сказали что нужно видеть bigger picture, а вы в ответ на это подписались на скрам. Скрам тут вообще никаким боком. Но дело ваше конечно.
Что касается хорошести программиста, который пишет простейший кусок кода и при этом не понимает почему он в нем использует конкретный дизайн, и ему для этого нужен архитектор и дизайн документ...

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

[valchkou]

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

По той же причине и strategy не нужен, если мы говорим об одном и том же стратежи.
Если интересно обсуждать, объясню на примере кода

Я про это http://en.wikipedia.org/wiki/Strategy_pattern
Конкретная имплементация выбирается в завтсимости от контекста ( на какую платформу задеплоено хозяйство)

фикипедия сбивает с толку обозвав объект контекстом.
Хороший пример паттерна стратегия это сортировка коллекций на ява.
Вот допустим у нас есть стадо тараканов TarakanList - это не контекст, а полноценный объект со своим состоянием и поведением. У нас задача строить этих тараканов по разным признакам: длина усов, цвет, кличка. Но вместо того чтобы писать отдельный метод ка каждый признак, мы имеем один - sort(), который в качестве параметра принимает один из вариантов TarakanSort.
TarakanSort - нам сам по себе не интересен, мы не используем его API на прямую.
Мы просто меняем поведение TarakanList.

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

а вот этот мне видится более подходящим.
Сама фактори инкапсулирует логику выбора имплементации в зависимости от платформы
http://en.wikipedia.org/wiki/Factory_method_pattern
у вас уже есть интерфейс и 2 имплементации.
все что нужно это выбрать нужную имплементацию
при этом использовать API самого интерфейса (а не создавать еще один параллельный API как в случае со Strategy).

Code: Select all

public class FileWorkerFactory {

    public static FileWorker getFileWorker()  {
        if (win)  {
                return new WinFileWorker();
        else
                return new MFFileWorker();
            // etc.
        }
    }
}

[Сабина]

Пожалуй вы правы, покопаю и factory. Спасибо

[Komissar]

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

[Интеррапт]

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

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

[oshibka_residenta]

Пожалуй вы правы, покопаю и factory. Спасибо

По-моему, самое главное все-таки правильные взаимоотношения в коллективе. Если кто-то использовал Adapter вместо Factory, то мир от этого не перевернется.
У многих инженеров (особенно русскоязычных, но не только) есть большое желание найти едиственно-верное решение. Так вот всегда есть много решений, которые "good enough".

[valchkou]

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

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

[Komissar]

пожалуй, в данном случае соглашусь. Тем более речь идет о считывании системной переменной.

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

[Lisa]

Мой комментарий был насчет вашего изначального поста, где вам сказали что нужно видеть bigger picture, а вы в ответ на это подписались на скрам. Скрам тут вообще никаким боком. Но дело ваше конечно.
Что касается хорошести программиста, который пишет простейший кусок кода и при этом не понимает почему он в нем использует конкретный дизайн, и ему для этого нужен архитектор и дизайн документ...

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

С колокольни скрам-мастера никаких big picture не видно. Но дело ваше.

[Сабина]

С колокольни скрам-мастера никаких big picture не видно. Но дело ваше.

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

[Tarasik]

Это что ж девчата, по вашему с высокой колокольни срама не видно ??? Заблуждаетеся вы крепко!!!

[Lisa]

С колокольни скрам-мастера никаких big picture не видно. Но дело ваше.

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

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

[SK]

Грусто что люди делают что им сказали совершенно не задумываясь почему.

Такие работники очень удобны...

[Сабина]

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

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

[dotcom]

Lisa права по поводу Big Picture. Скраммастер - это по большому счету арбитр. Скрам сам по себе устроен так, что каждый участник скрама знает, чем занимается каждый участник во время спринтов и видит главную цель процесса. Меня настораживает формализация процесса и использования ничего не значащих слов типа Big Picture в этом контексте. Обычно, это означает, что с организацией и мотивацией в такой конторе совсем все плохо и реальная работа заменяется организацией бесполезного процесса и бюрократией.

[Сабина]

Lisa права по поводу Big Picture. Скраммастер - это по большому счету арбитр. Скрам сам по себе устроен так, что каждый участник скрама знает, чем занимается каждый участник во время спринтов и видит главную цель процесса. Меня настораживает формализация процесса и использования ничего не значащих слов типа Big Picture в этом контексте. Обычно, это означает, что с организацией и мотивацией в такой конторе совсем все плохо и реальная работа заменяется организацией бесполезного процесса и бюрократией.

Это же было мое review, это было бы с моей стороны ошибкой не поинтересоваться что именно имелось в виду под big picture.
Меня правда совсем не волнует вопрос сделала ли я все что могла по следам review с менеджером ( я тут с самого начала написала что волнуют только слова архитектора), но я могу пояснить раз это вызвало вопрос не у одной Лизы. Тем более что вы утрудились привести аргументы.
Под big picture подразумевалось понимание как многочисленные модулы из которых состоит наш аппликейшен связаны и то как разные кoманды зависят от того что мы делаем на server side. Система контролирует массу многочисленных datasourcesс, практически все что можно найти на мейнфрейме. Это и неудивително что новому человеку это все сразу не охватить. Помимо нашего тима есть больше десятка комманд по столько же девелоперов в каждой. Много inter team dependencies etc. С таким раскладом скрам очень сильно помогает для координации. Потому что координация технических задач как раз и делаеться во имя достижения бизнес целей. Тем более когда Бета выходит в public (только что прошли).
Интересно почему вы на основании слов "big picture" сразу сделали вывод о формализация процесса и использования ничего не значащих слов типа Big Picture в этом контексте. Обычно, это означает, что с организацией и мотивацией в такой конторе совсем все плохо и реальная работа заменяется организацией бесполезного процесса и бюрократией ?
Это один из самых сложных и хорошо организованных проэктов на котором я работала.

[dotcom]

Я не говорю, что видение big picture - это плохо. Плохо, когда big picture можно увидеть только через Скрам и странные процессы координации между командами. Архитектура проекта должна познаваться через независимые от Скрама процессы. Будь то ваша любознательность и желание общаться с сотрудниками и командами, читать спецификации или более активное вовлечение в разработку архитектуры или project management - это уже вторичный вопрос. В хорошо организованной конторе каждый участник проекта должен видеть big picture.

[Сабина]

Я не говорю, что видение big picture - это плохо. Плохо, когда big picture можно увидеть только через Скрам и странные процессы координации между командами. Архитектура проекта должна познаваться через независимые от Скрама процессы. Будь то ваша любознательность и желание общаться с сотрудниками и командами, читать спецификации или более активное вовлечение в разработку архитектуры или project management - это уже вторичный вопрос. В хорошо организованной конторе каждый участник проекта должен видеть big picture.

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

[Сабина]

фикипедия сбивает с толку обозвав объект контекстом.

Евгений, спасибо вам еше раз большое за совет, но я поковырявшись подольше все же решила следовать strategy. У меня задача не совсем такая же как я описала выже но подобная. Имплементация должна вызываться в зависимости от того что случится at runtime.

In computer programming, the strategy pattern (also known as the policy pattern) is a particular software design pattern, whereby algorithms can be selected at runtime. Formally speaking, the strategy pattern defines a family of algorithms, encapsulates each one, and makes them interchangeable. Strategy lets the algorithm vary independently from clients that use it.[1]

[valchkou]

фикипедия сбивает с толку обозвав объект контекстом.

Евгений, спасибо вам еше раз большое за совет, но я поковырявшись подольше все же решила следовать strategy. У меня задача не совсем такая же как я описала выже но подобная. Имплементация должна вызываться в зависимости от того что случится at runtime.

Не за что, вам виднее на месте.
Strategy & Factory Method относятся к разной группе паттернов и применяются для разной цели.
Strategy - изменяет поведение объекта
Factory - определяет как создать инстанс объекта.
Можно например прикрутить factory для создания нужной имплементации strategy at runtime.

[Lisa]

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

[Сабина]

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

Это я встала в детскую позицию ? Вы пришли в эту тему, бросили что все плохо и ушли. Я пыталась развивать предложенное вами направление обьясняя, то что возможно пропустила в первом посте. Причем совсем не потому что мне это интересно ( вопрос то я задала конкоетный и совсем не о том что вы начали комментировать), а потому что не хотела вас обидеть невниманием.
В ответ получила такое же короткое "все плохо, вы неправы", то есть обсуждать это с вами невозможно по любому, только согласиться?
Ну хорошо, плохо и неправы если вам так хочется. Останемся каждый при своем мнении и не будем больше отнимать время друг у друга

[Easbayguy]