DollyPapper

В том беда современного обучения программированию, что учат ООП на наследовании кошечек и собачек от абстрактных животных, а нахера это делать и зачем это появилось не учат. Плохая для вас новость - вы не поймете прелести подхода пока не проработаете хотя бы годик на реальном проекте. Но понять сам ООП вы можете не работая. Попытаюсь натолкнуть вас на мысль, и обьяснить истоки, откуда пошло ООП и зачем, через какое-то время вы осознаете эти концепции. Итак.
Когда мы пишем программу, мы так или иначе моделируем какую-то часть реальности. Модель это несовершенное представление самой этой реальности, с выделенными атрибутами необходимыми для нашей решаемой задачи (абстрагирование, один из принципов ООП), например детская игрушка самолет, это модель реального самолета который копирует лишь внешний реального самолета, при этом игнорируется его внутреннее устройство, и игрушка таким образом не умеет летать, но наша задача (развлечь ребенка) при этом выполняется.
Существует несколько парадигм праграмирования. Каждая парадигма это стиль моделирования программы. Затронем например процедурное программирование. В нем существуют для моделирования задачи такие сущности как: структуры данных и процедуры которые эти структуры обрабатывают. Дело в том, что в программе есть всего две еденицы которыми мы управляем: данные и поведение. Структуры данных это собственно данные, процедуры это поведение. Смысл зачем появилось процедурное программирование именно чтобы дать программисту абстрагировать поведение (засунуть код обработки данные в именованную сущность, она еще называется функция или процедура). Что это нам дает? Раньше у нас была простыня кода которая расчитывала например зп сотрудников, если нам нужно было посчитать зп в разных местах нам нужно было копипастить эту простыню. А сначала нужно было разобраться что простыня делает. Это сложно. Теперь у нас появилась именованная сущность (процедура) которпя имеет метку имени calculateSalary. Ну и что? А то, что теперь нам во первых не нужно копипастить код, во вторых (в идеале) не нужно разбираться как он работает. Мы просто знаем что calculateSalary считает зп для сотрудника. Как оно это делает, нам совершенно похер. Снизилась когнитивная нагрузка на мозг при моделировании задачи и повысилась переиспользуемость кода, тем самым сократилось время разработки. Но умные люди на этом не остановились и стали развивать идею дальше. Дальше они подумали, что не плохо было бы обьеденить в одной сущности данные и действия над этими данными, назвали это обьектами, которые могут формироваться на основе классов. Теперь у нас обьеденены данные и процедуры в одной именованной сущности (это инкапсуляция). Подробнее об инкапсуляции можете почитать в другом моем ответе https://qna.habr.com/q/1174988#answer_2194198
В общем вы не поймете прелесть ООП пока не поработаете по той причине, что нужно набрать массу сложности в проекте, которую генерируете как вы сами так и другие программисты, и не поймете прелесть повторного использования кода которое дает ООП, потому что у вас нет горящих сроков. Тут еще можно в целом много чего написать на тему ООП, но я бы вам посоветовал следующие книги:

Стив Макконел - Совершенный код
Гради Буч - Обьектно ориентированный анализ и проектирование
Сергей Типляков - Паттерны проектирования на платформе .NET (это вместо банды четырех, т.к. там более современно раскрывается тема паттернов, не пугайтесь что она про C# .NET, книга в самом деле очень хорошая)

Так же список терминов на погуглить
GRASP - Information Expert
Information Hiding
Software Complexity (это то откуда всё начинается, управление сложностью)
Cohesion & Coupling

Если вы все эти темы осознаете, то будете понимать в ООП и проектировании больше 95% ваших будующих коллег, я вам гарантирую.

Не знаю правда ли в 22 году сложно найти работу, но если реально трудно, то попробуйте тут помониторьте стажировки

В Golang есть такое понятие как дженерики.

В вашем примере код может выглядеть как нибудь так:

type StringOrStrings interface {
	string | []string
}

type DataStruct[T StringOrStrings] struct {
	Data T
}

StringOrStrings interface в данном случае выступает как ограничитель типа. Далее советую подробней ознакомится с документацией по Generics на оф. сайте Go.

Разница ИМХО в моделировании задачи. Парадигма у языка может быть не одна, но одна из тех которые язык поддерживает всегда превалирующая. Например в Java можно писать и в функциональном стиле, но большинство проектов это ООП подход.
Сама парадигма дает вам подход для моделирования и декомпозиции задачи. В ООП обьект декомпозиции это обьект, уж простите за тавтологию, в ФП обьект декомпозиции это фукнция. В ООП вы создаете обьект, возможно мутируете его состояние, вызываете у обьекта методы и вот это вот всё. В ФП у вас есть изначальные данные и они должны пройти через цепочку преобразований (вызовов функций) чтобы вычислить конечный результат, при этом изначальные данные не мутируются, и функция (в чистом ФП) всегда идемподентна, т.е. подавая на вход одни и те же данные мы получаем один и тот же результат, что в ООП и других подходах не всегда возможно, поскольку состояние обьекта например может поменять другая часть кода, например в другом потоке.
Когда говорят про функциональный стиль в JS это чаще всего вые**ны говорящего, потому что в жс просто понадергали фишек из ФП: декларативный подход к написанию кода, каррирование (которое чаще является частичным применением, а не каррированием), иммутабельность. А чисто ФПшный подход я ни разу в жизни если честно не встречал. Да и надо ли оно...

Фактических - хоть 10 языков. Будет ли практический толк? Не будет.

Не уверен, что это то что вам нужно, но посмотрите на эту либу: https://github.com/samdark/hydrator

Инкапсуляция вообще является (ИМХО) главным принципом из 4. Инкапсуляция + абстракция. Вы не поняли её основную идею. Инкапсуляция это объдинение в одной сущности данных (не обязательно в общем-то) и действий которая эта сущность может предоставить. Инкапсуляция + абстракция представляю собой в общем более общий принцип - сокрытие информации/сложности, и один без другого не сильно то полезен. Не путать с модификаторами доступа (public, private и тд). Этот принцип идет скрозь всю историю развития языков программирования и собственно является главной движущей силой их развития. Вот пример из реальной жизни: есть у вас микроволновка. Она имеет +- 2 нопки: выставить время, выставить мощность. Это интерфейс микроволновки, который доступен конечному пользователю. Всё что вам нужно знать, чтобы приготовить себе похавать - 1)на какой мощности это хавать, нужно готовить 2) сколько это нужно делать по времени. При этом очевидно внутри микроволновки происходит та самая сложность, микросхемы гоняют электрический ток, магнетрон изучает электромагнитные волны, всякая разная физика происходит и вот это вот всё. Итого: вся эти физика и электротехника инкапсулирована в объект микроволновки (инкапсулирована так, что мы не можем добраться до её внутреннего устройства, это важно. Т.е. мы не можем сами соединить проводки, поменять электрическую цель, чтобы себе похавать сделать, разработчик этой электропечки не дал нам даже потенциальную возможность это сделать легально. Можно конечно разобрать устройство и проделать все эти манипуляции, но это уже это на совести того самоделкина, кто это делает). Итого: мы имеем интерфейс из двух кнопок и получаем от обьекта микроволновки услугу - приготовить пожрать. Как там внутри это реализовано, нам не важно. Это и есть инкапсуляция + абстракция = сокрытие информации/сложности.
Более программистский пример: есть такая структура данных - Стек. Хотя по факту это не структура данных, а абстрактный тип данных. Советую этот термин загуглить, это важная составляющая в понимании ООП.
Представим, что стек это такой обьект который предоставляет услуги, по типу как мы представляли себе обьект микроволновки. Что нам нужно знать про стек, чтобы им пользоваться? Публичный интерфейс. Т.е. есть класс Stack с публичными методами push(), pop(), viewTopStack() (посмотреть первый элемент стека, без его удаление из самого стека). Всё, можно пользоваться. Как он внутри эти элементы хранит, простой ли это массив, или связный список, на сколько эффективно он там внутри работает - нам не важно. Это важно тому, кто предоставил нам в пользование данный класс. Мы знаем, что вызвав viewTopStack мы посмотрим первый элемент стека, вызвав push - положим что-то в стек, вызвав pop получим первый элемент, удалив его из стека (по аналогии: мы знаем что чтобы притоговить пожрать, нужно выставить в микроволновке время и мощность, на выходе получив наше адово хрючево). Если подытожить - инкапсуляци + абстракция, (еще раз настою на том, что порознь их нельзя рассматривать, это две тесно связанные концепции которые имеют практический смысл только в синергии) это механизм борьбы со сложностью, не только в программировании, вообще везде, в любой человеческой деятельности. В этом их смысл. Если ваши абстракции плохие -> ваш код сложный -> ваш код плохой (говнокодом его еще называют в сообществе программистов).
Почитать на эту тему можно следующее: Р.Мартин - Чистая архитектура (начать с глав про SOLID прицнипы), С.Макконел - Совершенный код (главу про классы обязательно, остальное желательно (очень желательно)), там в общем-то вам расскажут то что я вам сейчас рассказал, только более подробно, по больше примеров и дадут обоснование сложности, назвав борьбу с ней - Главным техническим императивом. Шлифануть это книгой банды четырех. Сами паттерны не обязательно начинать учить (да и рано вам еще), но вот введение и часть про программирование на основе интерфейса, а не реализации - самое оно, это дополнит картину.

UPD: тот факт, что мы в классе стек собрали его функционал (функции pop,push,...) обьединенные одной общей темой и есть факт инкапсуляции.

Для этого нужно использовать стандартную аггрегатную функцию count. Является частью стандарта SQL так что должна быть реализована всеми СУБД которые стандарт соблюдают.
SELECT count(id) FROM Car WHERE id !='' "

Добро пожалововать в современный еб***нутый мир, где у каждого языка 100500 фреймворков и используют их чаще всего не потому что "надо", а потому что использующий хочет с ним опыта набраться, потому что в вакансиях требуют его знание, потому что тот кто начал тот проект в вакансии тоже хотел с ним опыта набраться и круг замкнулся.

Использовать ОРМ где это реализовано не через костыль. За не имением ОРМ хорошим вариантом как уже предложил Дмитрий Беляев использовать курсоры

Если оболочка в системе баш (мб с другими тоже будет работать, если они читают этот файл), то можно внести необходимый код в /etc/profile, этот файл читается башем при входе в систему удаленных пользователей, в частности по ssh. Это наиболее нативный способ, который будет работать везде и для всех пользователей. Если нужно для какого-то конкретного пользователя, то ~/.bash_profile - так же работает при входе с удаленного сеанса, но уже конкретного пользователя.

возможно ли из другого образа будет к ней достучаться

Да, если их обьеденить в общую сеть.

Откуда берется вся эта херотень про "принципы ООП". Нет никаких принципов ООП кроме 7-8 (в большинстве статей в интернете 4). Абстракция, инкапсуляция, полиморфизм и наследование. DRY, KISS, SOLIDы всякие и прочее и прочее это не принципы ООП, это принципы программирования вообще. ООП это надстройка над процедурщиной. Процедурщина абстрагировала логику в функции, ООП сказал - "давайте еще и данные абстрагируем". Так получились классы и объекты. То есть у нас имеются умные обьекты которые хранят в себе данные, хранят свое состояние, и показывают наружу интерфейс взаимодействия. Всё. Вот ваш ООП. Отсюда и не понимание - "а как переписать на ООП", потому что в интернете столько всякого дерьма, и каждый любой придуманный или услышанный им принцип называет "принцип ООП". Нет.
Это если с идеологической стороны подходить. А с практической FanatPHP правильно сказал - это инструмент который следует применять к месту. И это место - большие проекты где очевидна выгода от этого подхода. Начни с объектной декомпозиции. Гради Буча покури попробуй. То есть нужно сначала понять концепцию, а потом уже пытаться что-то написать в "стиле ООП". Иначе будут возникать вопросы на которые вы не ответите, типа - "А вот этот класс который я написал, это реально объект в понимании ООП или структура данных с обвязкой из процедур".