Рефакторинг

IntelliJ IDEA под этот бред сурово заточена.

>этот бред

Мне был бы очень интересен ваш критический отзыв о рефакторинге.

Необходимость такой штуки вызвана излишней жесткостью (?недостаточной гибкостью?) ныне популярного подхода к ОО программированию. Если твоя программа построена на иерархии обьектов с наследованием в стиле C++/Java - очень велика вероятность, что невозможно будет что-либо поменять в этой иерархии без массового переписывания кода. Также велика вероятность того, что это понадобиться - ибо мир динамичен а оракулы редко пишут программы.

NB! Скорее всего проблема не в языках а в наиболее разрекламированом варианте их применения.

Шутки ради:

Рефакторинга бояться - на Яве не писать.

Рефакторинг - методология латания дыр в дизайне ПО, вызваных ошибкой при принятии решения об используемом языке.

> А есть ли ещё что опсорсное на эту тему?

> IntelliJ IDEA

"Идея" игрушка неплохая, но не опенсорсная, если мне память не изменяет. Eclipse вещь хорошая и опенсорсная. Сам использую Eclipse + Borland Together plug-in (увы, не опенсорсный).

Цитата их бимерской доки по Eclipse/WSAD (прямо с моей установки сего замечательного средства):

"The goal of Java program refactoring is to make system-wide code changes without affecting the behavior of the program. The Java tools provide assistance in easily refactoring code.

The refactoring tools support a number of transformations described in Martin Fowler's book Refactoring: Improving the Design of Existing Code, Addison Wesley 1999, such as Extract Method, Inline Local Variable, etc.

When performing a refactoring operation, you can optionally preview all of the changes resulting from a refactoring action before you choose to carry them out. When previewing a refactoring operation, you will be notified of potential problems and will be presented with a list of the changes the refactoring action will perform. If you do not preview a refactoring operation, the change will be made in its entirety and any resultant problems will be shown. If a problem is detected that does not allow the refactoring to continue, the operation will be halted and a list of problems will be displayed.

Refactoring commands are available from the context menus of several Java views (e.g. Package Explorer, Outline) and editors. Many "apparently simple" commands, such as Move and Rename, are actually refactoring operations, since moving and renaming Java elements often require changes in dependent files. ... "

Для тех, кто заглянул на этот трэд и пока не достал книгу Фулера можно посмотреть (это сайт переводчика книги?)

http://w8.platonoff.com/refactoring/

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

Ну, в общем, DonkeyHot тут уже всё правильно сказал.

Рефакторинг - неизбежное зло, связанное с принятыми методами проектирования ОО-систем. Тут виновата даже не столько Java, сколько ООП вообще. И, refactoring является очевидным бредом - хотя бы по той простой причине, что он самим своим существованием противоречит главному лозунгу адептов ООП про "code reuse". Демонстрирует, что ООП в принципе не допускает ни малейшего code reuse, и, тем самым, полностью ООП дискредитирует.

Ага. Всего лишь. И это после всех этих идиотских воплей о том, что однажды написанный код потом менять не надо - только наследовать. Вот тебе и code reuse, вот тебе истинное лицо ООПной религии...

Провокационный вопрос. А чем объект отличается от замыкания?

> Рефакторинг - неизбежное зло, связанное с принятыми методами проектирования ОО-систем

Ну в чём-то ты прав. Сейчас от традиционного неповоротливого ООП пытаются перейти к АОП (аспектно-ориентированному программированию) - Spring стал модным фреймворком, очень модным. Хотя АП (ФП), возможно, более перспективно. Не дураки в "мелкософте" сидят, не дураки.

Ну так в то же время АОП - всего лишь очень ограниченный частный случай метапрограммирования.

Есть существенно более продвинутая тема - LOP (Language Oriented Programming), читать на lambda-the-ultimate.

Тем, что является всего лишь частным случаем. Замыкание - более общая сущность, пригодная для описания не только объектной модели, но и любой другой.

Ну так нефиг уши развешивать. ООП нормальная парадигма. По крайней мере реюз кода больше чем при процедурном програмировании. А то что не для всех задач подходит - ну так есесссно. Кто хочет панацями лечиться от первой же простуды подохнет.

>Ага. Всего лишь. И это после всех этих идиотских воплей о том, что однажды написанный код потом менять не надо - только наследовать.

От этого подхода вроде как уже отошли. Правда, это в общем-то не шаг вперед по отношению к ООП, а возврат к объектному программированию и связывание через композицию (например, посредством АОП).

А рефакторинг, на мой взгляд, применим не только к ООП. Открываем "добрую книжку", смотрим главу: http://www.gigamonkeys.com/book/practical-a-simple-database.html#removing-dup....

По-моему, это и есть рефакторинг. В чистом виде. Или нет?

Тут рефакторинг в другом контексте применяется, причём, в совершенно противоположном. Не специализация существующего кода под задачу - как то диктует принятый в ОО-тусовке рефакторинг, а, наоборот, на основе порождённого задачей или задачами кода построение более общего (!!!), и, соответственно, реюзабельного кода.

Ну, то, что твёрдый кал лучше поноса - не повод этот кал хавать. ООП - кал, и ему уже мало что поможет... :(

>Тут рефакторинг в другом контексте применяется, причём, в совершенно противоположном. Не специализация существующего кода под задачу - как то диктует принятый в ОО-тусовке рефакторинг, а, наоборот, на основе порождённого задачей или задачами кода построение более общего (!!!), и, соответственно, реюзабельного кода.

Ну это и есть "определение" рефакторинга - избавление от дублирования (а не специализация кода под задачу). В данном случае построением более общего кода.

Другое дело, что ты высказал интересную мысль о противоречивости рефакторинга переиспользованию кода в "чистом ООП". Может так оно и есть, но если учесть что сейчас единицей переиспользования считается уже не класс, а некий компонент (или набор компонентов, как сборка в .NET), то все равно остается широкое поле для рефакторинга (который не будет мешать переиспользуемости) - внутренняя имплементация (которая в идеале никого не волнует).