Q:

Полезно ли всю логику делить на методы?

В последнее время пишу многофункциональные приложения со множеством элементов UI-интерфейса в смешке с работой с локальной БД, серверными запросами, загрузкой картинок, сложными списками, кучей анимаций, сервисами и т.д. Плюс всякие хаки, без них никак. Раньше я писал код сплошняком, не понимал тогда еще что все ужасно. Сейчас же я везде использую методы. Например, метод для нахождения всех вью initViews, метод для подготовки (установки всяких слушателей, настроек) - setupViews. Да что там говорить, бывают случаи когда прячешь две строки кода в метод чисто ради того, чтобы дать ему название! Это, я считаю, удобно, код превращается в идеальную (имхо) структуру, вся логика находится в методах, можно легко сконцентрироваться на главном, но правильно ли это?
Также активно использую интерфейсы, например, раньше:
player.setOnCompletionListener(new OnCompletionListener()...

сейчас (на память)
 public class MainActivity extends Activity implements MediaPlayer.OnCompletionListener

...

player.setOn...(this);

...

@Override
public void onComplete() {}

Иными словами, наследую активность от нужного интерфейса, реализую нужны методы, указываю this и вперед. В итоге 

активность набирает порядка 20 интерфейсов, в том числе своих, например, от адаптера списка или от класса-плеера. 
везде this
куча переопределенных методов

Это конечно удобно, но вот мне интересно правилен ли такой подход?

A:

Например, метод для нахождения всех вью initViews

Хорошо.
наследую активность от нужного интерфейса, реализую нужны методы, указываю this и вперед

Хорошо. Еще не помешало бы, допустим, в onClick писать не в switch, а в отдельном методе на каждую кнопку, который вызывать из switch.
метод для подготовки (установки всяких слушателей, настроек) - setupViews

Не стоит.
но правильно ли это?

Для меня нет, постоянно не хватает сил и времени, а эта "идеальность" отнимет их еще больше, причем именно потому, что она хороша, а хорошее создается дольше и тяжелее чем плохое (да ладно!), более того, даже если это окупится в будущем но заказчикам я этого не объясню которым нужен видимый результат каждый день, и в самом деле, нужно запустить проект, получить долгожданную первую прибыль и уже потом приводить в порядок, а если сразу, то это замедлит его запуск, и возникнет риск не уложиться в имеющийся финансовый и моральный потенциал, поэтому дураки - кто требует сразу писать проект идеально, особенно если вообще нет уверенности в его успехе.
Для меня такой перфекционизм - это вечная безысходность без единого законченного проекта и перспектив какого-либо роста. Пробовал, жалею.
Но это для меня, а вы, может быть, не создаете стартапов, со сроками все отлично, задачи самые стандартные и не приходится каждый раз проводить работу в объеме кандидатской диссертации, можно работать по два часа в день с тремя перекурами, и зачем вам мой ответ?

A:

Правильным будет не только выделять блоки кода в методы, а выделять логику в отдельные классы. 
Активити - контроллер виджетов на экране, и ее функция этим ограничена - получить реакцию пользователя и направить действие дальше (вызвать другой класс), саму бизнес-логику активити содержать не должна. Например, запрос в сеть выполняет другой класс, вся работа с БД тоже другой класс и тд. Активити же только вызывает методы этих классов в ответ на реакции пользователя/события интерфейса (виджетов)/манипуляции с интерфейсом (виджетами) - изменение контента и тп..
Реализации интерфейсов-колбэков в ряде случаев (когда их логика напрямую не связана с интерфейсом) тоже удобно выносить в отдельный класс, чтобы не загромождать логику контроллера. То есть, колбэк обработки клика уместен в классе самой активити, а например, колбэк запросов в сеть лучше вынести в отдельный класс (при реализации собственных колбэков), подключая в активити только слушатель и реализации методов колбэка.
В ООП программировании есть такое понятие - принципы SOLID, рекомендуется им следовать. Первый принцип (Single) - принцип единственной обязанности, то есть класс должен выполнять только одну функцию. Также полезно почитать литературу по теме проектирования архитектуры приложения, как "Чистый код" Боба Мартина.
По поводу ответа Rou1997 категорически не согласен и свое мнение выразил в комментариях. Конечно должен быть разумный баланс, "вылизывать" код можно до бесконечности, но подход "пофиг, лепи все в кучу" никогда не давал никаких приемуществ, кроме как показать заказчику/пользователям "залипуху" через неделю, а потом выслушивать его постоянные претензии "годы" (там упало, здесь криво и тд), и подпирать все это костылями, а потом костыли костылями. В итоге заказчик не захочет иметь другие дела с такой конторой и другим посоветует держаться подальше.
UPDATE Есть мнение, что структурированный проект отнимает больше времени на старте, а результаты нужны сейчас. С этим я так же не могу согласиться. Начинать проект без готовой структуры - это переписывать (рефакторить) все по много раз - то тут не учел, то там не состыкуется. За призрачную возможность показать клиенту шевелящийся экранчик на пару часов раньше - расплата: большее общее время разработки, нервы, нудная и бесполезная (при правильном подходе) рутина рефакторинга - это на любителя.
Не хочу навязывать свое мнение, но я начинаю проект по такой схеме: набрасываю общую архитектуру из требований ТЗ (классы, их методы, взаимодействия и тп.) на бумажке, UML или как кому нравится. Затем начинаю проект с стартового класса, делаю минимальную болванку (интерфейс) с заглушками для отладочных тестов и далее по следующей схеме - требуются данные из БД, пишем:
Cursor cursor = bdHelper.getData();

IDE отмечает, что данного класса не существует и предлагает создать. Создаем (при этом у опытного програмиста уже, как правило, есть готовый шаблон, требующий небольшой модификации. Вообще большинство типовых классов уже написано и их шаблон нужно только добавить в проект, внося минимальные изменения. При подходе "все в кучу" приходится писать все каждый раз заново или копипастить куски из других проектов с болшими переделками), реализуем требуемую сейчас логику (метод getData()). Тестируем, что все работает.
 Реализуем следующюю функцию стартового класса по такой же схеме и так весь проект по кирпичику выстраивается в четкую логическую структуру, удобную для тестов и отладки (места появления проблем локализованы отдельными классами и методами в них, а не в огромной портянке с запутанными взаимодействиями), плюс к тому отличная масштабируемость и расширяемость, добавление новых хотелок клиента не приводит к переписыванию половины портянки).
Так же современные IDE делают очень много работы за программиста, особенно если он следует "канонам" разработки, на реализацию структуры уходят секунды (нажать создать класс). Шаблоны, автодополнения, автовставки методов для реализации того же колбэка и прочие удобства позволяют "обрастать" кодом "на глазах" не теряя структуры и чистоты. Поэтому я, в свою очередь, считаю дураками тех, кто лепит "лишь бы что то показать", а потом уже разбираться будем, как все собрать и "причесать".

