Хочу сделать презенташку по Рефакторингу. Вот сел и набросал в mindmap'чик все что было в голове по этому поводу. Надеюсь кому-то пригодится.
Если нельзя, но очень хочется, то нужно обязательно и ничего в мире не стоит того, чтобы делать из этого проблему!
Интересна Java? Кликай по ссылке и изучай!
столько времени читатели провели на блоге -
сейчас онлайн -
воскресенье, 20 ноября 2011 г.
Подписаться на:
Комментарии к сообщению (Atom)
Уже пригодилось.
ОтветитьУдалитьНачал читать Фаулера, но столкнулся с тем, что он очень любит ссылки из одного раздела (паттерна) в другой. Изложение в виде иерархической структуры более наглядно
Я так понял, что это после пятничного общения со мной :)
Да, Славик, все как-то на кучу наложилось и то, о чем мы с тобой говорили в пятницу, и таск в TODO моем - сделать презентацию по рефакторингу и минутка свободная... Парад планет так сказать.
ОтветитьУдалитьЭто так сказать самый сложный первый шаг был. Дальше пойдет по проще.
А вообще сама книга - это дерево. Смотри сам - оглавление, потом главы, параграфы, абзацы, предложения, слова и наконец буквы.
ОтветитьУдалитьКнигу удобнее было бы читать как mind map карту.
C "метод что-то делает с объектом пришедшим извне" не согласен, т.к. по закону Деметры http://en.wikipedia.org/wiki/Principle_of_Least_Knowledge метод может вызывать поля и методы объекта, который приходит к нему в качестве параметра.
ОтветитьУдалитьМожет то может, но больше, я бы сказал, read only. Если же он злоупотребляет этим и нагло меняет состояние объекта который ему пришел извне вместо того, чтобы отвечать за состояние того объекта в котором находится - это не гуд.
ОтветитьУдалитьПредставь себе List, который в методе add(Object) кроме добавления объекта еще и каким-то образом его причесывает. Я об этом.
Типичный пример - когда метод меняет состояние своего параметра - шаблон параметр-накопитель http://c2.com/cgi/wiki?CollectingParameter
ОтветитьУдалитьПочему бы не написать просто?
ОтветитьУдалитьString[] userFiles = ...
List userList = new ArrayList();
for (int i=0; i < userFiles.length; i++) {
userList.add(userFiles[i]);
}
или List userList = Arrays.asList(userFiles);
Пример какой-то непрактичный.
Опять же. Есть правила и есть исключения.
"метод что-то делает с объектом пришедшим извне" - можно и нужно нарушать, без этого не сделаешь некоторых шаблонов. Но когда весь код написан так, пора задуматься о рефакторинге.
У меня метод, который меняет что-то в объекте приходящем ему в качестве параметра но при этом не занимаюшийся своими полями - плохо пахнет. Его может реабилитировать то, что он служит какому-то шаблону, но чаеще всего это не так. Такому аромату у Фаулера есть определение - завистливая функция.
"Так, пора задуматься о рефакторинге", с этим тоже не согласен в корне, т.к. есть специальный рефакторинг - "Move Accumulation to Collecting Parameter", по той же ссылке, что я кидал (прямая: http://www.industriallogic.com/xp/refactoring/accumulationToCollection.html)
ОтветитьУдалитьДругой пример, когда метод изменяет состояние параметра: метод Persist (Save) в ORM, который обычно присваивает идентификатор сохраняемой сущности.
Единственное ограничение, которое тут накладывается - метод должен это делать через публичный контракт параметра. Другими словами - не менять поля напрямую.
"Его может реабилитировать то, что он служит какому-то шаблону, но чаеще всего это не так."
ОтветитьУдалитьУ меня другой опыт. И он подсказывает, что метод делающий правки в объекте плохо пахнет.
Если этот подход - часть шаблона - вопросов нет. Но в моем опыте это скорее исключение, чем правило.
Давай лучше сконцентрируемся на том, с чем есть согласие, что было ново, что захотелось попробовать?