Насчет «просто работало».
Купили моей невесте iMac. Это чудо техники проработало 3 недели и сломалось. Причем, был бы это линукс, был бы Kernel Panic с хоть какой-нибудь вменяемой информацией, или BSOD в случае винды. В случае мака — это просто белый экран. Потому — просто сломался.

Как выяснилось после вечера разбирательств (а это к слову было накануне дня рождения невесты), выяснилось, что накрылся модуль bluetooth. С учетом того, что клавиатура и мышка беспроводные система стала слепоглухонемой. Даже при подключении проводных устройств система «висела» в режиме белого экрана около 15 минут (видимо тщетно пытаясь инициализировать bluetooth).

Да, компьютер приняли назад в re:Store и он уехал на экспертизу (на 45 дней). Но миф о качестве сборки и что «это просто работает» — это действительно просто миф. Маркетинг и бизнес, ничего личного. Своих денег он не стоит.

Правда есть другой случай — купил себе макбук для командировок. Два раза ронял его на кафельный пол — до сих пор служит. В каком случае и кому повезло — вопрос.

Во-первых, открывать поля класса для публичного доступа — это почти всегда плохая идея.
Во-вторых, очень важно, чтобы API был лаконичным и кратким. Стороннему разработчику, который будет пользоваться вашим классом, не нужно видеть больше методов, чем может понадобиться по смыслу задачи (не перегружайте людей информацией и не раскрывайте деталей своей реализации).
Поэтому методы стоит определять как private по умолчанию. Если выяснится, что метод может потребоваться (или его поведение может уточниться) в потомке, то делайте его protected.

Делать публичными стоит только те методы, которые соответствуют смысловой абстракции.

Постановка вопроса несколько странная. По-моему РСУБД никогда не скажет, сколько строк она обработала до получения результата. Более того, «маршрут сканирования» и его порядок в разных условиях будет разным.

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

Ключевой момент в профессиональном программировании — командная работа. Гениальность конкретного индивида не так важна с точки зрения проекта, как это наверное ни печально.