Saboteur

Подход процедурного программирования - во главе стоят функции и алгоритмы.

Во главе ООП стоят данные.
У вас есть данные, простой int или сложная структура в виде учетной записи (имя юзера, пароль, емайл, полное имя, etc)
Вот эти данные вы упаковываете в класс, к ним добавляете методы, которые работают именно с этими данными.

Это позволяет вам оперировать данными в виде класса. Вы точно знаете, что данные, в том формате, в котором они находятся и обрабатываются внутри класса, НИГДЕ больше не используются, кроме как в этом классе.
Если другому классу нужны данные вашего класса - для этого создается метод.

Это позволяет вам менять класс как угодно, при этом сохраняя методы. Надо что-то в новом виде - создаем еще один метод. Кто пользовался старым - продолжают, кто обновил - пользуется новым.

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

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

1. Паттерны это просто примеры решения часто возникающих проблем. Если вы знаете много паттернов, то скорее всего не будете изобретать велосипед там, где не надо. Но всегда можно действовать по ситуации, потому что стандартные методы не покрывают все требования.

2. Смотря как вы будете с ними работать. Если сущности слишком элементарные, можно и общий объект-массив

3. Сложно сказать. Если вам кажется, что много - подумайте, можно ли передавать в качестве аргумента сразу объект. И имеет ли смысл создавать новый класс для этого. Иногда бывает достаточно сделать достаточно конструкторов, и иметь возможность указывать не все аргументы.

4. Подключение к базе должно быть одним модулем.

Чем выше квалификация программиста
Чем проще задача
Чем больше времени на ее выполнение
Тем больше дзен.

Не парьтесь. Читать и изучать стилистику и правильное программирование нужно, но главное понимать какая основная стоит цель.

А цель - более читабельный и понятный код.
Более дешевый в поддержке и модернизации.

ООП это парадигма, а не язык программирования.
В ембеддед системах вполне активно пишут на С++ с полным ООП.

Просто почитайте внимательно что такое ООП и не задавайте некорректный вопрос

ООП это не стиль, это парадигма.
Ее можно использовать для написания программ практически любого размера, но неудобно для мелких скриптов.
Стиль это скорее нотации, типа CamelNotation

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

Суть ООП и функционального программирования только в том, как располагать куски кода - по функциям или по методам. Но ограничение доступа связано ни с функцией ни с методом, а с тем, как вы это ограничение реализовали.

Главная идея ООП заключается вот в чем:

Есть данные. Мы их инкапсулирем в класс.
Есть методы, которые манипулируют именно этими данными. Поэтому методы должны тоже находиться в классе с данными.

Если нам приходится добавлять данные, менять их тип и формат, в случае с ООП мы легко правим методы, которые находятся в этом же классе. Можем написать новые методы, можем переделать старые, можем совместить. В случае с функциональным программированием, затраты на переделку программы будут гораздо дороже и запутаннее.

Класс, это не функция, чтобы предоставлять что-то на выходе.

Класс - это набор данных и методов, которые работают с этими данными.

От этого определения и отталкивайтесь - что в классе должны быть нужные вам данные, и работать с этими данными нужно при помощи методов, объявленных внутри этого класса.

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

Женитесь, остальные вопросы отпадут.
Многопоточность и приколы современных компиляторов для вас открытая книга?
Поищите работу, в котором уровень сеньерности выше, чем в вашем текущем проекте, и узнаете новые грани для себя.

Все имеет свою цену. Не существует лучшего подхода просто самого по себе.
Существует задача, требования к задаче и от этого уже отталкиваться какой метод в конкретном случае будет удобнее.
Поэтому не нужно искать теоретических выводов.

Лучше начать с того, чтобы научиться пользоваться гуглом.
Рекомендуемый ресурс:
google.com

P.S. Java более ООП-язык, чем C++