К сожалению, нет, ссылки не осталось. Если я правильно помню (а было это давно), то было предложено решение типа вот такого: sysmagazine.com/posts/111649
Если продраться через сильно неродной для автора английский и/или смотреть только на код, то становится понятно, куда копать. Надеюсь, вам поможет.
Когда крупный проект разбит на много задач (в идеале так и должно быть), то такой проблемы нет. В принципе, для сферического проекта в вакууме можно вывести эмпирическое правило: если Mylyn-овский контекст становится слишком большим, то вы неправильно разбиваете работу на конкретные задачи.
Второе: при закрытии редактора с файлом он исчезает из контекста (насколько я помню, это поведение настраивается).
И третье: В сам mylyn встроен алгоритм, по которому определяется релевантность конкретного ресурса (файла, метода, теста, и т.д.). И чем реже вы обращаетесь к этому ресурсу, тем быстрее он «выпадет» из контекста. Не помню сейчас деталей (я присутствовал на презентации Мика Кирстена когда-то давно), но если мне не изменяет склероз, какой-то коэффициент этого затухания интереса тоже настраивается, либо через UI, либо через какой-то конфиг. Если я это придумал — прошу прощения.
Главное в Mylyn (а для меня этот плагин — мастхэв) — это не продвинутое управление задачами, а его главная фишка — контекстный фокус. Очень помогает мыслить рационально, когда все спрятано, кроме того, с чем конкретно работаешь. Ну и еще помогает делать code review или продолжить чью-то работу — открываешь чужой контекст, который сохранен в тракере как аттачмент, и вперед.
Я еще не до конца продумал Ваше решение, но хотелось бы обсудить такой вопрос: насколько оно (решение) будет приложимо для полноценного FluentInterface-а, как он описан, например, у Фаулера (http://martinfowler.com/bliki/FluentInterface.html). К сожалению, я почему-то не могу найти пример такого решения с кодом (на Гугле забанили, похоже), но принцип такой:
class Entity {
public static ActionOne start() {
return new Builder();
}
...
private interface ActionOne {
ActionTwo actionOne_path1();
ActionTwo actionOne_path2();
}
private interface ActionTwo {
Entity build();
}
private class Builder implements ActionOne, ActionTwo {
//тут мы пишем имплементацию методов actionOne_path1, actionOne_path2, build, каждый раз возвращая this
}
Пардон за неаккуратность в коде, думаю, идея понятна.
Я прошу прощения, но у меня не было в планах описывать тонкости работы с JodaTime, тем более, что я в нем, как видно из поста, не специалист. Это был крик души, опубликованный в персональном блоге.
Эээ… А что значит «сразу делать по паттернам»? Зачем вообще продумывать весь код сначала? Почему не дать ему (коду) расти самостоятельно, исправляя искривления сразу, не дожидаясь врастания уродства в другие куски программы? Не знаю, насколько этот рецепт подходит всем, но я просто пишу код (с тестами, да). Если в процессе хоть раз поморщусь (типа, как-то тут неэлегантно получается), я тут же делаю рефакторинг. В результате код получается прямой, читаемый, неповторяющийся, легко тестируемый.
Ну да, опыт, конечно, помогает находить неэлегантные места и подсказывает, что нужно сделать для их исправления, и опыт этот придет. Но если сначала рисовать _всю_ архитектуру, или, не приведи Господь, UML-диаграммы, а потом писать, получится индусский код. Их так учат. Они в своих университетах запоминают сотни умных слов и названий паттернов, но с практическим применением этих знаний у них проблемы. Смотришь на их код, хватаешся за голову. Говоришь ему — друг дорогой, на кой хрен тут нужны 50 строк кода в элеменарном методе? А он говорит: «А я применил паттерн «Сон синглтона в летнюю ночь на фасаде статической фабрики»». А то, что оно тут просто не нужно, что все эти 50 строк превращаются в три, он не задумывается. Не научен.
Подумал-подумал, и решил, что был несколько категоричен. Все вышесказанное — 100% правда. Для случая Java/Scala + Eclipse. Вспомнил времена, когда кодил в VI, и понял, что без хороших инструментов (типа Эклипса), мне было бы намного труднее решиться заниматься рефакторингом не закончив какой-то кусок кода. А сейчас — лафа :) И никаких отмазок, чтобы не делать все правильно.
Исходя из личного опыта, именно так и происходит, если откладывать рефакторинг (как и написание тестов, кстати) на потом. Последние годы убедили меня, что рефакторинг и тесты нетоделимы от дизайна и собственно написания кода. И, почему-то, я уже давно не рисовал архитектуру отдельно от кода, в смысле, на бумажке. Архитектура — и есть код, классы, пусть даже с пустыми методами.
А по поводу того, что в лучшем случае это будет сопоставление, к которому привык лично я — меня это не пугает, потому что а) я не один, всегда найдется куча людей со схожими привычками, а кому не нравится, то б) он может модифицировать мое решение под себя, ну или в) расхождений не должно быть очень уж много, эта часть может быть настраиваемой
Ага, это я уже понял, поразбиравшись с soundex и русским Metaphone. Поэтому сейчас начал думать в сторону транслитерации в нужный алфавит. Точнее, транслитерации преферансом и поэтессами. Ни один из фонтетических алгоритмов, на которые я смотрел, не дает мне то, что мне нужно, и именно по указанной вами причине.
Если продраться через сильно неродной для автора английский и/или смотреть только на код, то становится понятно, куда копать. Надеюсь, вам поможет.
Второе: при закрытии редактора с файлом он исчезает из контекста (насколько я помню, это поведение настраивается).
И третье: В сам mylyn встроен алгоритм, по которому определяется релевантность конкретного ресурса (файла, метода, теста, и т.д.). И чем реже вы обращаетесь к этому ресурсу, тем быстрее он «выпадет» из контекста. Не помню сейчас деталей (я присутствовал на презентации Мика Кирстена когда-то давно), но если мне не изменяет склероз, какой-то коэффициент этого затухания интереса тоже настраивается, либо через UI, либо через какой-то конфиг. Если я это придумал — прошу прощения.
Пардон за неаккуратность в коде, думаю, идея понятна.
Зачем это нужно:
Ну да, опыт, конечно, помогает находить неэлегантные места и подсказывает, что нужно сделать для их исправления, и опыт этот придет. Но если сначала рисовать _всю_ архитектуру, или, не приведи Господь, UML-диаграммы, а потом писать, получится индусский код. Их так учат. Они в своих университетах запоминают сотни умных слов и названий паттернов, но с практическим применением этих знаний у них проблемы. Смотришь на их код, хватаешся за голову. Говоришь ему — друг дорогой, на кой хрен тут нужны 50 строк кода в элеменарном методе? А он говорит: «А я применил паттерн «Сон синглтона в летнюю ночь на фасаде статической фабрики»». А то, что оно тут просто не нужно, что все эти 50 строк превращаются в три, он не задумывается. Не научен.
Спасибо огромное!