Мне вот почему-то кажется, что смотреть надо на другое: график количества активных пользователей. Если есть стабильный прирост без вложений в рекламу - дело идет хорошо. Это сразу значит: приложение ищут и находят, приложение устанавливают больше, чем удаляют, приложение регулярно запускают.
Когда в SWTOR стали вводить LGBT-тематику, то у игроков появилась идея - ввести в настройки игры LGBT-OFF. Так вот, от разработчиков поступил отказ и мотивация - введение, например, опции BLACK-OFF будет расизмом. Так что есть мнение, что возможность отключения геев - это вид расизма.
Сдаётся мне, тут запросом не отделаешься, а если и можно, то лучше не надо - заковыристо выйдет. Писать надо процедурно. Или в хранимке с курсором. Или в обычном языке запихнуть данные в структуру и анализировать в цикле.
Например интерфейс Clickable. Все кликабельные объект его могут имплементировать. И эти объекты могут быть очень разные: кнопки, фоточки, ссылки. Ты можешь спокойно обрабатывать клик в каждом их них, но вдруг тебе нужно одинаковое поведение всех элементов на правый клик. Писать в каждом классе одинаковые обработчики - плохо. Зато можно обойтись одним универсальным методом:
void clickRight(Clickable clicked) {
message("Right on " + clicked.toString());
}
Суть еще в чём - если ты закрепишься в Москве, то если не будешь спать/дремать, то года через 3 появятся возможности поехать работать в Европу. Не упускай шанс - Курск от тебя не уйдет.
Начинать надо с функциональных требований. Т.е. список, что мы должны получить от программы. Когда список готов надо придумать модули, которые покроют эти требования. Ну а потом уже структуры данных, классов начинают просматриваться.
Еще беда что сейчас много разработок ведется на фреймворках, которые навязывают свою структуру. Надо уметь вписываться.
Создание правильной архитектуры - это высший пилотаж, приходит не сразу и не ко всем.
Вот вам правильные книги Мартина посоветовали - купите и читайте/перечитывайте. Еще изучите паттерны ООП. Когда информация на эту тему начнёт поступать в мозг, то при очередном написании программы вы вдруг поймёте "да вот же как надо!"
А пока книжек не купили, начните применять первый архитектурный принцип - разделяйте код. Видите программу больше 100 строк - сделайте из нее две. Видите кусок кода, который пишите не первый раз - вынесите его в отдельную программу. Сложно дать короткое имя классу или методу, потому что он делает и то и это - сделайте два класса/метода. Постепенно начнёт расти понимание, как нужно проводить архитектурные границы, а как не нужно.
Если нет - плохи дела.