Hm. DRY to świetna idea, a jak każda idea wymaga dogłębnego zrozumienia. Muszę przyznać, że jeszcze niedawno podpisałbym się pod tym co napisałeś, ale teraz chyba już nie… DRY – nie powtarzaj się, to każdy wie. Jednak tu nie chodzi o to, że w ogóle nie można się powtarzać. Chodzi o to, aby pewne części systemu (aplikacji) nie były zdefiniowane, zdublowane w dwóch różnych miejscach. Jeśli zmieni się coś w jednym miejscu, a zapomni w tym drugim to zapewne powstanie błąd. Przykładowo (na forum.rubyonrails.pl było kiedyś takie pytanie), masz metodę current_user (zwraca bieżącego zalogowanego usera) w kontrolerze. Chciałbyś tą samą metodę w widoku, ale jak wiadomo metody kontrolerów tam nie są widoczne. Musiałbyś zdefiniować tą metodę jeszcze raz w helperze. Jeśli zmieni się jedna to druga też powinna (są takie same!). Na szczęście można użyć helper_method w kontrolerze i wyeksponować ją do helpera.

Wracając do Twojego przykładu. Próbujesz traktować DRY zbyt dosłownie (tak jak mówię, ja chciałem robić na początku dokładnie tak samo). Zauważ, że Twój kod kontrolera jest kodem końcowym, tzn sam nigdzie nie zostanie już użyty, a więc można powiedzieć, że żadna część systemu od niego nie jest zależna. Dodatkowo zauważ, że (IMHO) bardziej sobie skomplikowałeś kod, gdyż musisz skapować skąd się bierze poprawny obiekt Podcast w zmiennej @podcast.

Każda z twoich akcji, które wymaga znalezienia podcasta po jego id ma taką logikę:
1. znajdź podcast po jego id = params[:id] i zapamiętaj ją w zmiennej @podcast
2. zrób coś z podcastem

I tak jak mówię, nie ma tu co cudować, logiki tej nie zmienisz i lepiej zostawić wersję bez filtrów. Ale podam Ci przykład, w którym (IMHO) DRY powinien być zastosowany. Załóżmy, że użytkownicy dodają podcasty, ale zanim pojawią się na stronie głównej, musi je zaakceptować (flaga accepted = true). Zatem w metodzie list mógłbyś napisać:

@podcasts = Podcast.find(:all, :conditions => [‘accepted = ?’, true])

I teraz jeśli w innym miejscu chcesz pobrać tylko zaakceptowane podcasty (np. RssController) powtórzysz dokładnie ten same finder z tymi samymi warunkami. A co, jeśli zmienisz flagą accepted na jakąś inną? Lepiej jest wtedy zrobić osobną metodę klasową w Podcas:

class Podcast < ActiveRecord::Base def self.find_accepted return find(:all, :conditions => [‘accepted = ?’, true]) end
end

To moim zdaniem DRY. DRY to także wszystkie wartości, które stanowią konfigurację systemu (zmienna którą zmieniasz w jednym miejscu i pozostała część systemu zależna od niej widzi te zmiany, np. adres jakiejś usług, urle itp). Na pewno można podać więcej przykładów. Aczkolwiek tak jak ze wszystkim, trzeba uważać żeby nie przesadzić :).

Jasne, ale moim zdaniem Seban pokazał tu ważną rzecz, że trzeba starać się stosować DRY. Zrozumienie poprawnego DRY i nieodpowiedniego przychodzi z czasem.

Poza tym dla każdego DRY oznacza coś innego. W naszym aktualnym projekcie jako pochodną DRY stosowaliśmy skinny controller, fat model. Na początku uznaliśmy, że każdego bardziej skomplikowanego finda należy wywalić do modelu. Okazało się po jakimś czasie, że zmniejsza to czytelność kodu - zamiast frameworkowego find'a z conditions miałeś ModelX::getcośtam(parametr). Okazało się, że jest to szkodliwe też z drugiego powodu (wspomniany w komentarzu powyżej). Otóż gdy taki getcośtam jest używany w kilku akcjach i nagle okazuje się, że w jednej z nich potrzeba odwrotnej kolejności zwracanych wyników.
Pojawił się dylemat: rozbudowywać get_cośtam o parametr order?

W każdym razie zmierzam do tego, że trzeba starać się stosować DRY, myśleć o nim i mieć to w głowie. Jeśli ma się dość oleju w głowie to po jakimś czasie przyjdzie zrozumienie jakie DRY jest dobre. Po prostu nie da się inaczej wytłumaczyć kiedy przeprowadzić ekstrakcję danego fragmentu do osobnej metody, a kiedy nie. Trzeba po prostu kilka razy się pomylić i poczuć problemy jakie z tego wynikają...